bugGforth - Bugs: bug #50221, FP operations produce unexpected...

 
 

bug #50221: FP operations produce unexpected NaNs

Submitted by:  None
Submitted on:  Fri 03 Feb 2017 02:21:13 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Anton Ertl <anton>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 08 Feb 2017 02:58:36 PM UTC, comment #7:

Ok, I have now commented out this test case.

Anton Ertl <anton>
Project AdministratorIn charge of this item.
Wed 08 Feb 2017 02:59:42 AM UTC, comment #6:

Hmm - now this test in test/float.fs fails:

{ 1e0 eps f- pad 20 represent pad 5 s" 99999" str= -> 0 0 -1 -1 }

because it produces "10000..", i.e. rounds up (apart from this slight "inaccuracy" the conversion is correct, so i'd prefer if it wouldn't stop the build process).

Anonymous
Mon 06 Feb 2017 08:17:21 AM UTC, comment #5:

fixed in the git repository.

Anton Ertl <anton>
Project AdministratorIn charge of this item.
Sun 05 Feb 2017 02:11:52 PM UTC, comment #4:

So, a possible fix would be (in engine/ecvt_r.c):
..
*exp=(x==0)?-1:(int)floor(log10(x));
if(exp < -300) { / maybe a denormal: do this in two steps */
x = x * pow10(300.);
x = x / pow10((double)(*exp)+300.);
} else {
x = x / pow10((double)*exp);
}

+ // Adjust x and exp in case rounding grew x a digit (e.g.: 0.999999999.. -> 1.0)
+ if(x>=10.) {
+ x /= 10.;
+ exp += 1;
+ }

Anonymous
Sat 04 Feb 2017 03:52:20 PM UTC, comment #3:

Yes, it's definitely not a NaN coming out of the computation:

1 53 lshift 1- s>f 1 53 lshift s>f f/ fdup f= .

prints -1 (for a Nan we would see 0).

And it is really the FP->String conversion (REPRESENT on the
Forth level, ecvt_r on the C level). It works with the ecvt_r
from glibc 2.19 on AMD64. Unfortunately it does not work
reliably with our own ecvt_r replacement, either:

2e0 -53e0 f** fconstant eps
1e0 eps f- pad 20 represent .s cr pad 20 dump

This produces an "invalid" result (and the ":" in the string).

So I consider this to be a bug in MacOS X's ecvt_r and in our own
ecvt_r replacement; and ideally we should be checking for this bug in
our configure script so that our then-fixed ecvt_r replacement is used
instead of the broken MacOS X ecvt_r.

Thank you for the bug report.

Anton Ertl <anton>
Project AdministratorIn charge of this item.
Sat 04 Feb 2017 12:10:24 AM UTC, comment #2:

Sure (sorry for the sloppy bug report):

gforth 0.7.9_20170112 amd64 (on mac os x sierra, compiled with gcc-4.9.3)

I found that this is likely only a problem of the float->string conversion:

2e0 -53e0 f** fconstant eps \ LSB of 1e0 as ieee double-float
1e0 fe. cr
1e0 eps f- fe. cr
1e0 eps f- eps f- fe. cr
1e0 eps f- eps f- eps f- fe. cr

Prints:

1.00000000000000E0
:
:
1.00000000000000E0

Anonymous
Fri 03 Feb 2017 04:24:46 PM UTC, comment #1:

Please give more information on the platform and Gforth version to allow us to reproduce the problem. It works for me on both AMD64 and ARM64:

1 53 lshift 1- s>f 1 53 lshift s>f f/ f. 1. ok

(PPC and ARM both produce -inf, because "1 53 lshift" produces 0 there).

Anton Ertl <anton>
Project AdministratorIn charge of this item.
Fri 03 Feb 2017 02:21:13 PM UTC, original submission:

Floating point results having a mantissa consisting of FFFF....FFFF or FFFF....FFFE are considered not a number.

An example calculation triggering this:

1 53 lshift 1 - s>f
1 53 lshift s>f f/
f.

Prints ":" (ie. NaN)

(Other, less artificial examples trigger this behaviour too - i originally encountered the bug when approximating an integral, where the result was ok unless i used a higher precision which yielded a result very close to 1.0).

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by anton (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 08 Feb 2017 02:58:36 PM UTCantonOpen/ClosedOpen=>Closed
    Mon 06 Feb 2017 08:17:50 AM UTCantonAssigned toNone=>anton
    Mon 06 Feb 2017 08:17:21 AM UTCantonStatusConfirmed=>Fixed
    Sat 04 Feb 2017 03:52:20 PM UTCantonStatusNeed Info=>Confirmed
    Fri 03 Feb 2017 04:24:46 PM UTCantonStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1