ceil/floor bug with negative floats #382
Milestone
Comments
|
I think this is very similar to the other issue. We first ceil / floor the
float, then make it negative:)
Thanks for finding these, I'll try to give it a crack in the upcoming days
…On Tue, Jul 28, 2020, 1:05 PM Adrian Ho ***@***.***> wrote:
> -10.6.ceil()
-11 # should be -10
> -10.6.floor()
-10 # should be -11
> -10.6.round()
-11
> -10.6.int()
-10
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#382>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACQFZGTKAAIA7T5ZJRA723R52IGXANCNFSM4PKJQX4A>
.
|
|
👍, parenthesizing the negative number object gives correct results for all the math operations in both my PRs, so it just a parser issue. |
odino
added a commit
that referenced
this issue
Jul 28, 2020
This bugfix introduces negative numbers into our parser: before, -10 would be parsed as (minus, number) whereas right now it's going to be parsed as (number) only. This fixes a bug with precedences, where `-1.str()` would be parsed as (-, (1, str)), leading to first calling the str method on the positive number, then applying the minus. Before: ``` ⧐ -1.234.str() ERROR: unknown operator: -STRING [1:1] -1.234.str() ``` After: ``` ⧐ -1.234.str() -1.234 ``` If a space is found between the minus and the number, the old parsing mechanism still applies. I found inspiration in Ruby, where: ``` $ - 1.to_s() -@: undefined method `-@' for "1":String $-1.to_s() -1 $ -10.3.floor() -11 $ - 10.3.floor() -10 ```
odino
added a commit
that referenced
this issue
Jul 28, 2020
This bugfix introduces negative numbers into our parser: before, -10 would be parsed as (minus, number) whereas right now it's going to be parsed as (number) only. This fixes a bug with precedences, where `-1.str()` would be parsed as (-, (1, str)), leading to first calling the str method on the positive number, then applying the minus. Before: ``` ⧐ -1.234.str() ERROR: unknown operator: -STRING [1:1] -1.234.str() ``` After: ``` ⧐ -1.234.str() -1.234 ``` If a space is found between the minus and the number, the old parsing mechanism still applies. I found inspiration in Ruby, where: ``` $ - 1.to_s() -@: undefined method `-@' for "1":String $-1.to_s() -1 $ -10.3.floor() -11 $ - 10.3.floor() -10 ```
odino
added a commit
that referenced
this issue
Jul 28, 2020
This bugfix introduces negative numbers into our parser: before, -10 would be parsed as (minus, number) whereas right now it's going to be parsed as (number) only. This fixes a bug with precedences, where `-1.str()` would be parsed as (-, (1, str)), leading to first calling the str method on the positive number, then applying the minus. Before: ``` ⧐ -1.234.str() ERROR: unknown operator: -STRING [1:1] -1.234.str() ``` After: ``` ⧐ -1.234.str() -1.234 ``` If a space is found between the minus and the number, the old parsing mechanism still applies. I found inspiration in Ruby, where: ``` $ - 1.to_s() -@: undefined method `-@' for "1":String $-1.to_s() -1 $ -10.3.floor() -11 $ - 10.3.floor() -10 ```
odino
added a commit
that referenced
this issue
Jul 28, 2020
This bugfix introduces negative numbers into our parser: before, -10 would be parsed as (minus, number) whereas right now it's going to be parsed as (number) only. This fixes a bug with precedences, where `-1.str()` would be parsed as (-, (1, str)), leading to first calling the str method on the positive number, then applying the minus. Before: ``` ⧐ -1.234.str() ERROR: unknown operator: -STRING [1:1] -1.234.str() ``` After: ``` ⧐ -1.234.str() -1.234 ``` If a space is found between the minus and the number, the old parsing mechanism still applies. I found inspiration in Ruby, where: ``` $ - 1.to_s() -@: undefined method `-@' for "1":String $-1.to_s() -1 $ -10.3.floor() -11 $ - 10.3.floor() -10 ```
odino
added a commit
that referenced
this issue
Jul 28, 2020
This bugfix introduces negative numbers into our parser: before, -10 would be parsed as (minus, number) whereas right now it's going to be parsed as (number) only. This fixes a bug with precedences, where `-1.str()` would be parsed as (-, (1, str)), leading to first calling the str method on the positive number, then applying the minus. Before: ``` ⧐ -1.234.str() ERROR: unknown operator: -STRING [1:1] -1.234.str() ``` After: ``` ⧐ -1.234.str() -1.234 ``` If a space is found between the minus and the number, the old parsing mechanism still applies. I found inspiration in Ruby, where: ``` $ - 1.to_s() -@: undefined method `-@' for "1":String $-1.to_s() -1 $ -10.3.floor() -11 $ - 10.3.floor() -10 ```
odino
added a commit
that referenced
this issue
Jul 28, 2020
This bugfix introduces negative numbers into our parser: before, -10 would be parsed as (minus, number) whereas right now it's going to be parsed as (number) only. This fixes a bug with precedences, where `-1.str()` would be parsed as (-, (1, str)), leading to first calling the str method on the positive number, then applying the minus. Before: ``` ⧐ -1.234.str() ERROR: unknown operator: -STRING [1:1] -1.234.str() ``` After: ``` ⧐ -1.234.str() -1.234 ``` If a space is found between the minus and the number, the old parsing mechanism still applies. I found inspiration in Ruby, where: ``` $ - 1.to_s() -@: undefined method `-@' for "1":String $-1.to_s() -1 $ -10.3.floor() -11 $ - 10.3.floor() -10 ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The text was updated successfully, but these errors were encountered: