vtl icon indicating copy to clipboard operation
vtl copied to clipboard

Undefined behavior of floats/doubles/... comparisons

Open dumblob opened this issue 5 years ago • 7 comments

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 https://github.com/vlang/v/issues/5180#issuecomment-675732199 for detailed analysis and a sketch of a possible solution.

dumblob avatar Oct 26 '20 16:10 dumblob

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

ulises-jeremias avatar Oct 28 '20 23:10 ulises-jeremias

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 avatar Oct 29 '20 08:10 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 :wink:.

dumblob avatar Oct 29 '20 08:10 dumblob

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

dumblob avatar Oct 29 '20 14:10 dumblob

As a follow up on https://github.com/vlang/v/issues/5180#issuecomment-675732199 , 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.

dumblob avatar Jan 13 '21 11:01 dumblob

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

wwlittewayne avatar May 04 '23 14:05 wwlittewayne

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

dumblob avatar Jun 14 '23 21:06 dumblob