arturo-lang / arturo

Simple, expressive & portable programming language for efficient scripting
http://arturo-lang.io
MIT License
673 stars 29 forks source link

In place type change results in inaccurate math results #1607

Closed barryple closed 1 month ago

barryple commented 2 months ago

Converting a floating point number to an integer and then adding it to a negative number gives incorrect results.

$> x: 1.1

$> to :integer x + neg(3) => -1

results should be $> 1 + neg(3) => -2

I'm running the Linux arm64 mini version v/0.9.83 @ 2023-02-10T16:02:07-05:00 from the download page.

github-actions[bot] commented 2 months ago

Thank you for submitting an issue! :)

drkameleon commented 2 months ago

First of all, hi! And welcome to our community! 😉

What you mention seems ... suspicious, so I tried to test it for myself. And apparently, you are 100% right.

That's exactly what the returned results are.

However, I tried the exact same thing in Ruby and it seems like the result (for this type of operation) is identical, so... I'd have to investigate and see what the best practice should be in this sort of cases... 🤔

Have a look:

Screenshot 2024-04-22 at 16 35 22

Now, that being said, if you want to get the result you mentioned (-2), I'd use round first - that is before converting to :integer.

Here's an example:

Screenshot 2024-04-22 at 16 34 34

I believe this does the trick! 😉

barryple commented 2 months ago

Thanks for the quick response, what I think is a bug, which is now somewhat in doubt because of the same result in ruby :) was easy to work around. In this particular case I didn't want to round but your example taught me something. thanks!

drkameleon commented 2 months ago

The truth is... the second I saw your result I was like a) the version is not up-to-date (btw, if you want to get the real cutting-edge versions, you could have a look into this - at the bottom: https://github.com/arturo-lang/arturo/actions/runs/8721035508 - there are a few yet-undocumented changes, but I think it's worth the fuss), b) this is a bug with the arm64 architecture, c) this is the end of the world... lol

Generally, I try to keep things as standard as possible, so having a look at how our "competitors" do it (not that it's the absolute rule) is a way to see whether we are too ... off.

In any case, this one is an interesting one that I'll have to investigate further... So, thanks a lot for mentioning it! 😄

Don't hesitate to post anything else you may come across - be it a real bug, or not, it's always valuable!

Also, you are very welcome to join our Discord server: https://discord.com/invite/YdVK2CB (anything posted there will usually get a reply fast 😉)

RickBarretto commented 1 month ago

As @drkameleon said, welcome to our community @barryple. Sorry for replying this now, I just notice right now the why of the confusion, and I'm closing this issue.


I already have read this, but re-reading some issues I decided to close it. This is not a bug. The main issue here is not the round or the conversion to :integer itself, but the precedence.

Arturo's precedence is from right to left, so what you need it not the round function, but just replace the precedence.

Let's take this Python example: image

Now, let's see what is happening in Arturo: image

The stack process:

1. []
2. [3]
3. [3 neg]
4. [(-3)]
5. [(-3) + (to :integer x)]
6. [(-3) + 1]
7. [-2]