Parse with exponent D

General Usage
,
1

I tried parsing the values printed to file by some old Fortran code. This code uses the exponent D for double precision numbers, like 2.73150000000000003D+02.

I can use the replace command to replace the “D” with “E”, but wondered if this should be built into parse.

Example

julia> parse(Float64, "1.0E+4")
10000.0

julia> parse(Float64, "1.0D+4")
ERROR: ArgumentError: cannot parse "1.0D+4" as Float64
Stacktrace:
 [1] _parse_failure(T::Type, s::String, startpos::Int64, endpos::Int64)
   @ Base .\parse.jl:388
 [2] #tryparse_internal#623
   @ .\parse.jl:384 [inlined]
 [3] tryparse_internal
   @ .\parse.jl:381 [inlined]
 [4] parse(::Type{Float64}, s::String)
   @ Base .\parse.jl:394
 [5] top-level scope
   @ REPL[14]:1

julia>
2

Fortran’s D is for decimal floating point — so I think this would make the most sense in DecFP.jl. Parsing them as Float64s would potentially yield different values.

I don’t think it currently supports Ds in its parse(Dec64, x), but I imagine it could without much consternation.

3

No it isn’t. D exponents as in 1.0D+4 stand for double precision. By default this will be the same as Julia’s Float64 on most hardware and compilers these days.

See also this stackoverflow thread: https://stackoverflow.com/questions/77397170/why-cant-julia-parse-functions-parse-numbers-in-scientific-notation-with-d-inst?utm_source=chatgpt.com — currently the easiest solution is to do a replace call on the string before parsing.

See also this issue on whether we should have a more flexible parse for floating-point values: `parse` can't parse our own Float32 output format · Issue #5690 · JuliaLang/julia · GitHub — currently even parse(Float32, "1.0f0") doesn’t work, even though the "f" exponent is allowed by Julia itself. Personally, my vote would be to allow more flexibility in accepting the most common formats when parsing data, since parse(T, str) is generally inequivalent to Julia syntax (Meta.parse) anyway.

3 Likes
4

:person_facepalming: well, never mind me! That’s me misreading these random docs about the “decimal double-precision” — where decimal is apparently meaning just “fractional,” not base 10. It makes a bit more sense that that 2.7315 example isn’t quite exact.

5

It would probably be best to add this option to one of the generic parser libraries out there, eg

I would suggest opening an issue.