numlib's exp function returning 0
Original Reporter info from Mantis: wp @wpam
-
Reporter name:
Original Reporter info from Mantis: wp @wpam
- Reporter name:
Description:
fpc'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.
Mantis conversion info:
- Mantis ID: 34434