This one got me (by reading in a DataFrame via CSV).
Is this behavior intentional?
julia> using CSV
julia> x = String7( "4" )
"4"
julia> parse( Int, x )
4
julia> y = String7( "true" )
"true"
julia> parse( Bool, y )
ERROR: InexactError: Bool(10)
Stacktrace:
[1] Bool
@ ./float.jl:158 [inlined]
[2] convert
@ ./number.jl:7 [inlined]
[3] tryparse_internal(#unused#::Type{Bool}, s::String7, startpos::Int64, endpos::Int64, base_::Int64, raise::Bool)
@ Base ./parse.jl:126
[4] parse(::Type{Bool}, s::String7; base::Nothing)
@ Base ./parse.jl:241
[5] parse(::Type{Bool}, s::String7)
@ Base ./parse.jl:240
[6] top-level scope
@ REPL[5]:1
julia> z = String( y )
"true"
julia> parse( Bool, z )
true
Joris_Pinkse:
parse( Bool, y )
String7 belongs to the InlineStrings package. I guess this is an InlineStrings bug, however, itâs fixed in the latest version, v1.4.0, of InlineStrings.
Whatâs your version of InlineStrings? Try updating and see if it fixes the bug.
It doesnât appear to be fixed in v1.4.0.
mkitti
July 4, 2023, 10:16pm
4
I can confirm the error for InlineStrings 1.4.0. Incidentally, my related package StaticStrings.jl also has the same issue.
julia> parse(Bool, inline"true")
ERROR: InexactError: Bool(10)
Stacktrace:
[1] Bool
@ ./float.jl:171 [inlined]
[2] convert
@ ./number.jl:7 [inlined]
[3] tryparse_internal(#unused#::Type{Bool}, s::String7, startpos::Int64, endpos::Int64, base_::Int64, raise::Bool)
@ Base ./parse.jl:126
[4] parse(::Type{Bool}, s::String7; base::Nothing)
@ Base ./parse.jl:241
[5] parse(::Type{Bool}, s::String7)
@ Base ./parse.jl:240
[6] top-level scope
@ REPL[33]:1
julia> parse(Bool, inline"true"; base=2)
ERROR: InexactError: Bool(2)
Stacktrace:
[1] Bool
@ ./float.jl:171 [inlined]
[2] convert
@ ./number.jl:7 [inlined]
[3] tryparse_internal(#unused#::Type{Bool}, s::String7, startpos::Int64, endpos::Int64, base_::Int64, raise::Bool)
@ Base ./parse.jl:126
[4] parse(::Type{Bool}, s::String7; base::Int64)
@ Base ./parse.jl:241
[5] top-level scope
@ REPL[34]:1
julia> using StaticStrings
julia> parse(Bool, static"true"; base=2)
ERROR: InexactError: Bool(2)
Stacktrace:
[1] Bool
@ ./float.jl:171 [inlined]
[2] convert
@ ./number.jl:7 [inlined]
[3] tryparse_internal(#unused#::Type{Bool}, s::StaticString{4}, startpos::Int64, endpos::Int64, base_::Int64, raise::Bool)
@ Base ./parse.jl:126
[4] parse(::Type{Bool}, s::StaticString{4}; base::Int64)
@ Base ./parse.jl:241
[5] top-level scope
@ ~/.julia/packages/StaticStrings/oSXOl/src/macros.jl:19
The problem appears to be related to the base.
mkitti
July 4, 2023, 10:18pm
5
Meta.parse seems to work just fine though.
julia> Meta.parse(static"true")
true
julia> Meta.parse(inline"true")
true
nsajko
July 4, 2023, 10:22pm
6
Sorry, this was a Julia Base bug, it has been fixed seven months ago, but I guess the fix wasnât backported to any releases:
JuliaLang:master â JuliaLang:jq-parse-bool-abstractstring
opened 04:46PM - 02 Dec 22 UTC
Fixes https://github.com/JuliaStrings/InlineStrings.jl/issues/57.
We currentl⌠y have a specialization for `parse(Bool, ::Union{String, SubString{String})` where `true` and `false` are parsed appropriately. The restriction to `Union{String, SubString{String}}`, however, means we don't get this behavior for other `AbstractString`s. In the linked issue above, for InlineStrings, we end up going through the generic integer parsing codepath which results in an `InexactError` when we try to do `Bool(10)`.
The proposal in this PR takes advantage of the fact that there is only the 2 comparisons where we do `_memcmp` that require the input string to be "dense" (in memory), and otherwise, we just do a comparison against a `SubString` of the input string.
Relatedly, I've wanted to introduce the concept of an abstrac type like:
```julia
abstract type MemoryAddressableString <: AbstractString
```
where the additional required interface would be being able to call `pointer(::MemoryAddressableString)`, since a lot of our string algorithms depend on doing these kind of pointer operations and hence makes it quite a pain to implement your own custom string type.
parse certainly works for me on nightly Julia.
This should be fixed in 1.6.8, 1.8.5, 1.9.3, and 1.10.0 (none of which have been released atm)
[Edit: corrected]
Lilith:
1.9.2
Actually, v1.9.2 was released two days ago. I think you mean v1.9.3, because v1.9.2 still seems to be buggy.