What about big integers in Ada 2005?

What about big integers in Ada 2005?

[jtg]

When I started to learn Ada, one of the most interesting features for me
was the possibility to declare integer type of the specified range.
I imagined that the integer type may be of any size.
However, several years later I needed big integers and I was
disappointed - Ada95 does not support integers of ANY size,
it can support only those integers that are supported
by the processor, or smaller.

Does Ada 2005 support big integers?
Where can I learn how to use them?

Re: What about big integers in Ada 2005?

[Pascal Obry]

jtg a �crit :

> Does Ada 2005 support big integers?

No.

> Where can I learn how to use them?

There is some libraries around (3 or 4 if my memory is right) that
support big integers. I don't have the links at hand...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: What about big integers in Ada 2005?

[Martin Krischik]

jtg wrote:

> When I started to learn Ada, one of the most interesting features for me
> was the possibility to declare integer type of the specified range.
> I imagined that the integer type may be of any size.
> However, several years later I needed big integers and I was
> disappointed - Ada95 does not support integers of ANY size,
> it can support only those integers that are supported
> by the processor, or smaller.

You are mistaken here. i.E GNAT supports 64 integers for 32 bit CPUs. It's
all up to the particular compiler. In theory you could create an Ada
compiler which supports intergers up to the memory limit - it would still
conform to the standart.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: What about big integers in Ada 2005?

[Martin Dowie]

Pascal Obry wrote:
> jtg a �crit :
> 
> 
>>Does Ada 2005 support big integers?
> 
> 
> No.
> 
> 
>>Where can I learn how to use them?
> 
> 
> There is some libraries around (3 or 4 if my memory is right) that
> support big integers. I don't have the links at hand...
> 
> Pascal.

They should be reachable from www.adapower.com

-- Martin

Re: What about big integers in Ada 2005?

[Martin Dowie]

Martin Krischik wrote:
> You are mistaken here. i.E GNAT supports 64 integers for 32 bit CPUs. It's
> all up to the particular compiler. In theory you could create an Ada
> compiler which supports intergers up to the memory limit - it would still
> conform to the standart.

Yeah, but that's a bit of a pain, portability-wise. E.g. GNAT for 
Windows can support 64-bit integers but ObjectAda for Windows can't. :-(

Cheers

-- Martin

Re: What about big integers in Ada 2005?

[jtg]

Martin Krischik wrote:

> 
> You are mistaken here. i.E GNAT supports 64 integers for 32 bit CPUs. It's
> all up to the particular compiler. In theory you could create an Ada
> compiler which supports intergers up to the memory limit - it would still
> conform to the standart.
> 

I know, but since it is not a standard Ada feature, it would be useless
anyway. Programs using this feature would not conform to the standard.

Re: What about big integers in Ada 2005?

[Larry Kilgallen]

In article <dgcihm$42g$2@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>, Martin Dowie <martin.dowie@btopenworld.com> writes:
> Martin Krischik wrote:
>> You are mistaken here. i.E GNAT supports 64 integers for 32 bit CPUs. It's
>> all up to the particular compiler. In theory you could create an Ada
>> compiler which supports intergers up to the memory limit - it would still
>> conform to the standart.
> 
> Yeah, but that's a bit of a pain, portability-wise. E.g. GNAT for 
> Windows can support 64-bit integers but ObjectAda for Windows can't. :-(

But less of a problem that with other languages where the compiler might
have no obligation to reject programs which expect missing support (or no
syntax for the programs to specify expected support).

Re: What about big integers in Ada 2005?

[Larry Kilgallen]

In article <dgclij$4lq$1@news.task.gda.pl>, jtg <jtg77@poczta.onet.pl> writes:
> Martin Krischik wrote:
> 
>> 
>> You are mistaken here. i.E GNAT supports 64 integers for 32 bit CPUs. It's
>> all up to the particular compiler. In theory you could create an Ada
>> compiler which supports intergers up to the memory limit - it would still
>> conform to the standart.
>> 
> 
> I know, but since it is not a standard Ada feature, it would be useless
> anyway. Programs using this feature would not conform to the standard.

Certainly they would comply (unless a standard more recent than I have
read says something about 32 or 64 bits).  I recall a lower limit of
16 bit support, but no upper limit.

Re: What about big integers in Ada 2005?

[gautier_niouzes]

jtg:

> When I started to learn Ada, one of the most interesting features for me
> was the possibility to declare integer type of the specified range.
> I imagined that the integer type may be of any size.
> However, several years later I needed big integers and I was
> disappointed - Ada95 does not support integers of ANY size,
> it can support only those integers that are supported
> by the processor, or smaller.
>
> Does Ada 2005 support big integers?
> Where can I learn how to use them?

Big integers are special beasts that have to be treated
differently than "normal" integers because they can have
an arbitrary size in memory and require a specific handling
not foreseen in "normal" processors.

However big integers are doable and available in every Ada version;
on the following site you'll find a bunch of downloadble packages:

http://www.chez.com/bignumber/

BTW, the freshest version of my multi-precision integers are
in mathpaqs.zip on my Ada page below.
HTH
______________________________________________________________
Gautier     --     http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: What about big integers in Ada 2005?

[Craig Carey <research@ijs.co.nz>]

On 16 Sep 2005 07:33:26 -0700, gautier_niouzes@hotmail.com wrote:
...
>> disappointed - Ada95 does not support integers of ANY size,
...
>on the following site you'll find a bunch of downloadble packages:
>
>http://www.chez.com/bignumber/

That webpage is out of date since not referring to my Ada bindings to
the GNU GMP big numbers package:

http://tope.tigris.org/source/browse/tope/src/Gmp/gmp_2k4.ads?view=markup

My code replaces the GMP Ada bindings named at the chez.com website.

>BTW, the freshest version of my multi-precision integers are
>in mathpaqs.zip on my Ada page below.

File "multi_precision_integers.ads" (*.adb file is 40kb):

|  subtype Basic_int is Integer;
|  type Index_int is new integer;
|
|  type Block_array is array( index_int range <> ) of Basic_int;
|
|  type Multi_int(n: Index_int) is record
|    blk:       Block_array( 0..n ); -- the n blocks with ABSOLUTE v...
|    neg:       Boolean;             -- negative flag
|    zero:      Boolean:=True;       -- zero flag (supercedes the ot...
|    last_used: Index_int;           -- the others blocks are suppos...
|  end record;


(The GNAT style checker won't accept that code fragment.)

GMP did compile well with GCC 2.8.1 (which was needed since combining
GNAT 2.8.1 with a GCC C (not C++) of a different version, in Windows,
led
to botched parameter passing.

There was a message about C/C++ to Ada. A way to get that running is to
have two Ada YACC (AdaGOOP) parsers in series. Maybe Mr de Montmollin
can
produce a program to convert C body files into faulty Ada.


Craig Carey, Auckland city

Re: What about big integers in Ada 2005?

[adaworks]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1581461.uQ1jN63t33@linux1.krischik.com...
> jtg wrote:
>
> > When I started to learn Ada, one of the most interesting features for me
> > was the possibility to declare integer type of the specified range.
> > I imagined that the integer type may be of any size.
> > However, several years later I needed big integers and I was
> > disappointed - Ada95 does not support integers of ANY size,
> > it can support only those integers that are supported
> > by the processor, or smaller.
>
> You are mistaken here. i.E GNAT supports 64 integers for 32 bit CPUs. It's
> all up to the particular compiler. In theory you could create an Ada
> compiler which supports intergers up to the memory limit - it would still
> conform to the standart.
>
I interepreted this question to refer to integers of arbitrary size such as
those in Smalltalk.   In Ada compilers, as with other language with
implementations tied to the underlying platrform, numbers are related
to the word size of the targeted machine.    For example, I cannot define,
on any Ada compiler that I know of, an Integer such as,

       type Number is range 0..2**78;

since this would overflow contemporary (not future) architectures.  In
Smalltalk,
and many other languages, we can do arithmetic on numbers such as,

        34567345754784567745464478456345356675
and
        99874257918340987932560129346591237523

Of course, this is not an inherent limitation of Ada.  One can create a package
to do this kind of arithmetic, but it is not all that easy to do so.

Richard Riehle

Re: What about big integers in Ada 2005?

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:1581461.uQ1jN63t33@linux1.krischik.com...
> > jtg wrote:
> >
> > > When I started to learn Ada, one of the most interesting features for me
> > > was the possibility to declare integer type of the specified range.
> > > I imagined that the integer type may be of any size.
> > > However, several years later I needed big integers and I was
> > > disappointed - Ada95 does not support integers of ANY size,
> > > it can support only those integers that are supported
> > > by the processor, or smaller.
> >
> > You are mistaken here. i.E GNAT supports 64 integers for 32 bit CPUs. It's
> > all up to the particular compiler. In theory you could create an Ada
> > compiler which supports intergers up to the memory limit - it would still
> > conform to the standart.

I'm not sure that would work very well.  Programmers today often write
things like "range 0..System.Max_Int", which wouldn't work well if
Max_Int requires something like 2**36 bits to store.  That is,
programmers sometimes _rely_ on the fact that Ada compilers limit
integers to a small number of machine words (like one or two).

Anyway, it's not very interesting when compilers are _allowed_ to
provide some capability.  The interesting features (to me) are the ones
that I can count on existing in _every_ compiler -- because I usually
want to write portable code.

> I interepreted this question to refer to integers of arbitrary size such as
> those in Smalltalk.   In Ada compilers, as with other language with
> implementations tied to the underlying platrform, numbers are related
> to the word size of the targeted machine.    For example, I cannot define,
> on any Ada compiler that I know of, an Integer such as,
> 
>        type Number is range 0..2**78;
> 
> since this would overflow contemporary (not future) architectures.  In
> Smalltalk,
> and many other languages, we can do arithmetic on numbers such as,
> 
>         34567345754784567745464478456345356675
> and
>         99874257918340987932560129346591237523
> 
> Of course, this is not an inherent limitation of Ada.  One can create a package
> to do this kind of arithmetic, but it is not all that easy to do so.

One annoying thing is that every Ada compiler must implement such a
package, yet this package is not (portably) available to Ada
programmers.  Some such package has to exist in every implementation,
because static expressions are evaluated with arbitrarily-large range at
compile time.  But that functionality is not (standardly) available at
run time.  Sigh.

The other annoying thing is that even if you have such a package, you
have to use different (uglier) notations for various things (literals,
case statements, range constraints, etc).  So if I want an integer range
1..2**40, say, should I use an arbitrary-range arithmetic package and
write ugly-but-portable code?  Or should I take advantage of a
particular Ada compiler that supports it?  Neither choice is good.

I happen to think "range 0..2**78" should be required of all Ada
implementations.  Or even "0..2**(2**12)".

> Richard Riehle

- Bob

Re: What about big integers in Ada 2005?

[Jeffrey R. Carter]

Robert A Duff wrote:

> One annoying thing is that every Ada compiler must implement such a
> package, yet this package is not (portably) available to Ada
> programmers.  Some such package has to exist in every implementation,
> because static expressions are evaluated with arbitrarily-large range at
> compile time.  But that functionality is not (standardly) available at
> run time.  Sigh.

Right. This is one of my problems with the Containers proposal. Vendors have to 
implement a hash table (for the hashed structures) and a structure that may be 
searched in O(log N) time (for the ordered structures), but they're not defined 
by the language nor required to be available to users.

-- 
Jeff Carter
"Now go away or I shall taunt you a second time."
Monty Python & the Holy Grail
07

Re: What about big integers in Ada 2005?

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccmzlu3127.fsf@shell01.TheWorld.com...
> <adaworks@sbcglobal.net> writes:
>
>
> > I interepreted this question to refer to integers of arbitrary size such as
> > those in Smalltalk.   In Ada compilers, as with other language with
> > implementations tied to the underlying platrform, numbers are related
> > to the word size of the targeted machine.    For example, I cannot define,
> > on any Ada compiler that I know of, an Integer such as,
> >
> >        type Number is range 0..2**78;
> >
> > since this would overflow contemporary (not future) architectures.  In
> > Smalltalk,
> > and many other languages, we can do arithmetic on numbers such as,
> >
> >         34567345754784567745464478456345356675
> > and
> >         99874257918340987932560129346591237523
> >
> > Of course, this is not an inherent limitation of Ada.  One can create a
package
> > to do this kind of arithmetic, but it is not all that easy to do so.
>
> One annoying thing is that every Ada compiler must implement such a
> package, yet this package is not (portably) available to Ada
> programmers.  Some such package has to exist in every implementation,
> because static expressions are evaluated with arbitrarily-large range at
> compile time.  But that functionality is not (standardly) available at
> run time.  Sigh.
>
> The other annoying thing is that even if you have such a package, you
> have to use different (uglier) notations for various things (literals,
> case statements, range constraints, etc).  So if I want an integer range
> 1..2**40, say, should I use an arbitrary-range arithmetic package and
> write ugly-but-portable code?  Or should I take advantage of a
> particular Ada compiler that supports it?  Neither choice is good.
>
> I happen to think "range 0..2**78" should be required of all Ada
> implementations.  Or even "0..2**(2**12)".
>
I am glad to see that we agree on this Bob.   One of the key ideas of
abstraction is that we are not limited to the underlying architecture of
the hardware but can use that architecture in more creative ways.

COBOL solved this problem years ago with its capability for variable
length numbers via the PICTURE clause.   Smalltalk, mentioned in
my earlier post is particularly good at this kind of thing.    One would
think that Ada, with its emphasis on building good abstractions, would
have support for it.

Richard Riehle

Re: What about big integers in Ada 2005?

[Brian May]

>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:

    Martin> You are mistaken here. i.E GNAT supports 64 integers for
    Martin> 32 bit CPUs. It's all up to the particular compiler. In
    Martin> theory you could create an Ada compiler which supports
    Martin> intergers up to the memory limit - it would still conform
    Martin> to the standart.

Question (from writing a communications protocol with a high level
programming language that turned out to a an extremely poor
choice[1]):

Does GNAT support both "unsigned" and "signed" 64 bit numbers on 32
bit CPUs?

The reason I ask is because the protocol specs say some numbers might
be 64 bit, and sometimes they are signed, and other times that might
be unsigned. I am just curious if how well Ada could cope with this.

Notes:

[1] PHP. As far as I can tell it only supports signed 32 bit numbers
on 32 bit platforms[1].

[2] Fortunately, 32 bit numbers are probably OK for my client. This is
kind of ugly though, as I have to store the numbers in a mysql
database (signed/unsigned up to 64 bit[3]). My current approach is to
turn it into a positive number and store it in an unsigned 64 bit
field, with another field to indicate that the number is
negative. Unfortunately, the negative number 8000 0000 (hex) can't be
represented as a positive number in a signed 32 bit integer :-(.  So I
transform the number into 7FFF FFFF (hex) instead. This results in it
being out by one.

[3] Yes, even though the current code doesn't support 64bit, I have
designed the database to support it properly.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: What about big integers in Ada 2005?

[Martin Krischik]

Brian May wrote:

> Question (from writing a communications protocol with a high level
> programming language that turned out to a an extremely poor
> choice[1]):

package Interfaces is
pragma Pure (Interfaces);

   type Integer_8  is range -2 **  7 .. 2 **  7 - 1;
   for Integer_8'Size use  8;

   type Integer_16 is range -2 ** 15 .. 2 ** 15 - 1;
   for Integer_16'Size use 16;

   type Integer_32 is range -2 ** 31 .. 2 ** 31 - 1;
   for Integer_32'Size use 32;

   type Integer_64 is range -2 ** 63 .. 2 ** 63 - 1;
   for Integer_64'Size use 64;

   type Unsigned_8  is mod 2 **  8;
   for Unsigned_8'Size use  8;

   type Unsigned_16 is mod 2 ** 16;
   for Unsigned_16'Size use 16;

   type Unsigned_32 is mod 2 ** 32;
   for Unsigned_32'Size use 32;

   type Unsigned_64 is mod 2 ** 64;
   for Unsigned_64'Size use 64;

;-)

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: What about big integers in Ada 2005?

[Martin Krischik]

Dennis Lee Bieber wrote:

>         I'll admit I'm somewhat surprised GNAT (and likely others)
> implemented fixed-point math using scaled integers -- rather than a BCD
> package.

I allways thought we have both:

http://en.wikibooks.org/wiki/Ada_Programming/Types/delta
http://www.adaic.com/standards/95lrm/html/RM-3-5-9.html

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: What about big integers in Ada 2005?

[Brian May]

>>>>> "Martin" == Martin Krischik <krischik@users.sourceforge.net> writes:

    Martin>    type Integer_64 is range -2 ** 63 .. 2 ** 63 - 1; for
    Martin> Integer_64'Size use 64;

[...]

    Martin>    type Unsigned_64 is mod 2 ** 64; for Unsigned_64'Size
    Martin> use 64;

Yes, looks like it. I thought so....

Thanks for the confirmation.

Now I just need to convince my client to pay to rewrite the project
using Ada ;-). Yes, I know, I am dreaming.
-- 
Brian May <bam@snoopy.apana.org.au>

Re: What about big integers in Ada 2005?

[Simon Wright]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Brian May wrote:
>
>> Question (from writing a communications protocol with a high level
>> programming language that turned out to a an extremely poor
>> choice[1]):
>
> package Interfaces is
> pragma Pure (Interfaces);
>
>    type Integer_8  is range -2 **  7 .. 2 **  7 - 1;
>    for Integer_8'Size use  8;
>
>    type Integer_16 is range -2 ** 15 .. 2 ** 15 - 1;
>    for Integer_16'Size use 16;
>
>    type Integer_32 is range -2 ** 31 .. 2 ** 31 - 1;
>    for Integer_32'Size use 32;
>
>    type Integer_64 is range -2 ** 63 .. 2 ** 63 - 1;
>    for Integer_64'Size use 64;
>
>    type Unsigned_8  is mod 2 **  8;
>    for Unsigned_8'Size use  8;
>
>    type Unsigned_16 is mod 2 ** 16;
>    for Unsigned_16'Size use 16;
>
>    type Unsigned_32 is mod 2 ** 32;
>    for Unsigned_32'Size use 32;
>
>    type Unsigned_64 is mod 2 ** 64;
>    for Unsigned_64'Size use 64;

This is GNAT. On the other hand, RM95 says

package Interfaces is
   pragma Pure(Interfaces);

   type Integer_n is range -2**(n-1) .. 2**(n-1) - 1;  --2's complement

   type Unsigned_n is mod 2**n;

..

 An implementation shall provide the following declarations in the
 visible part of package Interfaces:

* Signed and modular integer types of n bits, if supported by the
  target architecture, for each n that is at least the size of a
  storage element and that is a factor of the word size. The names of
  these types are of the form Integer_n for the signed types, and
  Unsigned_n for the modular types;

Re: What about big integers in Ada 2005?

[adaworks]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1928817.EZCl3m4u3t@linux1.krischik.com...
> Dennis Lee Bieber wrote:
>
> >         I'll admit I'm somewhat surprised GNAT (and likely others)
> > implemented fixed-point math using scaled integers -- rather than a BCD
> > package.
>
> I allways thought we have both:
>
> http://en.wikibooks.org/wiki/Ada_Programming/Types/delta
> http://www.adaic.com/standards/95lrm/html/RM-3-5-9.html
>
These citiations refer to the decimal type.   This type is still constrained
by the underlying hardware.   For example,

     type Decimal_Number is delta 0.001 digits 20;

will not compile under GNAT.

Dr. Beiber is correct in his suprise that Ada does not have a
straightforward approach to BCD.  Of course, few languages
do have this.   COBOL continues to be an easy approach to
solving business data processing problems that falls short in Ada,
C++, C, Java, and most other languages.    Somehow, the
designers of these languages just never quite understood this
simple idea.

Richard Riehle

Re: What about big integers in Ada 2005?

[Martin Dowie]

Simon Wright wrote:
> Martin Krischik <krischik@users.sourceforge.net> writes:
[snip]
>>   type Unsigned_64 is mod 2 ** 64;
>>   for Unsigned_64'Size use 64;
> 
> 
> This is GNAT. On the other hand, RM95 says

And note that for the same platform, different compilers provide 
different things, e.g. no 64-bit types in package Interfaces.

-- Martin

Re: What about big integers in Ada 2005?

[adaworks]

"Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
news:imsuj1h8vevg4un71rmh0nc41pnee5ihjl@4ax.com...
>
> Of course, my college mainframe actually had a 32-digit hardware BCD
> ALU (which failed one term -- COBOL classes were stuck, but FORTRAN,
> using integer and floating ALU hardware, proceeded apace).
>
> I'll admit I'm somewhat surprised GNAT (and likely others)
> implemented fixed-point math using scaled integers -- rather than a BCD
> package.
> -- 
I wonder if anyone has implemented a BCD package?  Also, in COBOL,
programmers routinely design using packed decimal.   I don't know of any
corresponding package in Ada.   I suspect this is one of the many reasons
Ada has consistently failed to win any support in the information systems
world.

Unfortunately, the Information Systems annex falls short of what COBOL
programmers really want.   Perhaps we could re-design the Information
Systems Annex someday to bring it into conformity with common IS
practice.  Probably too late.   The damage is already done.

Also, I am teaching a class in functional programming languages this Quarter
and wrote a little factorial program in Scheme that shows that we can do

            (factorial 45)

and get a perfectly good answer.   Anyone know of an Ada package that
can do that?

Richard Riehle

Re: What about big integers in Ada 2005?

[tmoran]

> I wonder if anyone has implemented a BCD package?
There's a package BCDOPS in an old (1988) RR Software manual, in the
Janus/Ada Library Routines section.  BCD_Fore and BCD_Aft appear to
default to 20 and 10.  It doesn't seem to be in the current Janus manual,
though.

Re: What about big integers in Ada 2005?

[Dmitry A. Kazakov]

On Tue, 04 Oct 2005 05:24:17 GMT, adaworks@sbcglobal.net wrote:

> "Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
> news:imsuj1h8vevg4un71rmh0nc41pnee5ihjl@4ax.com...
>>
>> Of course, my college mainframe actually had a 32-digit hardware BCD
>> ALU (which failed one term -- COBOL classes were stuck, but FORTRAN,
>> using integer and floating ALU hardware, proceeded apace).
>>
>> I'll admit I'm somewhat surprised GNAT (and likely others)
>> implemented fixed-point math using scaled integers -- rather than a BCD
>> package.
>> -- 
> I wonder if anyone has implemented a BCD package?  Also, in COBOL,
> programmers routinely design using packed decimal.   I don't know of any
> corresponding package in Ada.   I suspect this is one of the many reasons
> Ada has consistently failed to win any support in the information systems
> world.
>
> Unfortunately, the Information Systems annex falls short of what COBOL
> programmers really want.   Perhaps we could re-design the Information
> Systems Annex someday to bring it into conformity with common IS
> practice.  Probably too late.   The damage is already done.
> 
> Also, I am teaching a class in functional programming languages this Quarter
> and wrote a little factorial program in Scheme that shows that we can do
> 
>             (factorial 45)
> 
> and get a perfectly good answer.   Anyone know of an Ada package that
> can do that?

Curious, why somebody would like to use BCD for 45!? I cannot imagine any
use of BCD except than to speed up conversions to ASCII, which is not an
issue in these days. But even so, whoever is expected to read 45! on the
screen, he can always say - I did, though can't remember the 25th digit
from the left! (:-)) 

[decimal fixed point numbers is a different issue]

But I agree that Ada should have Universal_Integer or its equivalent
available for users. And this time one should not repeat errors made with
Unbounded_String!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: What about big integers in Ada 2005?

[Simon Clubley]

In article <1x4pe4pv41qsn$.m5c5jawjqcpq.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
> Curious, why somebody would like to use BCD for 45!? I cannot imagine any
> use of BCD except than to speed up conversions to ASCII, which is not an
> issue in these days.

One reason to use BCD is because it's a compact data representation.

One real world use of BCD that I have come across is in SMS messages where 
it is used to encode all the SMS message centre/destination/originating
telephone numbers in the SMS TPDU packets. (Details in SMS specification
GSM 03.40).

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       
Microsoft: The Standard Oil Company of the 21st century

Re: What about big integers in Ada 2005?

[adaworks]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1x4pe4pv41qsn$.m5c5jawjqcpq.dlg@40tude.net...
> On Tue, 04 Oct 2005 05:24:17 GMT, adaworks@sbcglobal.net wrote:
> >
> > Also, I am teaching a class in functional programming languages this Quarter
> > and wrote a little factorial program in Scheme that shows that we can do
> >
> >             (factorial 45)
> >
> > and get a perfectly good answer.   Anyone know of an Ada package that
> > can do that?
>
I apologize.  I did not mean to imply that BCD is the only way to do 45!  There
are better implementations possible.  The point was that this is not something
one can do with the present implementations of Ada.   Every compiler I know
of is limited by the word size of the platform.   Smalltalk, Lisp, Scheme, and
lots of other languages are at a level of abstraction better suited to the
representation of problems involving large numbers.
>
> But I agree that Ada should have Universal_Integer or its equivalent
> available for users. And this time one should not repeat errors made with
> Unbounded_String!
>
We are in agreement on this.  It can be done with a home-grown package,
but having implemented a partial version of it, I can say it is not a trivial
thing to do in Ada.
>
Richard Riehle

Re: What about big integers in Ada 2005?

[adaworks]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:1x4pe4pv41qsn$.m5c5jawjqcpq.dlg@40tude.net...
> On Tue, 04 Oct 2005 05:24:17 GMT, adaworks@sbcglobal.net wrote:
>
>  I cannot imagine any
> use of BCD except than to speed up conversions to ASCII, which is not an
> issue in these days. > [decimal fixed point numbers is a different issue]
>
I replying to this part of your message separately.

BCD, and its cousins, including packed decimal, are used widely in the
business data processing world.   Files are stored in these formats. At
present, it is rather a nuisance to try to use Ada for reading these files.
Not impossible, but not convenient either.

Richard Riehle

Re: What about big integers in Ada 2005?

[Larry Kilgallen]

In article <cMv0f.454$ht7.77@newssvr21.news.prodigy.com>, <adaworks@sbcglobal.net> writes:
> 
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:1x4pe4pv41qsn$.m5c5jawjqcpq.dlg@40tude.net...
>> On Tue, 04 Oct 2005 05:24:17 GMT, adaworks@sbcglobal.net wrote:
>>
>>  I cannot imagine any
>> use of BCD except than to speed up conversions to ASCII, which is not an
>> issue in these days. > [decimal fixed point numbers is a different issue]
>>
> I replying to this part of your message separately.
> 
> BCD, and its cousins, including packed decimal, are used widely in the
> business data processing world.   Files are stored in these formats. At
> present, it is rather a nuisance to try to use Ada for reading these files.
> Not impossible, but not convenient either.

DEC Ada (83) stores fixed-point decimal data in BCD (VMS packed decimal).

I would presume that GNAT for VMS does the same, as compatibility with
existing programs was an important consideration when it was ported.

Re: What about big integers in Ada 2005?

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> BCD, and its cousins, including packed decimal, are used widely in the
> business data processing world.   Files are stored in these formats. At
> present, it is rather a nuisance to try to use Ada for reading these files.
> Not impossible, but not convenient either.

But Ada _does_ support packed decimal -- see F.1(2).

By the way, what's the difference between packed decimal and BCD
-- I thought they were the same thing.  (...shows how much I know
about business data processing)

- Bob

Re: What about big integers in Ada 2005?

[Robert A Duff]

clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:

> In article <1x4pe4pv41qsn$.m5c5jawjqcpq.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> > Curious, why somebody would like to use BCD for 45!? I cannot imagine any
> > use of BCD except than to speed up conversions to ASCII, which is not an
> > issue in these days.
> 
> One reason to use BCD is because it's a compact data representation.

Heh?  Binary is more compact that BCD.

I think the only reason to use BCD these days (instead of binary) is to
interface to something that uses BCD.  In the old days, another reason
was to avoid the cost of converting strings to binary integers and
vice-versa, but that seems like an obsolete reason at this 

Am I right?

> One real world use of BCD that I have come across is in SMS messages where 
> it is used to encode all the SMS message centre/destination/originating
> telephone numbers in the SMS TPDU packets. (Details in SMS specification
> GSM 03.40).

But one does not normally do arithmetic on telephone numbers,
so considering them "numbers" is questionable.  You could do
it this way:

    type Digit is ('0', '1', '2', '3', '4', '5', '6', '7', '8', '9');
    type Phone_Number is array (...) of Digit;
    for Phone_Number'Component_Size use 4;

- Bob

Re: What about big integers in Ada 2005?

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> We are in agreement on this.  It can be done with a home-grown package,
> but having implemented a partial version of it, I can say it is not a trivial
> thing to do in Ada.

True.  The only really hard one is division -- it takes a couple hundred
lines of arcane code.  But you can copy the algorithms out of Knuth.

Anyway, why not use the GNAT compiler's version?

- Bob

Re: What about big integers in Ada 2005?

[Martin Dowie]

Robert A Duff wrote:
> <adaworks@sbcglobal.net> writes:
> 
> 
>>We are in agreement on this.  It can be done with a home-grown package,
>>but having implemented a partial version of it, I can say it is not a trivial
>>thing to do in Ada.
> 
> 
> True.  The only really hard one is division -- it takes a couple hundred
> lines of arcane code.  But you can copy the algorithms out of Knuth.
> 
> Anyway, why not use the GNAT compiler's version?

<mischief>
Coz these days its GPL! :->
</mischief>

Re: What about big integers in Ada 2005?

[Robert A Duff]

Martin Dowie <martin.dowie@btopenworld.com> writes:

> > Anyway, why not use the GNAT compiler's version?
> 
> <mischief>
> Coz these days its GPL! :->
> </mischief>

You're being a trouble maker!  ;-) ;-)

But seriously: the version in the gcc tree is still GMGPL, is it not?
And I doubt if AdaCore is actively fixing bugs in that particular
package -- it might well be identical in all versions going back
some time.

- Bob

Re: What about big integers in Ada 2005?

[Simon Clubley]

In article <wccmzlpclgd.fsf@shell01.TheWorld.com>, Robert A Duff <bobduff@shell01.TheWorld.com> writes:
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:
> 
>> In article <1x4pe4pv41qsn$.m5c5jawjqcpq.dlg@40tude.net>, "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> > 
>> > Curious, why somebody would like to use BCD for 45!? I cannot imagine any
>> > use of BCD except than to speed up conversions to ASCII, which is not an
>> > issue in these days.
>> 
>> One reason to use BCD is because it's a compact data representation.
> 
> Heh?  Binary is more compact that BCD.
> 

Oops, bad choice of wording on my part. When I wrote that, I thinking of
the telephone number example (I've just written code to generate SMS TPDU
packets), and was not thinking of encoding a full size integer.

(SMS packs 2 telephone digits into a single octet in order to reduce
the size of the packet.)

> I think the only reason to use BCD these days (instead of binary) is to
> interface to something that uses BCD.  In the old days, another reason
> was to avoid the cost of converting strings to binary integers and
> vice-versa, but that seems like an obsolete reason at this 
> 
> Am I right?

How would you choose to implement big number packages ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       
Microsoft: The Standard Oil Company of the 21st century

Re: What about big integers in Ada 2005?

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccr7b1clr7.fsf@shell01.TheWorld.com...
> <adaworks@sbcglobal.net> writes:
>
> > BCD, and its cousins, including packed decimal, are used widely in the
> > business data processing world.   Files are stored in these formats. At
> > present, it is rather a nuisance to try to use Ada for reading these files.
> > Not impossible, but not convenient either.
>
> But Ada _does_ support packed decimal -- see F.1(2).
>
> By the way, what's the difference between packed decimal and BCD
> -- I thought they were the same thing.  (...shows how much I know
> about business data processing)
>
BCD was originally a six bit (where 7 was a parity bit) representation.  With
the advent of the byte on the IBM System 360, BCD became Extended Binary
Coded Decimal Interchange Code (EBCDIC).

In COBOL for the 360, we had several Picture clauses available.

     05 Item-1       PICTURE   XXX .            which would be represented by
EBCDIC
     05 Number     PICTURE   S99999.         which would also be EBCDIC
     05 Hnumber   PICTURE   S99999 Usage Comp-3. which would be packed

decimal.

COMP-3 represented the numeric PICTURE by using a half-byte (nibble) for each 9
in the picture and a nibble for the sign.   In the example shown, Hnumber would
occupy
only three bytes where Number would occupy five bytes.   In both cases, the
high-order
nibble is used for the sign.

There are actually some additional formats available including USAGE
COMPUTATIONAL
which is the same as representing a value in pure binary within the size of a
word.

I could write for a couple of hours on this topic, but I think this gets the
gist of the issue.

The central problem is that business data processing people use all of these
formats
at one time or another.

Richard Riehle

Re: What about big integers in Ada 2005?

[Robert A Duff]

clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) writes:

> > I think the only reason to use BCD these days (instead of binary) is to
> > interface to something that uses BCD.  In the old days, another reason
> > was to avoid the cost of converting strings to binary integers and
> > vice-versa, but that seems like an obsolete reason at this 
> > 
> > Am I right?
> 
> How would you choose to implement big number packages ?

I have implemented such a thing, and I used all manner of low-level
trickery to make it efficient.  Of course what's "efficient" depends on
typical usage patterns, such as:

    1. Almost all numbers are small (fit comfortably in one machine
       word).

    2. Extremely large numbers are common.  Lots of arithmetic,
       comparisons, etc.

    3. Not so much arithmetic, etc.  Lots of conversions back and forth
       to human-readable text strings.

My scanario was number 1.  I won't go into all the details, but
basically a big int is a word, containing a small number, plus
some flag bits, or a pointer to a big number, plus some flag bits.
The pointer points to a heap-allocated array of "super digits".
Each super digit is half a 32-bit word.  In other words,
we're using base 2**16.

It would be more efficient to use base 2**32, but that would have
required non-portable machine code inserts or something, because Ada
doesn't give access to the necessary machine instructions (double-length
multiply, for example).

For scenario 2, I suppose the small-int hack would be a waste -- just
make it a pointer to the array.

For scenario 3, base 1_000_000_000 would be more efficient.
Or base 10_000, if you're doing the half-word thing.

I still don't see a really good reason to use base 10.

- Bob

Re: What about big integers in Ada 2005?

[Adrian Hoe]

adaworks@sbcglobal.net wrote:
> "Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
> news:imsuj1h8vevg4un71rmh0nc41pnee5ihjl@4ax.com...
> >
> > Of course, my college mainframe actually had a 32-digit hardware BCD
> > ALU (which failed one term -- COBOL classes were stuck, but FORTRAN,
> > using integer and floating ALU hardware, proceeded apace).
> >
> I wonder if anyone has implemented a BCD package?  Also, in COBOL,
> programmers routinely design using packed decimal.   I don't know of any
> corresponding package in Ada.   I suspect this is one of the many reasons
> Ada has consistently failed to win any support in the information systems
> world.
>
> Unfortunately, the Information Systems annex falls short of what COBOL
> programmers really want.   Perhaps we could re-design the Information
> Systems Annex someday to bring it into conformity with common IS
> practice.  Probably too late.   The damage is already done.


I thought Swiss Bank is using some software developed in Ada. If I
recall correctly, Paranor was the developer. How did they do that if IS
Annex falls short?

I remember that I asked for BCD package sometime ago and someone
responded. But my project ditched the idea of using BCD and I did not
have to pursue in BCD then.

--
Adrian Hoe

Re: What about big integers in Ada 2005?

[Martin Krischik]

Adrian Hoe wrote:

> adaworks@sbcglobal.net wrote:
>> "Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message
>> news:imsuj1h8vevg4un71rmh0nc41pnee5ihjl@4ax.com...
>> >
>> > Of course, my college mainframe actually had a 32-digit hardware BCD
>> > ALU (which failed one term -- COBOL classes were stuck, but FORTRAN,
>> > using integer and floating ALU hardware, proceeded apace).
>> >
>> I wonder if anyone has implemented a BCD package?  Also, in COBOL,
>> programmers routinely design using packed decimal.   I don't know of any
>> corresponding package in Ada.   I suspect this is one of the many reasons
>> Ada has consistently failed to win any support in the information systems
>> world.
>>
>> Unfortunately, the Information Systems annex falls short of what COBOL
>> programmers really want.   Perhaps we could re-design the Information
>> Systems Annex someday to bring it into conformity with common IS
>> practice.  Probably too late.   The damage is already done.
> 
> 
> I thought Swiss Bank is using some software developed in Ada. If I
> recall correctly, Paranor was the developer. How did they do that if IS
> Annex falls short?

Well, it's the Swiss PostFinance. But there is not much interfacing with
COBOL - it's all done Ada.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: What about big integers in Ada 2005?

[Dave Thompson]

On Tue, 04 Oct 2005 18:56:20 GMT, <adaworks@sbcglobal.net> wrote:
<snip>
> BCD was originally a six bit (where 7 was a parity bit) representation.  With
> the advent of the byte on the IBM System 360, BCD became Extended Binary
> Coded Decimal Interchange Code (EBCDIC).
> 
The 6-bit character code was BCDIC -- Binary Coded Decimal Interchange
Code.  With the advent of _8-bit_ bytes on S/360 it became EBCDIC.

BCD was/is any representation that uses 4-bits for each decimal digit,
hence the name. That can be an outright 4-bit processor like the
original 4004; 4-bits in a 6-bit (BCDIC) or 8-bit (EBCDIC) or 7-bit
(ASCII) character; or 2 4-bit nibbles packed in an 8-bit byte.

> In COBOL for the 360, we had several Picture clauses available.
> 
>      05 Item-1       PICTURE   XXX .            which would be represented by
> EBCDIC
>      05 Number     PICTURE   S99999.         which would also be EBCDIC
>      05 Hnumber   PICTURE   S99999 Usage Comp-3. which would be packed
> 
> decimal.
> 
> COMP-3 represented the numeric PICTURE by using a half-byte (nibble) for each 9
> in the picture and a nibble for the sign.   In the example shown, Hnumber would
> occupy
> only three bytes where Number would occupy five bytes.   In both cases, the
> high-order
> nibble is used for the sign.
> 
Not that last; the S/360 decimal instructions (AP, SP, etc.) put the
sign in the low-order nibble, namely the low half of the highest
addressed byte, which is the low-valued one on big-endian S/360.

For DISPLAY numeric the sign is in the high nibble aka 'zone' of _one_
byte, IIRC the low-order (high-address) one by default but you can
specify SIGN [IS] LEADING | TRAILING .

> There are actually some additional formats available including USAGE
> COMPUTATIONAL
> which is the same as representing a value in pure binary within the size of a
> word.
> 
Pure binary, but IIRC fullword or halfword depending on digits.

And [DISPLAY] numeric with SIGN ... [IS] SEPARATE a full byte for each
digit _plus_ one for sign.  (And numeric edited even more, but that's
no longer just a number representation anyway.)

> I could write for a couple of hours on this topic, but I think this gets the
> gist of the issue.
> 
> The central problem is that business data processing people use all of these
> formats
> at one time or another.
> 

- David.Thompson1 at worldnet.att.net

Re: What about big integers in Ada 2005?

[adaworks]

"Dave Thompson" <david.thompson1@worldnet.att.net> wrote in message
news:bpujk1998r48p79n5jh1jtfgm42jl3ei8r@4ax.com...
> On Tue, 04 Oct 2005 18:56:20 GMT, <adaworks@sbcglobal.net> wrote:
> <snip>
> > BCD was originally a six bit (where 7 was a parity bit) representation.
With
> > the advent of the byte on the IBM System 360, BCD became Extended Binary
> > Coded Decimal Interchange Code (EBCDIC).
> >
> The 6-bit character code was BCDIC -- Binary Coded Decimal Interchange
> Code.  With the advent of _8-bit_ bytes on S/360 it became EBCDIC.
>
On the IBM 1401 and IBM 7080, we used the term Binary Coded Decimal
(BCD) for the six bit character.   BCDIC may have been the term on other
machines -- or perhaps we were simply using a short-cut name, but this
was how it was named in the IBM literature we were given.
>
> >
> > COMP-3 represented the numeric PICTURE by using a half-byte (nibble) for
each 9
> > in the picture and a nibble for the sign.   In the example shown, Hnumber
would
> > occupy
> > only three bytes where Number would occupy five bytes.   In both cases, the
> > high-order
> > nibble is used for the sign.
> >
> Not that last; the S/360 decimal instructions (AP, SP, etc.) put the
> sign in the low-order nibble, namely the low half of the highest
> addressed byte, which is the low-valued one on big-endian S/360.
>
Yes.  You are right.  It has been a long time since I have programmed
the S/360.   Now, do remember the bizzare format for a floating-point
number on the VAX.   I once had to convert VAX code to S/360 and
it was, at first, a bit of a nightmare.
>
Richard Riehle