From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,7e15102eb14c0020 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.224.117.143 with SMTP id r15mr4992401qaq.1.1349344910280; Thu, 04 Oct 2012 03:01:50 -0700 (PDT) Received: by 10.52.30.164 with SMTP id t4mr801930vdh.4.1349344910240; Thu, 04 Oct 2012 03:01:50 -0700 (PDT) Path: e10ni165558057qan.0!nntp.google.com!l8no24688160qao.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 4 Oct 2012 03:01:50 -0700 (PDT) In-Reply-To: <036db9eb-36e8-4a2e-8832-cecd9f1f4e2d@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=83.150.124.2; posting-account=QrZwxQoAAAByl3YAWTpexAk3yBYyZMHn NNTP-Posting-Host: 83.150.124.2 References: <50673111$0$9505$9b4e6d93@newsspool1.arcor-online.net> <38594cbf-b52d-4002-8db9-410f55126a09@googlegroups.com> <50694f43$0$6577$9b4e6d93@newsspool3.arcor-online.net> <036db9eb-36e8-4a2e-8832-cecd9f1f4e2d@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: highest bit, statically determined From: kalvin.news@gmail.com Injection-Date: Thu, 04 Oct 2012 10:01:50 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-10-04T03:01:50-07:00 List-Id: maanantai, 1. lokakuuta 2012 11.52.43 UTC+3 Anatoly Chernyshev kirjoitti: > >=20 >=20 > > 68580000 1.687923000 >=20 > >=20 >=20 > > 68580000 1.447859000 >=20 > >=20 >=20 > > 68580000 24.481472000 >=20 >=20 >=20 > Yes, that could be expected. Here's the draft lightning-fast version: >=20 >=20 >=20 > procedure xx is >=20 > last_bit_a: array(0..255) of natural:=3D(0|1=3D>0,2|3=3D>1,4..7=3D>2, 8..= 15=3D>3, 16..31=3D>4,32..63=3D>5, 64..127=3D>6, 128..255=3D>7); >=20 > N:natural; >=20 > begin >=20 > ... >=20 > Highest_Bit_In_Octet:=3Dlast_bit_a(N); >=20 > ... >=20 > end xx; This can be optimised for improved size so that we create a lookup table on= ly for a nibble values (0..15), and divide the handling into two parts acco= rding to whether the higher nibble is zero or non-zero. The end result woul= d be a slighter slower execution speed but less code space. And this method= can easily be extended to larger data sizes, too. - Kalvin