# Bug? parse(Integer, ...) calls typemax

**URL:** <https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252>\
**Category:** General Usage\
**Tags:** integer-overflow\
**Created:** [August 29, 2021, 12:26am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252 "2021-08-29T00:26:08Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mark\_Nahabedian](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mark_nahabedian/32/16562_2.png) [@Mark\_Nahabedian](https://discourse.julialang.org/u/Mark_Nahabedian)\
**Post date:** [August 29, 2021, 12:26am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/1 "2021-08-29T00:26:08Z")

</div>

Is this a bug

```julia
parse(Integer, "1234567890987654321234567890")
ERROR: MethodError: no method matching typemax(::Type{Integer})
Closest candidates are:
  typemax(!Matched::Union{Dates.DateTime, Type{Dates.DateTime}}) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.6\Dates\src\types.jl:426
  typemax(!Matched::Union{Dates.Date, Type{Dates.Date}}) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.6\Dates\src\types.jl:428
  typemax(!Matched::Union{Dates.Time, Type{Dates.Time}}) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.6\Dates\src\types.jl:430
  ...
Stacktrace:
 [1] tryparse_internal(#unused#::Type{Integer}, s::String, startpos::Int64, endpos::Int64, base_::Int64, raise::Bool)
   @ Base .\parse.jl:128
 [2] parse(::Type{Integer}, s::String; base::Nothing)
   @ Base .\parse.jl:241
 [3] parse(::Type{Integer}, s::String)
   @ Base .\parse.jl:241
 [4] top-level scope
   @ none:1

```

```julia
julia --version
julia version 1.6.0

```

---

<div class="post-metadata">

**Author:** ![rafael.guerra](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rafael.guerra/32/216610_2.png) [@rafael.guerra](https://discourse.julialang.org/u/rafael.guerra)\
**Post date:** [August 29, 2021, 12:29am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/2 "2021-08-29T00:29:35Z")

</div>

Did you mean `parse(Int,...)`?  
(which will overflow, btw)

---

<div class="post-metadata">

**Author:** ![Mark\_Nahabedian](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mark_nahabedian/32/16562_2.png) [@Mark\_Nahabedian](https://discourse.julialang.org/u/Mark_Nahabedian)\
**Post date:** [August 29, 2021, 12:38am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/3 "2021-08-29T00:38:42Z")

</div>

Oops. Integer is an abstract type. I still think I should be able to parse to Integer and get the subtype that the value fits in.

This works

```julia
parse(BigInt, "1234567890987654321234567890")
1234567890987654321234567890

```

but this

```julia
typeof(parse(BigInt, "4"))
BigInt

```

seems wasteful.

---

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [August 29, 2021, 1:13am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/4 "2021-08-29T01:13:31Z")

</div>

> [@Mark\_Nahabedian](#):
>
> get the subtype that the value fits in

`Integer` can have infinitely many sub-types, what should Julia do? dynamically call `subtypes` and check each `typemax` and sort them and find the smallest fitting one? Seems wasteful.

---

<div class="post-metadata">

**Author:** ![Mark\_Nahabedian](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mark_nahabedian/32/16562_2.png) [@Mark\_Nahabedian](https://discourse.julialang.org/u/Mark_Nahabedian)\
**Post date:** [August 29, 2021, 1:34am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/5 "2021-08-29T01:34:11Z")

</div>

Yup. Good point.

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [August 29, 2021, 4:02am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/6 "2021-08-29T04:02:30Z")

</div>

And if that is what you want, you can of course do

```julia
T = Int8

while true
    try
        x = parse(T, s)
        break
    catch e
        e isa UnrepresentableError || rethrow(e) #whatever the error type is called, need to look this up
        T = widen(T)
    end
end

```

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [August 29, 2021, 8:12am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/7 "2021-08-29T08:12:48Z")

</div>

> [@Mark\_Nahabedian](#):
>
> but this
> 
> ```julia
> typeof(parse(BigInt, "4"))
> BigInt
> 
> ```
> 
> seems wasteful.

A workaround to fix this is to write

```julia
parse(Int, "4")

```

instead of specifically asking for a `BigInt`.

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [August 29, 2021, 8:25am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/8 "2021-08-29T08:25:39Z")

</div>

> [@DNF](#):
>
> specifically asking

`Int` isn’t less specific than `BigInt` (on a given system). I think OP’s point is they want the smallest `Integer` type which can represent the number in a string.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [August 29, 2021, 8:31am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/9 "2021-08-29T08:31:04Z")

</div>

Read it again:

> [@Mark\_Nahabedian](#):
>
> but this
> 
> ```julia
> typeof(parse(BigInt, "4"))
> BigInt
> 
> ```
> 
> seems wasteful.

He’s suggesting that this should not return a `BigInt`.

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [August 29, 2021, 8:34am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/10 "2021-08-29T08:34:15Z")

</div>

I read that to mean that the more inclusive method `parse(BigInt, stringvariable)` is wasteful for small values of `stringvariable`.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [August 29, 2021, 8:36am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/11 "2021-08-29T08:36:57Z")

</div>

Maybe, but that depends on the use case, one can easily imagine cases where combinations of small integers overflow.

Anyway, I read it as a request that the compiler should override `parse(BigInt, "4")` to return a smaller type. Can you clarify, @Mark_Nahabedian?

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [August 29, 2021, 9:22am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/12 "2021-08-29T09:22:59Z")

</div>

At my computer now, so I could test it out:

```julia
function minimalparse(s)
    T = Int8
    while true
        try
            return parse(T, s)
        catch e
            e isa OverflowError || rethrow(e)
            T = widen(T)
        end
    end
end

```

```julia
julia> typeof(minimalparse("123"))
Int8

julia> typeof(minimalparse("1234"))
Int16

julia> typeof(minimalparse("123456"))
Int32

julia> typeof(minimalparse("123456789012"))
Int64

julia> typeof(minimalparse("123456789012345678901234"))
Int128

julia> typeof(minimalparse("12345678901234567890123456789012345678901234567890"))
BigInt

```

Obviously this is not type stable. It may very well be more performant to use a “too large” type for many applications.

---

<div class="post-metadata">

**Author:** ![Mark\_Nahabedian](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mark_nahabedian/32/16562_2.png) [@Mark\_Nahabedian](https://discourse.julialang.org/u/Mark_Nahabedian)\
**Post date:** [August 29, 2021, 10:17am UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/13 "2021-08-29T10:17:28Z")

</div>

I’m sorry. From the discussion, it’s clear I wasn’t really thinking.

A CommonLisp implementation would use FIXNUM until it overflowed into BIGNUM. The built-in types in CommonLisp aren’t extensible though.

Given that Integer us subtypable, the Julia implementation can’t guess which subtypes are most appropriate for a given application. I suppose if a developer really didn’t know the range of integers they were dealing with, and wanted a minimal size integer, they could implement their own function to do that, or specialize parse.

One possible behavior would be to start with Int until the number being parsed overflows and then resort to BigInt. That would be analogous to the CommonLisp implementation, would represent all integers, and those that fit would be represented in a manner mist suited to the architecture. This is not consistent with Julia’s wrap on overflow behavior though. It’s been so long since I’ve dealt with anything near the machine level that I have no clue whether machines still allow trap on arithmetic overflow or whether any IS or language runtime exposes that to the programmer.

I suppose at the hardware level the “extra” most negative twos compliment integer could be treated as an overflow indicator analogous to the various floating point NaNs. I doubt thus could be gone without adding gate delay to what is probably the most fundamental operation in computation.

Can you tell I’m having trouble falling asleep?

> ![](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/45/10191_2.png "DNF") | [DNF](https://discourse.julialang.org/u/dnf)  
> August 29 |
> 
> - | - |

Maybe, but that depends on the use case, one can easily imagine cases where combinations of small integers overflow.

Anyway, I read it as a request that the compiler should override `parse(BigInt, "4")` to return a smaller type. Can you clarify, [@Mark\_Nahabedian](https://discourse.julialang.org/u/mark_nahabedian)?

---

<div class="post-metadata">

**Author:** ![Mark\_Nahabedian](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mark_nahabedian/32/16562_2.png) [@Mark\_Nahabedian](https://discourse.julialang.org/u/Mark_Nahabedian)\
**Post date:** [August 29, 2021, 1:20pm UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/14 "2021-08-29T13:20:45Z")

</div>

DNF: I don’t think I have a clear, coherent request.

Gustaphe:. Pretty neat.

I don’t understand how the existence of Overflow error and it’s behavior in gystaphe’s example is consistent with what I read in the Julia numbers doc about wrap-around. See [Integers and Floating-Point Numbers · The Julia Language](https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/) under “Overflow Behavior”. Can someone clarify this inconsistency?

---

<div class="post-metadata">

**Author:** ![gustaphe](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gustaphe/32/18174_2.png) [@gustaphe](https://discourse.julialang.org/u/gustaphe)\
**Post date:** [August 29, 2021, 1:30pm UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/15 "2021-08-29T13:30:10Z")

</div>

> [@Mark\_Nahabedian](#):
>
> what I read in the Julia numbers doc about wrap-around

I think that specifically applies to arithmetic. When doing `a + b`, it doesn’t check for overflow. `parse(T, s)` on the other hand, is assumed to be a rare and expensive enough operation, the overflow check is not a big overhead. Another way to view it is, there is a pretty clear and consistent way to interpret addition of two large numbers, but there is no obvious answer to what julia should do with `parse(Int8, "1234")`. It can only do normal overflow if it parses the entire number into a larger type (or somehow divides it into some arithmetic operations). An addition on the other hand doesn’t need to know that it’s overflowing, which is why the choice was made to not error.

---

<div class="post-metadata">

**Author:** ![Elrod](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/elrod/32/22461_2.png) [@Elrod](https://discourse.julialang.org/u/Elrod)\
**Post date:** [August 29, 2021, 1:47pm UTC](https://discourse.julialang.org/t/bug-parse-integer-calls-typemax/67252/16 "2021-08-29T13:47:06Z")

</div>

> [@Mark\_Nahabedian](#):
>
> I suppose at the hardware level the “extra” most negative twos compliment integer could be treated as an overflow indicator

On x86, many instructions will set the [CF](https://en.wikipedia.org/wiki/Carry_flag) (the carry flag) to indicate this. `inc` (increment) and `dec` (decrement) will not, for example, but `add`/`sub` will.