Feature #13693: Allow String#to_i and / or Kernel::Integer to parse e-notation

• Status: Rejected
• Assignee: -
• Target version: -

[sos4nt (Stefan Schüßler)]

Kernel can properly convert e-notation strings into numeric objects:

     Float('1e+3') #=> 1000.0
  Rational('1e+3') #=> (1000/1)
   Complex('1e+3') #=> (1000.0+0i)
BigDecimal('1e+3') #=> 0.1e4

Same for String:

'1e+3'.to_f #=> 1000.0
'1e+3'.to_r #=> (1000/1)
'1e+3'.to_c #=> (1000.0+0i)
'1e+3'.to_d #=> 0.1e4

With one exception:

Integer('1e+3') #=> ArgumentError: invalid value for Integer(): "1e+3"
'1e+3'.to_i     #=> 1

Ruby should be able to convert e-notation strings to integers, too.

[shevegen (Robert A. Heiler)]

I think you are right, due to the behaviour of '1e+3'.to_i alone. Perhaps it was forgotten?

[duerst (Martin Dürst)]

• Status changed from Open to Rejected

We quickly discussed this issue at today's Ruby committer's meeting.

For everybody, converting exponential (scientific) notation to integer looked strange. Exponential notation is usually used to express very large numbers or very small numbers that don't fit integer.

We also wondered whether you have an actual use case. Consistency is important, but we don't add something just for 'consistency's sake.

[sos4nt (Stefan Schüßler)]

We also wondered whether you have an actual use case.

I stumbled across this behavior when playing with a simple calculator which collects user input via:

number = Integer(gets)

Exponential notation is usually used to express very large numbers or very small numbers that don't fit integer.

I'd remove the "that don't fit integer" part, but yes, it's a way to enter and display very large (or very small) numbers more concise. That's exactly was I was attempting: entering 1e30, so I don't have to type 1000000000000000000000000000000.

Consistency is important, but we don't add something just for 'consistency's sake.

The documentation for Kernel#Integer explains that "[...] strings should be strictly conformed to numeric representation". Shouldn't it in turn be able to parse for example "1e30", given that 1e30 is a valid numeric representation?

I think it's more a matter of completeness than consistency. It seems odd that Integer() happily parses '0xff', '0b100110' and '0740' but cannot handle '1e30'.