Undefined behavior of floats/doubles/... comparisons

[dumblob]

A numerical library needs a well defined behavior of floating point computations (incl. comparisons) on all platforms it supports. Currently it seems vnum is not limited to any platform (as vsl is not limited to any) with the exception of LAPACK/BLAS routines which usually do have well defined limitations and can't be run on all existing platforms.

V does NOT have well defined behavior of floating point comparisons and that's why I'm raising this issue here.

Refer to vlang/v#5180 (comment) for detailed analysis and a sketch of a possible solution.

[ulises-jeremias]

Hi! Thanks for the comment and the good analysis you did. As you mentioned vsl is not limited to any platform but we are using LAPACK/BLAS, which is contradictory.

That's a big problem in the vsl and vnum documentation, since that point is unclear. However, it is true that some vsl modules are compatible with any platform, so I will be reviewing the docs to better clarify which ones are and which are not.

Also, I want to take this opportunity to comment that the idea is that vnum will not have platform problems, so the responsibility for that will be entirely up to vsl in which the necessary functions for this will be implemented. That is, if something cannot be implemented using LAPACK, BLAS, or any dependencies, vsl will have a default implementation in pure V.

Regarding the precision problem, it is a problem that we inherit from the number system defined in V. However, I have a couple of solutions that can be defined in the future in VSL. At the moment the only thing I can say is that we are defining tests with a total precision of more than 9 or 16 decimal places, or even more. Therefore, every number is compared in a safe and realistic way using an epsilon instead of the equality defined by the language, as it has been done in other scientific computer libraries of other languages.

In the short term I will be dealing with this issue in VSL so I would really appreciate reviews from you in future PRs in vsl and vnum

[dumblob]

Regarding the precision problem, it is a problem that we inherit from the number system defined in V.

I believe there is still room for improvement - the language didn't reach 1.0 yet. That's why I'm pushing for this as many issues would simply "disappear" if V e.g. disallowed all comparison operators for floats by default (i.e. forcing the programmer to explicitly choose the semantics of comparison operators with given granularity up front - be it for the current expression/line_of_code/module/...).

[dumblob]

In the short term I will be dealing with this issue in VSL so I would really appreciate reviews from you in future PRs in vsl and vnum

I'll gladly do if I'll find some time - but please always ping me so that I get an email as I can't follow everything 😉.

[dumblob]

I'd leave this open as the issue is still valid. Or am I missing something?

[dumblob]

As a follow up on vlang/v#5180 (comment) , it seems due to equality operators being now overloadable we got much closer to the proposal of disabling all equality operators for floats by default and allowing to import any of the 5 proposed APIs with file-grained granularity.

[wwlittewayne]

It might be worth investigating how GNU Octave deal with this problem.

[dumblob]

@wwlittewayne AFAIK it does not deal with it "at all" (pretty much the same goes for Matlab). It is a very old SW design/concept, so this is to be expected.