## Feature #13693

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

Added by sos4nt (Stefan Schüßler) about 4 years ago.
Updated almost 4 years ago.

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

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

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

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

.

Also available in: Atom
PDF