Project

General

Profile

Actions

Feature #13693

closed

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

Added by sos4nt (Stefan Schüßler) over 6 years ago. Updated over 6 years ago.

Status:
Rejected
Assignee:
-
Target version:
-
[ruby-core:81811]

Description

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.

Updated by shevegen (Robert A. Heiler) over 6 years ago

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

Updated by duerst (Martin Dürst) over 6 years ago

  • 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.

Updated by sos4nt (Stefan Schüßler) over 6 years ago

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'.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0