View Issue Details

IDProjectCategoryView StatusLast Update
0034434FPCFCLpublic2018-10-26 17:09
Reporterwp Assigned ToMarco van de Voort  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Summary0034434: numlib's exp function returning 0
Descriptionfpc's numlib contains its own exp funtion in unit "typ" which returns 0 when the argument is "very small".

This function, however, has a bug in what is considered to be "very small".

The following project calculates exp(-1) which, according to the rules of mathematics, must be equal to 1/e = 1/2.718... = 0.3678... The output of the system's exp funtion is correct, but numlib's function returns 0:

--------------------------------------------------
program Project1;
uses
  typ;
var
  x: Double;
begin
  x := -1.0;
  WriteLn(x:10:5, typ.exp(x):10:5, system.exp(x):10:5);
  WriteLn(LnMidget);
end.

Output on fpc 3.0.4 (64 bit) on Win10:
  -1.00000 0.00000 0.36788 <--- NOTE the 0 for typ.exp(-1)
-2.5242573334140299E-067

Output on fpc 3.0.4 (32 bit) and fpc trunk (32 bit) on Win10:
  -1.00000 0.36788 0.36788
-1.13988053843083006136E+0004
--------------------------------------------------

The LnMidget is used in numlib's exp function to decide whether the "true" value of system.exp() should be used, or whether the argument is too small and the function result should be considered to be zero.

Obviously the 64-bit LnMidget is not correct, it is way too large (near zero).

Since I don't know what the LnMidget is exactly I cannot present a patch. But I have a bad feeling about setting function results of the exp function to zero anyway as this is wrong mathematically. I'd propose to remove the exp() function in the unit "typ" of numlib altogether. Of course, I don't know either whether numlib requires exp to be zero somewhere internally.

Since numlib probably originates from the time when nobody thought of 64-bit systems I'd urge to check the validity of the internal values TC1..TC6 for 64-bit.

TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget
Attached Files

Activities

Marco van de Voort

2018-10-24 17:15

manager   ~0111539

I think this is a x87 vs sse issue. Currently the code seems to assume x87, also on win64.

So maybe {$ifndef win64} around the {$define arbextended} would help.

Thaddy de Koning

2018-10-24 17:39

reporter   ~0111541

That on its own is not enough, because you can compile win64 with x87 support...
(Ok, that's a niche, but possible) so you also need to exclude the x87. There is a define for that, do not know it by heart.

Marco van de Voort

2018-10-24 18:09

manager   ~0111542

I committed a simple test for sizeof(extended)=10. Please test.

wp

2018-10-26 12:12

reporter   ~0111570

Thank you. Seems to work for me (but I can only test Win10/64bit)

Issue History

Date Modified Username Field Change
2018-10-19 11:32 wp New Issue
2018-10-24 17:15 Marco van de Voort Note Added: 0111539
2018-10-24 17:39 Thaddy de Koning Note Added: 0111541
2018-10-24 18:09 Marco van de Voort Note Added: 0111542
2018-10-25 00:05 Marco van de Voort Assigned To => Marco van de Voort
2018-10-25 00:05 Marco van de Voort Status new => feedback
2018-10-26 12:12 wp Note Added: 0111570
2018-10-26 12:12 wp Status feedback => assigned
2018-10-26 14:02 Marco van de Voort Status assigned => resolved
2018-10-26 14:02 Marco van de Voort Resolution open => fixed
2018-10-26 17:09 wp Status resolved => closed