Add floating-point primitives. about basil HOT 4 CLOSED

Closing this, since these are included in the rewritten v1.0 branch! Float is the 32-bit floating-point type, and Double is the 64-bit one.

from basil.

a) Are float literals safe in runtime (i.e. checked in compile-time)?

b) Would it be possible to use the compile-time functionality to import automatically the mpdecimal library on demand and treat all float literals as decimal float literals (instead of the default binary float literals)?

from basil.

I wouldn't consider this unsafe, it's kind of just an inherent feature of floating-point...which is fine, I think. My thoughts on this are that as long as Basil is pretty clear about where it's using floating-point, it should be pretty clear where one uses it as a trade-off between perfect accuracy and performance (no floating-point alternative is anywhere near as fast on modern hardware, and esp. 64-bit floats have pretty low error margins IMO). In general, I'm leaning more towards performance over the kinds of "strict correctness" features we see in some other languages.

Not sure how I feel about opaquely changing the default behavior of the compiler, esp. with regards to constants, but it should be possible to write a pleasant interface to any decimal library you want. It's a little outdated but I've actually already implemented a rational approximation in Basil in https://github.com/basilTeam/basil/blob/v1.0/example/rational.bl - with a few more language features (like user-defined implicit conversions, so you can somewhat transparently write def x : Rational = 10 equivalently to def x = Rational 10 or something) it should be fairly smooth.

from basil.

I wouldn't consider this unsafe, it's kind of just an inherent feature of floating-point...which is fine, I think. My thoughts on this are that as long as Basil is pretty clear about where it's using floating-point, it should be pretty clear where one uses it as a trade-off between perfect accuracy and performance (no floating-point alternative is anywhere near as fast on modern hardware, and esp. 64-bit floats have pretty low error margins IMO).

I was myself shocked that mpdecimal (an arbitrary precision decimal float) is about 2-3x slower than native 64bit binary floats on average. Only in games (or any kind of visualization) and scientific libs (or anything having floats in a tight loop) I'd use a mixture of binary & decimal floats for performance reasons. But in any other scenario I can think of, the advantages of decimal floats (especially mpdecimal) by far outweight the IMHO totally acceptable slowness so I'd use only decimal floats.

Do you have different observations?

In general, I'm leaning more towards performance over the kinds of "strict correctness" features we see in some other languages.

In general I understand and lean also to performance. On the other hand, I'd like to have a mechanism to ensure the higher safety. So I'd really like to be able to tell Basil to treat float literals as decimals.

Not sure how I feel about opaquely changing the default behavior of the compiler, esp. with regards to constants, but it should be possible to write a pleasant interface to any decimal library you want. It's a little outdated but I've actually already implemented a rational approximation in Basil in https://github.com/basilTeam/basil/blob/v1.0/example/rational.bl - with a few more language features (like user-defined implicit conversions, so you can somewhat transparently write def x : Rational = 10 equivalently to def x = Rational 10 or something) it should be fairly smooth.

Hm, this might work if the float number will be treated untyped until the type of LHS is fully resolved. Because otherwise one would lose precision when converting binary float to a decimal float.

Could you clarify whether Basil treats float literals as untyped floats (i.e. without any loss of precision)?

from basil.