Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2017-03

Math and numlib

5 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Werner Pamler

Hi everybody - my first post here...

At the moment I am spending some time with fpc's numlib and writing a wrapper for a more versatile fitting procedure. Are there any problems to add the unit math to the uses clause of some numlib units? I want to use the value NaN (not-a-number) which is defined in numlib, but there 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.

Werner

Reply by email

Michael Van Canneyt
to Werner Pamler
Werner Pamler wrote 11 lines
Hi everybody - my first post here... At the moment I am spending some time with fpc's numlib and writing a wrapper for a more versatile fitting procedure. Are there any problems to add the unit math to the uses clause of some numlib units? I want to use the value NaN (not-a-number) which is defined in numlib, but there 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.

You can use the routines from the system unit for this.

http://www.freepascal.org/docs-html-3.0.0/rtl/system/textended80rec.html http://www.freepascal.org/docs-html-3.0.0/rtl/system/tdoublerec.html http://www.freepascal.org/docs-html-3.0.0/rtl/system/tsinglerec.html

function SpecialType.

Michael.

Reply by email

Marco van de Voort
to Werner Pamler: Hi everybody - my first post here... At the moment I am spending some time with fpc's…

In our previous episode, Werner Pamler said:

Show quoted text 6 lines
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.

Reply by email

Werner Pamler
to Marco van de Voort

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).

Marco van de Voort wrote 13 lines
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 - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply by email

Michael Van Canneyt
to Werner Pamler
Werner Pamler wrote 18 lines
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).

Better make this a normal variable; not a define.

Michael.

Reply by email