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.223.84 with SMTP id ij20mr6894333qab.5.1349423415796;
        Fri, 05 Oct 2012 00:50:15 -0700 (PDT)
Received: by 10.52.71.38 with SMTP id r6mr1510931vdu.12.1349423415767; Fri, 05
 Oct 2012 00:50:15 -0700 (PDT)
Path: 
 e10ni165558057qan.0!nntp.google.com!l8no26156349qao.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Fri, 5 Oct 2012 00:50:15 -0700 (PDT)
In-Reply-To: <fd41da3a-288e-4717-a511-3f6dc44b1ac5@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=188.66.211.138;
 posting-account=g6PEmwoAAADhFsmVm6Epjviaw4MLU0b5
NNTP-Posting-Host: 188.66.211.138
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>
 <fd41da3a-288e-4717-a511-3f6dc44b1ac5@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <cdacbebf-e532-485a-acf2-590a94d86660@googlegroups.com>
Subject: Re: highest bit, statically determined
From: Anatoly Chernyshev <achernyshev@gmail.com>
Injection-Date: Fri, 05 Oct 2012 07:50:15 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Date: 2012-10-05T00:50:15-07:00
List-Id: <comp.lang.ada>

On Thursday, October 4, 2012 2:01:50 PM UTC+4, kalvi...@gmail.com wrote:
> maanantai, 1. lokakuuta 2012 11.52.43 UTC+3 Anatoly Chernyshev kirjoitti:
>=20
> > >=20
>=20
> >=20
>=20
> > >     68580000 1.687923000
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >     68580000 1.447859000
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >     68580000 24.481472000
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > Yes, that could be expected. Here's the draft lightning-fast version:
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > procedure xx is
>=20
> >=20
>=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
> >=20
>=20
> > N:natural;
>=20
> >=20
>=20
> > begin
>=20
> >=20
>=20
> > ...
>=20
> >=20
>=20
> > Highest_Bit_In_Octet:=3Dlast_bit_a(N);
>=20
> >=20
>=20
> > ...
>=20
> >=20
>=20
> > end xx;
>=20
>=20
>=20
> This can be optimised for improved size so that we create a lookup table =
only for a nibble values (0..15), and divide the handling into two parts ac=
cording to whether the higher nibble is zero or non-zero. The end result wo=
uld be a slighter slower execution speed but less code space. And this meth=
od can easily be extended to larger data sizes, too.
>=20
>=20
>=20
> - Kalvin

If you play with the memory optimization (I'm not very good at it), the arr=
ay above will be made of 3 bit integers (0 to 7), which occupy lousy 3*256/=
8=3D 96 bytes of memory. Laughable by today's standards. Even if you go for=
 long_long_long..._integers, the table will be quite small.