-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
parse(Bool, s::String3)
giving InexactError
#57
Labels
bug
Something isn't working
Comments
This is a bug in Julia Base in my opinion. |
Also to be covered:
@quinnj - how do you want to handle this. I think:
to
|
quinnj
added a commit
to JuliaLang/julia
that referenced
this issue
Dec 2, 2022
Fixes JuliaStrings/InlineStrings.jl#57. We currently 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.
Ok, PR to fix Base is up: JuliaLang/julia#47782. Will look into what we should do in InlineStrings as well. |
quinnj
added a commit
to JuliaLang/julia
that referenced
this issue
Dec 6, 2022
* Generalize Bool parse method to AbstractString Fixes JuliaStrings/InlineStrings.jl#57. We currently 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. * Apply suggestions from code review Co-authored-by: Stefan Karpinski <stefan@karpinski.org> Co-authored-by: Nick Robinson <npr251@gmail.com> Co-authored-by: Stefan Karpinski <stefan@karpinski.org> Co-authored-by: Nick Robinson <npr251@gmail.com>
KristofferC
pushed a commit
to JuliaLang/julia
that referenced
this issue
Jul 11, 2023
* Generalize Bool parse method to AbstractString Fixes JuliaStrings/InlineStrings.jl#57. We currently 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. * Apply suggestions from code review Co-authored-by: Stefan Karpinski <stefan@karpinski.org> Co-authored-by: Nick Robinson <npr251@gmail.com> Co-authored-by: Stefan Karpinski <stefan@karpinski.org> Co-authored-by: Nick Robinson <npr251@gmail.com> (cherry picked from commit 63830a6)
KristofferC
pushed a commit
to JuliaLang/julia
that referenced
this issue
Oct 11, 2023
* Generalize Bool parse method to AbstractString Fixes JuliaStrings/InlineStrings.jl#57. We currently 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. * Apply suggestions from code review Co-authored-by: Stefan Karpinski <stefan@karpinski.org> Co-authored-by: Nick Robinson <npr251@gmail.com> Co-authored-by: Stefan Karpinski <stefan@karpinski.org> Co-authored-by: Nick Robinson <npr251@gmail.com> (cherry picked from commit 63830a6)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
is this expected to work? It was confusing hitting this when working with a DataFrame
The text was updated successfully, but these errors were encountered: