Thanks - unfortunately I've just uploaded a patch for unit typ
implementing IsNaN and IsInfinity according to Michael's suggestion. But
I think I'll withdraw the patch and replace it with one for a cleaned up
typ unit.
How about cleaning up also spe? It contains a large number of functions
which are contained in math as well, but with a terrible name (e.g.,
"spesih(x)" instead of "sinh(x)"). In theory, of course, this will break
existing code although I am absolutely sure that nobody ever has used
these functions.
Another idea: Errors in spe (and probably everywhere else) terminate the
program with a RunError. This is not up to date any more. How about
throwing an exception? Or, maybe, I could add a procedure
"NumLibError(ErrCode: Integer)" which by default throws an exception
with a message corresponding to the ErrCode, or, if compiled with
$DEFINE RUNTIME_ERRORS, terminates the program like before with a
RunError(ErrCode).
Am 14.03.2017 um 09:58 schrieb Marco van de Voort:
In our previous episode, Werner Pamler said:
is no way to check whether a value is "equal" to NaN. In math, however,
there is a function IsNaN(). And my feeling is that these special
numbers NaN and Infinity are implemented in math in a more general way
than in numlib. An idea would be to remove NaN and Infinity from the
numlib unit "typ" to replace them by the math values.
No, cleaning up "typ" a bit using math is no problem. RTL generally have
functions like this since coprocessors are standard. Just keep the
separation of typing (arbint/arbfloat) a bit, it can be useful to change the
library's precision.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
