Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add floating-point primitives. #28

Closed
elucent opened this issue Oct 4, 2021 · 4 comments
Closed

Add floating-point primitives. #28

elucent opened this issue Oct 4, 2021 · 4 comments
Labels
planned feature Planned feature for upcoming language revision.
Projects

Comments

@elucent
Copy link
Contributor

elucent commented Oct 4, 2021

Basil should support floating-point primitives, specifically a 32-bit float and 64-bit double, as primitives. Floating-point types should support implicit conversion from smaller integer types, and to larger floating-point types.

@elucent elucent added the planned feature Planned feature for upcoming language revision. label Oct 4, 2021
@elucent elucent added this to 1.0 in Releases Oct 4, 2021
@elucent
Copy link
Contributor Author

elucent commented Oct 4, 2021

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.

@dumblob
Copy link

dumblob commented Oct 4, 2021

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

@elucent
Copy link
Contributor Author

elucent commented Oct 4, 2021

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.

@dumblob
Copy link

dumblob commented Oct 4, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
planned feature Planned feature for upcoming language revision.
Projects
Development

No branches or pull requests

2 participants