Re: Floating point, again...

> >> Mosher's code isn't always-correct; it even
given an error bound in the
> >> source.
> >
> > You means this?
> >
> > /* Multiply by 10**nexp.  If precision is 64
bits,
> >  * the maximum relative error incurred in forming
10**n
> >  * for 0 <= n <= 324 is 8.2e-20, at
10**180.
> >  * For 0 <= n <= 999, the peak relative
error is 1.4e-19 at 10**947.
> >  * For 0 >= n >= -999, it is -1.55e-19 at
10**-435.
> >  */
> >
> > I did try 10e180, 10e947, and 10e-435 -- for those
three acfloat3
> > does match what his ieee.c spits out.
>
> Yes, and they're both wrong, that was the point.

Uhm... gcc happens to match his results for these three
numbers:

>cat c.c
#include <stdio.h>

int main ( void ) {
 double d1 = 10e180;
 double d2 = 10e947;
 double d3 = 10e-435;

 printf ( "d1=%016llXn", * ( long long unsigned
int * ) &d1 );
 printf ( "d2=%016llXn", * ( long long unsigned
int * ) &d2 );
 printf ( "d3=%016llXn", * ( long long unsigned
int * ) &d3 );
}

>gcc c.c -o c

>./c
d1=6583478410F4C7EC
d2=7FF0000000000000
d3=0000000000000000

...versus...

number? 10e180
 n=10e180
DD=00000000_00000000_00000000_7F800000
DQ=00000000_00000000_65834784_10F4C7EC
DT=00000000_00004258_9A3C2087_A63F6399
DO=42583478_410F4C7E_C7326D56_00000000

number? 10e947
 n=10e947
DD=00000000_00000000_00000000_7F800000
DQ=00000000_00000000_7FF00000_00000000
DT=00000000_00004C4C_91CC76FD_5EC629B5
DO=4C4C2398_EDFABD8C_53690BFE_00000000

number? 10e-435
 n=10e-435
DD=00000000_00000000_00000000_00000000
DQ=00000000_00000000_00000000_00000000
DT=00000000_00003A5D_9BC34631_A2F7B46F
DO=3A5D3786_8C6345EF_68DE7B4C_00000000

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel

anonymous coward wrote:
>>>> Mosher's code isn't always-correct; it even
given an error bound in the
>>>> source.
>>> You means this?
>>>
>>> /* Multiply by 10**nexp.  If precision is 64
bits,
>>>  * the maximum relative error incurred in
forming 10**n
>>>  * for 0 <= n <= 324 is 8.2e-20, at
10**180.
>>>  * For 0 <= n <= 999, the peak relative
error is 1.4e-19 at 10**947.
>>>  * For 0 >= n >= -999, it is -1.55e-19 at
10**-435.
>>>  */
>>>
>>> I did try 10e180, 10e947, and 10e-435 -- for
those three acfloat3
>>> does match what his ieee.c spits out.
>> Yes, and they're both wrong, that was the point.
> 
> Uhm... gcc happens to match his results for these three
numbers:
> 

Okay, fine, but the matter still is:

- Moscher's algorithm isn't accurate to the last bit in the
general
   case;
- It doesn't claim to be;
- Clinger's paper proves that no bounded-storage algorithm
*can* be.

So MP math is required for doing it right.

Note "doing it right" means finding the correctly
rounded 
implementation.  The IEEE standard only requires ±0.97 LSB,
since at the 
time the IEEE standard was written, it wasn't known if a 
correctly-rounded algorithm could be written.  So Moscher's
algorithm is 
probably within the looser bound of the IEEE standard.

We can either try to extract the glibc algorithm with all
its 
dependencies (which are mostly extracted already, it's just
a matter of 
cleaning up the types, and all the double-underscores added
everywhere 
to make the namespace safe for libc) or cook up something
else; perhaps 
based on one of the simpler algorithms from Clinger's
paper.

	-hpa

------------------------------------------------------------
-------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Nasm-devel mailing list
Nasm-devellists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nasm-devel