Why shouldn't the parse function accept all representation of numeric literals in Julia?

[udohjeremiah]

I was doing a test on the parse function, and I came across something I don't know if I should call a bug yet, or if it was the intended design by the core developers of Julia.

The Julia doc says this:

Unsigned integers are input and output using the 0x prefix and hexadecimal (base 16) digits 0-9a-f (the capitalized digits A-F also work for input).

So it makes intuitive sense for this 👇 to work (and it works):

julia> parse(Int, "0x123")
291

julia> parse(Int, "afc", base = 16)
2812

Again, the doc says this:

Literal floating-point numbers are represented in the standard formats, using E-notation when necessary.

So it makes intuitive sense for this 👇 to work as well (and it works):

julia> parse(Float64, "1.2E-2")
0.012

julia> parse(Float32, "1.2e2")
120.0f0

As the doc continues, it goes further to say this:

Hexadecimal floating-point literals are also valid, but only as Float64 values, with p preceding the base-2 exponent:

So, again it makes intuitive sense for this 👇 to work too (and it works):

julia> parse(Float64, "0x1p3")
8.0

julia> parse(Float32, "0x1p3")
8.0f0

THIS IS NOW MY ARGUMENT
Finally, the doc says this:

Literal Float32 values can be entered by writing an f in place of e:

So, it makes intuitive sense for this 👇 to work too (BUT IT THROWS AN ERROR):

julia> parse(Float64, "1.2f-2")
ERROR: ArgumentError: cannot parse "1.2f-2" as Float64
[...]

julia> parse(Float32, "1.2f2")
ERROR: ArgumentError: cannot parse "1.2f2" as Float32
[...]

My question is:

• If it's an intended design, are there any valid reasons to it?
• If it's a bug (which I believe its not), I've tried fixing it up and pushing a pull request, but guess my head is too small for now to wrap it around the parse.jl file, so please look into it.

[KristofferC]

Even Float32s are printed with e:

julia> print(1f10)
1.0e10

The f syntax is Julia specific and imo parsing that is more like parsing Julia code where Meta.parse should be used:

julia> Meta.parse("1f0")
1.0f0

[udohjeremiah]

I am not worried or talking about the function print(). What I'm more concerned about is:
Why should a language reject its own internal representation of numeric literals?

All other cases are supported by parse as I pointed above, so there should be a very good reason why this is disallowed and possibly be spelled out in the docs, so people should be aware - as it makes no sense ordinarily.

Talking about Julia specific, I don't think you're utterly right. Other languages like Java and many others uses the F literal to create primitive types. Yes, its capital letter most times, but then that doesn't qualify it to be a language specific trait; if it is, then we can say 1.2E-2 is Julia specific, because it allows e to be in capital letter as E.

So, yes it might not be supported, but Why should a language reject its own internal representation of numeric literals?

[udohjeremiah]

Another reason why this of vital importance to either spell out in the docs (with a good reason), or allowed to run without an error is because developers using Julia tends to use more of parse() than convert(). So, yes, convert should work fine, but this 👇 just seems ugly in a way:

julia> convert(Float64, 0.1E-2)          # figures this works out
0.001

julia> parse(Float64, "0.1E-2")         # figures this works out as well
0.001

julia> convert(Float64, 1.2f-2)         # then he tries this and sees same behaviour
0.012000000104308128


#= hopefully he writes code with this 👇 expecting same behaviour but an error
is raised and he can't figure out where the subtle bug is, because he doesn't expect
this to throw an error and when he finally figures out the subtle bug, he can't figure
out why that should throw an error from the docs or anywhere. =#
julia> parse(Float64, "1.2f-2")
ERROR: ArgumentError: cannot parse "1.2f-2" as Float64
[...]

[KristofferC]

How do you end up with wanting to parse a float that is written with the f syntax? Not from Julia, since when you print such a float to a stream or a file you get it with e.

developers using Julia tends to use more of parse() than convert()

convert and parse have totally different functionality so I don't really understand why you are talking about them like they are exchangeable.

[udohjeremiah]

@KristofferC you keep emphasising on the print functionality which is not what my issue is.

parse says this

help?> parse
search: parse tryparse partialsortperm partialsortperm! pairs skipchars

  parse(type, str; base)

  Parse a string as a number. For Integer types, a base can be specified
  (the default is 10). For floating-point types, the string is parsed as
  a decimal floating-point number. Complex types are parsed from decimal
  strings of the form "R±Iim" as a Complex(R,I) of the requested type;
  "i" or "j" can also be used instead of "im", and "R" or "Iim" are also
  permitted. If the string does not contain a valid number, an error is
  raised.

Parse a string as a number
If the string does not contain a valid number, an error is raised.

So is this string a valid numeral literal in Julia?

julia> "1f-2"
"1f-2"

julia> string(1f-2)    
"0.01"

1f-2 is a valid numeric literal, so why exactly should it fail, when the doc says "an error is only raised when the string does not contain a valid number"?

julia> parse(Float64, "1f-2") 
RROR: ArgumentError: cannot parse "1f-2" as Float64
[...]

If 1f-2 is a valid numeral literal in Julia, then it should work with parse. But if it is not (which in this case isn't, causing more subtle errors), then please state explictly on the docs why it should fail and what are possibly the reasons for it.

You keep emphasising on the print, which in my view can be e if Julia chooses to, but please give a reason (a good one because its just doesn't makes sense ordinarily) why 1f-2 works with everything that does some conversion except parse - but then parse says it parses a string as a number and then 1f-2 is a valid string that can be converted to a number but then throws an error.

[udohjeremiah]

This is another example where surprisingly I fell into today, just a day after the parse confusion.

julia> 0x1 + 0x2
0x03

julia> 1 + 12f0im
1.0f0 + 12.0f0im

julia> 1 + 0x2p4im
1.0 + 32.0im

julia> 1 + 1.2e-2im
1.0 + 0.012im

julia> 1 + 0x23im
ERROR: syntax: invalid numeric constant "0x23i"
[...]

Just as it makes no sense on why parse should fail here (and even when it makes sense, why isn't the docs spelling it out or is it so trivial an issue?):

julia> parse(Float64, "1f-2") 
ERROR: ArgumentError: cannot parse "1f-2" as Float64
[...]

So it makes no sense here for this not to juxtapose as a valid complex number:

julia> 1 + 0x23im
ERROR: syntax: invalid numeric constant "0x23i"
[...]

But this then works:

julia> 1 + UInt8(0x23)im
1 + 35im

julia> UInt8(0x23)
0x23

On different occasions, I just find myself getting confused on why Julia refused to accepts its own numeric literal representation

[KlausC]

I agree with some shortcomings in Base.parse and Meta.parse, once we accept that both functions are doing different things, in general.
At the same time, they should behave coherently if applied to a set of strings representing numbers.

1. Base.parse(::Type{<:AbstractFloat}, ...)
   Should accept "1f0" ... and interpret it like "1e0" ... (debatable?)

2. Base.parse(::Type{<:Complex{<:Integer}, ...)
   Should accept "0x1im" , 0x2i", "0xaj" ... like it does for Complex{<:AbstractFloat}.

3. Base.parse
   Docstring should describe all cases (currently missing: hexadecimal integers and floats, complex integers)

4. Meta.parse and REPL / compiler input
   Should parse "0xaim" as :( 0x0a * im) and not throw a syntax error, like it parses "0xap0im" as :(10.0 * im)`

That could be separated into 2 issues and PRs, IMO.

@udohjeremiah if I missed cases you found, please add them.

[udohjeremiah]

@KlausC WOW!!! I'm so amazed at how you summed up my points I'm driving at. Thank you and hopefully they'll look into it.

Julia's domain is scientific computing (even though we know its has general use cases), so if a language should perform poorly (base on documentation and intuitive use-cases) on simple number stuffs, it shouldn't be Julia, and to worsen it all, it shouldn't even be a language still trying to get adopted mainstream (by my own definition).

@KristofferC I said people used Base.parse more than convert, not because I didn't know they had different use cases, but because when you work with strings a lot, Base.parse is probably the easiest route you would usually follow a lot of the times. So you see working with numbers become a terrifying activity when you know Base.parse will behave weird on multiple cases when you're parsing strings into numbers from a file containing numbers from all different numeric literals.