Project

General

Profile

Actions

Bug #21163

closed

Inconsistencies in Kernel.Float compared to other number parsing methods

Added by herwin (Herwin W) about 1 month ago. Updated 12 days ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:121205]

Description

Not sure if I consider the following points to be bugs, but they sure did surprise me:

Item 1: Hexadecimal is the only prefix accepted
If you use the "0x" prefix, your value is parsed as hexadecimal float:

Float("0x10")  # => 16.0
Float("0x0.8") # =>  0.5 # Since Ruby 3.4

This is the only accepted prefix, "010" is not parsed as octal, but as decimal 10. "0b10" and "0o10" are parse errors. If "0x" works, I would expect these to work too.

Item 2: Inconsistency with String#to_f
String#to_f does not parse hexadecimal strings, "0x10".to_f simply returns 0.0. Generally, the methods in Kernel are stricter than the methods on String, so valid input for the Kernel methods yields the same result in the String methods, I think this is the only exception

Item 3: Inconsistency with Kernel#Integer

Integer("0x1_0a") # => 0x10a
Float("0x1_0")     # => 16.0 # This underscore is accepted
Float("0x1_0a")    # => ArgumentError

Kernel.Float does accept underscores in hexadecimal strings, but only if all values are digits. As soon as there is a [a-fA-F] in the input, it is an ArgumentError

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0