precise floats

precise floats

[Bob Fletcher]

What is the best way to define a float type that has greater precision,
(like a lot greater), than the default one? Is there a simple way to do
this?

Re: precise floats

[Corey Ashford]

Bob Fletcher wrote in message <6q7vtb$jk$1@heliodor.xara.net>...
>What is the best way to define a float type that has greater precision,
>(like a lot greater), than the default one? Is there a simple way to do
>this?
>
>

The most straight-forward and portable way is to use a declaration
like:

type my_big_float is digits 12;

If the compiler doesn't have an underlying type that supports that
precision it will tell you so.

If you need more precision than can be provided by the hardware and
compiler, you'll probably obtain some extended precision arithmetic
packages.

- Corey

Re: precise floats

[Corey Ashford]

Corey Ashford wrote in message
[snip]
>If you need more precision than can be provided by the hardware and
>compiler, you'll probably obtain some extended precision arithmetic
>packages.


Typo.

I meant:

If you need more precision than can be provided by the hardware and
compiler, you'll need to obtain some extended precision arithmetic
packages.

- Corey

Re: precise floats

[Frank Klemm]

On Tue, 4 Aug 1998 18:00:36 -0700, Corey Ashford <yeroca@rocketmail.com> wrote:
>
>If you need more precision than can be provided by the hardware and
>compiler, you'll need to obtain some extended precision arithmetic
>packages...
>
... which will slow down your computation by at least a factor of 100.

What about support of the 3 floating point types of the x86 architecture,
32-bit IEEE (7 digits), 64-bit IEEE (16 digits) and the internal FPU format
(19 digits).

Most compilers do *not* support the last.

-- 
Frank Klemm

 /------\  /-----------------------------------------------------\
| eMail: || pfk@uni-jena.de | home: pfk@schnecke.offl.uni-jena.de |
| Tel:   ||                 | home: +49 (3641) 390545             |
| sMail: ||  Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany   |
 \------/  \-----------------------------------------------------/

Re: precise floats

[Robert Dewar]

Frank said

<<What about support of the 3 floating point types of the x86 architecture,
32-bit IEEE (7 digits), 64-bit IEEE (16 digits) and the internal FPU format
(19 digits).

Most compilers do *not* support the last.
>>

I am very surprised if that last statement is true. Most certainly GNAT
supports the extended precision type on the x86 (it is called Long_Long_Float).

Note that any compiler not supporting this type is not a conforming
implementation. B.2(10) is a normative requirement:

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

    8  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;

    9  For each such modular type in Interfaces, shifting and rotating
       subprograms as specified in the declaration of Interfaces above.
       These subprograms are Intrinsic.  They operate on a bit-by-bit
       basis, using the binary representation of the value of the
       operands to yield a binary representation for the result.  The
       Amount parameter gives the number of bits by which to shift or
       rotate.  For shifting, zero bits are shifted in, except in the
       case of Shift_Right_Arithmetic, where one bits are shifted in if
       Value is at least half the modulus.

   10  Floating point types corresponding to each floating point format
       fully supported by the hardware.

If your vendor claims conformance to the standard, or claims validated
status, then the failure to support this type should be reported as a
(serious in my view) bug. Note that no vendor can reasonably sign the
declaration of conformance for validation if they are aware of this
serious omission.

Note that in accordance with the standard, GNAT provides this type in
Interfaces, where it is called IEEE_Extended_Float.

In accordance with the implementation permission of 3.5.7(16), we also
provide this type in Standard with the name Long_Long_Float. We quite
realize that this is not in accordance with the implementation advice
in 3.5.7(17), but we consider this bad advice, since it seems clear to
us that this type should be a first class citizen, as it is in GNU C
(where it is the type long double).

Robert Dewar
Ada Core Technologies

Re: precise floats

[dennison]

In article <dewar.902412781@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> Note that any compiler not supporting this type is not a conforming
> implementation. B.2(10) is a normative requirement:
>
> 7   An implementation shall provide the following declarations in the visible
> part of package Interfaces:
...
>    10  Floating point types corresponding to each floating point format
>        fully supported by the hardware.
>
> If your vendor claims conformance to the standard, or claims validated
> status, then the failure to support this type should be reported as a
> (serious in my view) bug. Note that no vendor can reasonably sign the
> declaration of conformance for validation if they are aware of this
> serious omission.

The Ada.Interfaces package that comes with ObjectAda 7.1.1 for windows/Intel
contains *no* floating-point types whatsoever. (It is also quite different
that the verion they printed out in Annex M of their docs. In particular the
16 and 8 bit integers don't appear to exist in the actual package spec.)

So are you saying I need to report this as a bug? It would be my 3rd report in
a month (1st this month, though).

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: precise floats

[paul.english]

dennison@telepath.com writes:

> The Ada.Interfaces package that comes with ObjectAda 7.1.1 for
> windows/Intel contains *no* floating-point types whatsoever. (It is
> also quite different that the verion they printed out in Annex M of
> their docs. In particular the 16 and 8 bit integers don't appear to
> exist in the actual package spec.)

The Ada.Interfaces package that came with ObjectAda 7.1.1
(ObjectAda/lib/src/INTERF$1.ADS) contains the following definitions:

    type Integer_32 is range -2**31 .. 2**31-1;  --2's complement
    type Integer_16 is range -2**15 .. 2**15-1;  --2's complement
    type Integer_8  is range -2**7  .. 2**7 -1;  --2's complement

    type Unsigned_32 is mod 2**32;
    type Unsigned_16 is mod 2**16;
    type Unsigned_8  is mod 2**8;

    type IEEE_Float_32 is new FLOAT;
    type IEEE_Float_64 is new LONG_FLOAT;

This is the same as the Annex M, with the exception of the IEEE
Floating point types, which aren't in Annex M.  Are you sure you are
looking at the right version of the spec?

> So are you saying I need to report this as a bug? It would be my 3rd
> report in a month (1st this month, though).

That I can believe, it's about in keeping with my experience of OA so
far.

Cheers,

-- 
                                        ,    , 
                                       ("\''/").___..--''" -._ 
Paul English                           `9_ 9  )   `-.  (     ).`-.__.') 
paul.english@NOSPAM.technologist.com   (_Y_.)'  ._   )   ._  . ``-..-' 
(delete NOSPAM. to mail me)          _..`--'_..-_/  /--'_.' .' 
                                    (il).-''  ((i).'  ((!.-' 

Re: precise floats

[Robert Dewar]

Paul said

<<The Ada.Interfaces package that came with ObjectAda 7.1.1
(ObjectAda/lib/src/INTERF$1.ADS) contains the following definitions:

    type Integer_32 is range -2**31 .. 2**31-1;  --2's complement
    type Integer_16 is range -2**15 .. 2**15-1;  --2's complement
    type Integer_8  is range -2**7  .. 2**7 -1;  --2's complement

    type Unsigned_32 is mod 2**32;
    type Unsigned_16 is mod 2**16;
    type Unsigned_8  is mod 2**8;

    type IEEE_Float_32 is new FLOAT;
    type IEEE_Float_64 is new LONG_FLOAT;
>>


That's reasonable, and the names here are expected (since they correspond
to the the implementation note B.2(10.a) in the AARM). Note that purists
might object to the appearence of IEEE rather than the proper ISO name
here, but in practice everyone talks about IEEE floating-point (it has
been one of the real name recognition successes for IEEE :-)

However, the above definitions are most certainly inadequate on the x86.
This machine fully supports the 80-bit floating-point format corresponding
the optional IEEE extended type. Indeed all arithmetic in the fpt chip is
in fact performed in this mode. The ia32 (x86) is essentially the only widely
used chip that has this extended precision, and it is an extremely important
capability, since it allows algorithms to be used that otherwise would not
be usable (e.g. you cannot compute x**y using log/exp without introducing
horrible errors, but if you use extended precision to compute x**y using
log/exp, you can get accurate 64-bit answers -- see chapter 5 of my book
Microprocessors: A Programmer's View, McGraw Hill 1990 for details).

This type then is most definitely covered by the requirement in B.2(10),
and for an x86 implementation, must be defined in Interfaces. The relevant
definitions from the GNAT version of Interfaces are

   type IEEE_Float_32       is new Short_Float;
   pragma Float_Representation (IEEE_Float, IEEE_Float_32);

   type IEEE_Float_64       is new Long_Float;
   pragma Float_Representation (IEEE_Float, IEEE_Float_64);

   type IEEE_Extended_Float is new Long_Long_Float;
   pragma Float_Representation (IEEE_Float, IEEE_Extended_Float);

and Long_Long_Float is indeed the 80-bit format on the x86. Note that it is
usually the case that Long_Long_Float is the same as long double in C. However
this is not always the case. On the SPARC, where the 128-bit format is NOT
supported by the hardware, we consider that the proper approach is not to 
provide this 128-bit format as a first class citizen in the world of
base types that are intended to reflect the types implemented in the hardware.

Note: some people sometimes get confused into thinking that somehow the
80-bit format is "reserved" and should not be used. This derives from the
intention in the IEEE-754 standard that the extended format be used for
the purposes of getting accurate 64-bit results (e.g. in the log/exp
case above).

However, this is not an excuse for disobeying B.2(10), because:

(a) this is only an intention reflected in the design of 754, which is in
no way reflected in the hardware, and is essentially just programming 
advice which a programmer is free to ignore. If your application will
successfully run using 64-bit mantissa precision and not 53-bit mantissa
precision, then you will be happy to find out that the x86 (and incidentally
the forthcoming ia64 [merced]) satisfy your needs, and you will not be happy
to find that your Ada compiler arbitrarily eliminates this possibility.

(b) code that reflects the intention of IEEE-754 and uses the extended format
for intermediate results in the intended manner may perfectly well be
written in Ada!

Note that I have no idea what other Ada compilers do here. All I know is
that the standard mandates the inclusion of the 80-bit format in the
Interfaces definition for a conforming Ada 95 compiler for the x86.
We have already seen that people can get confused when they tell us
what is and what is not in some particular compiler. So you should check
for yourself to make sure that your compiler meets this requirement. It
is indeed a requirement that should be checked by the validation suite,
but in practice this kind of checking is hard. You can parametrize the
validation suite by specifying the maximum fpt precision, but it is 
difficult to check that this parametrization is done correctly when
it is machine dependent.

Robert Dewar
Ada Core Technologies

Re: precise floats

[Kevin Radke]

In article <dewar.902579704@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Paul said
...
>This type then is most definitely covered by the requirement in B.2(10),
>and for an x86 implementation, must be defined in Interfaces. The relevant
>definitions from the GNAT version of Interfaces are
>
>   type IEEE_Float_32       is new Short_Float;
>   pragma Float_Representation (IEEE_Float, IEEE_Float_32);
>
>   type IEEE_Float_64       is new Long_Float;
>   pragma Float_Representation (IEEE_Float, IEEE_Float_64);
>
>   type IEEE_Extended_Float is new Long_Long_Float;
>   pragma Float_Representation (IEEE_Float, IEEE_Extended_Float);
...
>Note that I have no idea what other Ada compilers do here. All I know is
>that the standard mandates the inclusion of the 80-bit format in the
>Interfaces definition for a conforming Ada 95 compiler for the x86.
>We have already seen that people can get confused when they tell us
>what is and what is not in some particular compiler. So you should check
>for yourself to make sure that your compiler meets this requirement. It
>is indeed a requirement that should be checked by the validation suite,
>but in practice this kind of checking is hard. You can parametrize the
>validation suite by specifying the maximum fpt precision, but it is 
>difficult to check that this parametrization is done correctly when
>it is machine dependent.

It appears Apex 1.0.2b and Green Hills AdaMulti 1.8.8e (both
Windows NT native targets) fail to provide an IEEE_Extended_Float
as well. (I don't think this Apex version claims validation,
however I could be wrong.)

Kevin

Re: precise floats

[Gene Ouye]

Robert Dewar wrote:
 [...]
> However, the above definitions are most certainly inadequate on the x86.
> This machine fully supports the 80-bit floating-point format corresponding
> the optional IEEE extended type. Indeed all arithmetic in the fpt chip is
> in fact performed in this mode.

I've gone through the 486, Pentium, and Pentium II manuals looking for
something that shows the 80-bit floating-point format is "fully
supported" and I don't see it.  True, all FP operations are performed on
numbers internally converted to the 80-bit format, and it is possible to
load and store 80-bit FP numbers, but all the other FP operations FP
numbers can only take operands from memory that are 64 bits or smaller
(eg, FADD, FCOM, FCOMP, FDIV, FDIVR, FMUL, FSUB, FSUBR).

 [...]
> Note: some people sometimes get confused into thinking that somehow the
> 80-bit format is "reserved" and should not be used. This derives from the
> intention in the IEEE-754 standard that the extended format be used for
> the purposes of getting accurate 64-bit results (e.g. in the log/exp
> case above).

I am not confused between the IEEE-754 standard and the Intel
Architecture Software Developer's Manual Volume 2: Instruction Set
Reference or the Pentium Processor Family Developer's Manual Volume 3:
Architecture and Programming Manual.  Those Intel manuals and others I
have examined do not make any claims that the 80-bit FP type is "fully
supported", and an examination of all the operations available to the
Pentium or 486 programmer does not lead me to the conclusion that the
80-bit FP type is "fully supported".

What am I missing?

Gene Ouye

Re: precise floats

[dennison]

In article <uu33pxltv.fsf@sg.adisys.com.au>,
  paul.english@NOSPAM.technologist.com wrote:
> The Ada.Interfaces package that came with ObjectAda 7.1.1
> (ObjectAda/lib/src/INTERF$1.ADS) contains the following definitions:
>
>     type IEEE_Float_32 is new FLOAT;
>     type IEEE_Float_64 is new LONG_FLOAT;
>
> This is the same as the Annex M, with the exception of the IEEE
> Floating point types, which aren't in Annex M.  Are you sure you are
> looking at the right version of the spec?

Interesting. I was looking at another version of the same package at
ObjectAda/ajb/Interfac.ads. So there are now 3 known versions of this package:
One in their documentation and two in their source distribution. %-(

Thanks for pointing me in the right direction.

T.E.D.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: precise floats

[Robert Dewar]

<<The Ada.Interfaces package that comes with ObjectAda 7.1.1 for windows/Intel
contains *no* floating-point types whatsoever. (It is also quite different
that the verion they printed out in Annex M of their docs. In particular the
16 and 8 bit integers don't appear to exist in the actual package spec.)

So are you saying I need to report this as a bug? It would be my 3rd report in
a month (1st this month, though).
>>

The annex B requirements are perfectly clear, if Interfaces has no
floating-point types, this is valid only if the hardware does not
support floating-point at all. So this is most certainly a bug.

Re: precise floats

[Tom Weis]

Frank said
<<What about support of the 3 floating point types of the x86
architecture,
 32-bit IEEE (7 digits), 64-bit IEEE (16 digits) and the internal FPU
format
 (19 digits).
 
 Most compilers do *not* support the last.>>

Robert said
<<I am very surprised if that last statement is true. Most certainly
GNAT
 supports the extended precision type on the x86 (it is called
Long_Long_Float).
 
 Note that any compiler not supporting this type is not a conforming
 implementation. B.2(10) is a normative requirement:
 
    10  Floating point types corresponding to each floating point format
        fully supported by the hardware.>>

Does GNAT support the IEEE representations of infinities and
Not-A-Number (nan) specified in "IEEE Standard for Binary Floating-Point
Arithmetic ANSI/IEEE Std 754-1985" or "IEEE Standard for
Radix-Independent Floating-Point Arithmetic ANSI/IEEE Std 854-1987"?

Re: precise floats

[Robert Dewar]

<<Does GNAT support the IEEE representations of infinities and
Not-A-Number (nan) specified in "IEEE Standard for Binary Floating-Point
Arithmetic ANSI/IEEE Std 754-1985" or "IEEE Standard for
Radix-Independent Floating-Point Arithmetic ANSI/IEEE Std 854-1987"?
>>

This is a potentially target dependent question, but in general, yes,
in most GNAT implementations, Machine_Overflows is false, and we generate
appropriate code to generate and handle infinities and NaN's. 

Re: precise floats

[David C. Hoos, Sr.]

Bob Fletcher wrote in message <6q7vtb$jk$1@heliodor.xara.net>...
>What is the best way to define a float type that has greater precision,
>(like a lot greater), than the default one? Is there a simple way to do
>this?
Well, whether it's simple depends on several things, e.g.:

    About what platform do you speak?
    Which compiler?
    How much is a _lot_ more?

For example, for some platform/compiler combinations, IEEE 32-bit floats are
the default Float type, while Long_Float is IEEE 64-bit.  Is 64-bit a _lot_
more than 32?

If you want something more than what is supported by the hardware, then it
certainly is no longer simple.  I don't know whether there are any arbitrary
precision Ada packages around.

David C. Hoos, Sr.

Re: precise floats

[Bob Fletcher]

David C. Hoos, Sr. wrote in message ...
>
>    About what platform do you speak?
>    Which compiler?
>    How much is a _lot_ more?
>


I'm using the GNAT compiler on Win32.

What I really need is a float that can comfortably deal with a signed value
with up to maybe as much as 30 or 40 decimal places.

Re: precise floats

[Christopher Green]

In article <6q7vtb$jk$1@heliodor.xara.net>,
Bob Fletcher <bob@radge.nospam.globalnet.co.uk> wrote:
>What is the best way to define a float type that has greater precision,
>(like a lot greater), than the default one? Is there a simple way to do
>this?

    type my_very_precise_type is digits <N>;

where <N> is the number of digits of precision you need.  Be aware, however,
that few compilers support float types of precision greater than 15 digits.

If you have an application that depends on floating-point calculations of
very high precision, be especially careful in numerical analysis, design,
and testing.  Don't accept vendor's claims that their numerical libraries
perform correctly; test them in computations that are required in your
application.

-- 
Chris Green                                  Email cgreen@atc.com
Advanced Technology Center                   Phone (949) 583-9119
22982 Mill Creek Drive                                   ext. 220
Laguna Hills, CA 92653                       Fax   (949) 583-9213

Re: precise floats

[Matthew Heaney]

"Bob Fletcher" <bob@radge.nospam.globalnet.co.uk> writes:

> What is the best way to define a float type that has greater precision,
> (like a lot greater), than the default one? Is there a simple way to do
> this?

How about

   type Max_Float is digits System.Max_Digits;

Is that what you had in mind?

Re: precise floats

[Bob Fletcher]

Thanks for all the advice, it's nice to see I posted something that sparked
a bit of a discussion :)

Anyway, I got the program I needed the floats for working, it's just a
little sample program for Jerry van Dijk's AdaGraph tool that plots the
mandelbrot set & lets you zoom in on bits of it.

http://www.users.globalnet.co.uk/~radge/files/mandel.zip

Bob Fletcher
(remove the 'nospam' from the reply address to email me)
http://www.users.globalnet.co.uk/~radge/

Re: precise floats

[Robert Dewar]

C Green said
<<
  In article <6q7vtb$jk$1@heliodor.xara.net>,
  Bob Fletcher <bob@radge.nospam.globalnet.co.uk> wrote:
    What is the best way to define a float type that has greater precision,
    (like a lot greater), than the default one? Is there a simple way to do
    this?
  
      type my_very_precise_type is digits <N>;
  
  where <N> is the number of digits of precision you need.  Be aware, however,
  that few compilers support float types of precision greater than 15 digits.
>>

Surely better advice is

     type my_very_precise_type is System.Max_Digits;

<<
  If you have an application that depends on floating-point calculations of
  very high precision, be especially careful in numerical analysis, design,
  and testing.  Don't accept vendor's claims that their numerical libraries
  perform correctly; test them in computations that are required in your
  application.
>>

or insist on Annex G validation. For almost all purposes, the ACVC
validation tests for accuracy of elementary functions should prove
adequate.

Re: precise floats

[Corey Ashford]

Robert Dewar wrote in message ...
>C Green said
><<
>  In article <6q7vtb$jk$1@heliodor.xara.net>,
>  Bob Fletcher <bob@radge.nospam.globalnet.co.uk> wrote:
>    What is the best way to define a float type that has greater precision,
>    (like a lot greater), than the default one? Is there a simple way to do
>    this?
>
>      type my_very_precise_type is digits <N>;
>
>  where <N> is the number of digits of precision you need.  Be aware, however,
>  that few compilers support float types of precision greater than 15 digits.
>>>
>
>Surely better advice is
>
>     type my_very_precise_type is System.Max_Digits;
[snip]

I think this is bad advice.

You want to find out at compile time whether or not the compiler
supports the precision you need, not at runtime where the system may
start behaving in mysterious ways because of inadequate precision.

I suppose it's another story if you just want the maximum precision that
the hardware allows.  I think that'd be a rare case though.

- Corey

Re: precise floats

[Samuel Mize]

In article <dewar.902417129@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>C Green said
>      type my_very_precise_type is digits <N>;
>  
>  where <N> is the number of digits of precision you need.  Be aware, however,
>  that few compilers support float types of precision greater than 15 digits.
>>>
>
>Surely better advice is
>
>     type my_very_precise_type is System.Max_Digits;

Assuming you want the greatest possible accuracy, perhaps best would be

  type my_very_precise_type is System.Max_Digits;

  subtype Fail_If_Not_Precise_Enough
    is my_very_precise_type digits <N>;

So your variables will have the max precision available, and the
compiler will warn you if it can't give you at least N digits.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam

Re: precise floats

[Matthew Heaney]

smize@news.imagin.net (Samuel Mize) writes:

> Assuming you want the greatest possible accuracy, perhaps best would be
> 
>   type my_very_precise_type is System.Max_Digits;
> 
>   subtype Fail_If_Not_Precise_Enough
>     is my_very_precise_type digits <N>;
> 
> So your variables will have the max precision available, and the
> compiler will warn you if it can't give you at least N digits.

Reduced accuracy subtypes are a deprecated feature (see RM95 J.3), so I
recommend not doing this.

Actually, it's not necessary anyway.  The compiler will reject the
declaration 

   type Fail_If_Not_Precise_Enough is digits N;

if it can't give you at least N digits.

Re: precise floats

[Robert Dewar]

Matthew said

<<Actually, it's not necessary anyway.  The compiler will reject the
declaration

   type Fail_If_Not_Precise_Enough is digits N;

if it can't give you at least N digits.
>>


The whole idea of requesting the precision you need at this level of
detail (number of decimal digits) is to me a bit bogus. It sounds good
if you are not doing serious numerical analysis, but in real life the
idea that you sit down with your program, figure out you need 12 digits,
then ask for it, and hope to get it, is very rarely the case.

Indeed there are quite a few algorithms where even if you could do this
kind of analysis, it would not work, because these algorithms fail if
you have too much precision. In general extra unwanted precision can
be quite an enemy to efficient floating-point code.

Especially in these days where virtually all machines use IEEE float formats,
even if they (increasingly, GRRR) don't provide 100% full IEEE arithmetic
semantics, the whole business about taking a high level abstract view of
precision requirements is dubious.