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

 
 

bug #50221: FP operations produce unexpected NaNs

Submitter:  None
Submitted:  Fri 03 Feb 2017 02:21:13 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  anton
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
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>
Group administrator
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>
Group administrator
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>
Group administrator
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 Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-02-08 anton Open/ClosedOpen Closed
    2017-02-06 anton Assigned toNone anton
    2017-02-06 anton StatusConfirmed Fixed
    2017-02-04 anton StatusNeed Info Confirmed
    2017-02-03 anton StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code