## Feature #13693

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

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

### History

#### Updated by shevegen (Robert A. Heiler) over 2 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 2 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 2 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'`

.