Bug toNumber

Here an amazing bug

"01".toNumber() => 1
"02".toNumber() => 2
"03".toNumber() => 3
"04".toNumber() => 4
"05".toNumber() => 5
"06".toNumber() => 6
"07".toNumber() => 7
"08".toNumber() => 0
"09".toNumber() => 0
"10".toNumber() => 10
"11".toNumber() => 11

travis.vitek over 9 years ago

This is not a bug.

It is treating the number as octal since it starts with a leading 0, and failing to parse beyond that. If you try to convert "0xAZ" you get the value 11, which is a correct interpretation of the hexadecimal integer 0xA. So there is consistency (the leading '0' or '0x' is interpreted as the radix specifier).

The documentation uses an example in hex, which confirms the intended behavior.

Travis

benjamin.serant over 9 years ago

Thank for this fast answer.

I understand for 0x8 but for 08....
I prefer the new format 0o as define in Python3 or Perl,

Firstly, It's not on the documentation If a string is in numeric form, either “123” or “0x12AB”, convert it to a Number object with toNumber().
Secondly, It's not practical when we need to parse string.

I use, now, a bypass for this bug.

jim_m_58 over 9 years ago

When parsing a string and you get the number, and strip leading zeros before using toNumber() to avoid this.

benjamin.serant over 9 years ago

Yes, no choice... not elegant...

benjamin.serant over 9 years ago

Newer languages have been abandoning the prefix 0, as decimal numbers are often represented with leading zeroes. The prefix q was introduced to avoid the prefix o being mistaken for a zero, while the prefix 0o was introduced to avoid starting a numerical literal with an alphabetic character (like o or q), since these might cause the literal to be confused with a variable name. The prefix 0o also follows the model set by the prefix 0x used for hexadecimal literals.

travis.vitek over 9 years ago

I understand for 0x8 but for 08....

You understand doing this for hex, but not for octal? If you were parsing an octal input string you would think it a bug if it were interpreted as decimal, no?

Firstly, It's not on the documentation If a string is in numeric form, either “123” or “0x12AB”, convert it to a Number object with toNumber().

Yes, it is just an example, not an exhaustive list of all parsed formats.

The problem is that the function is behaving exactly as it is supposed to, so it isn't a bug.

If you are asking for an enhancement, to parse an integer with a radix of 10, or some user specified radix, I'm sure that would be more well received than proposing that the function is broken. Especially when making the change you are proposing would break existing code that works correctly.

Travis

benjamin.serant over 9 years ago

Thank Travis,

I understand and I agree with you about the non regression.

It's just a pity to keep vetuste behavior in a new language.

But I understand and I do with.

Thank again

travis.vitek over 9 years ago

I'm all for adding the ability to specify the radix when converting, I think it is a reasonable thing to ask for.

benjamin.serant over 9 years ago

I'm for adding an exception and complet the documentation with all number formats.

Former Member over 9 years ago

Hey guys, in the first releases of CIQ, the conversion used under the hood for this, was not interpreting leading 0's as an octal prefix, but I believe it also did not work for hexadecimal numbers. The method was modified to use a less costly method, and inadvertently changed to support octal numbers along with hex. I think the AlphaMonkey is in favor of changing this back to the original functionality, and we may add an additional conversion operation that allows specifying the radix.

In any case, we want to update our documentation to properly reflect the functionality.