Parsing BigFloat in generated Julia code

[eringh]

Generated Julia code is (at lest on my machine, Julia 1.6.0) written as

coeff1=0.00383407335032704596164376098882956709489410248615638010744708335697776575140132556149544440996986827984

However, decimal literals are converted to Float64 when parsed. Hence,

julia> coeff1=0.00383407335032704596164376098882956709489410248615638010744708335697776575140132556149544440996986827984
0.003834073350327046

julia> typeof(coeff1)
Float64

To be parsed as a BigFloat it should be written as

julia> coeff1=big"0.00383407335032704596164376098882956709489410248615638010744708335697776575140132556149544440996986827984"
0.00383407335032704596164376098882956709489410248615638010744708335697776575140132556149544440996986827984

julia> typeof(coeff1)
BigFloat

I suggest adding a code-snippet like this

coeff_i_code = (big(T)==T) ?
        (split(coeff_i_code,"=")[1]*"=big\""*split(coeff_i_code,"=")[2]*"\"") :
        (coeff_i_code)

after line 227 in gen_julia_code.jl.
Thoughts? The code generation is not my specialty...

[jarlebring]

Does it work with Complex{BigFloat}?

I think it would be cleaner to insert this logic into these two functions.

https://github.com/jarlebring/GraphMatFun.jl/blob/0ef2384d27457d85ad7ec7b27fa0c55e70105a8d/src/code_gen/gen_julia_code.jl#L27-L33

I recommend turning them into function ... for readability. It's okay to use T=typeof(v).

[eringh]

Does it work with Complex{BigFloat}?

julia> big(Complex{BigFloat}) == Complex{BigFloat}
true

[jarlebring]

Does it work with Complex{BigFloat}?

julia> big(Complex{BigFloat}) == Complex{BigFloat}
true

Yes. The complex case in the generated code needs another look

julia> v=big(3.0+4.0im); s= "big\"$v\"";

julia> println(s)
big"3.0 + 4.0im"

julia> big"3.0 + 4.0im"
ERROR: ArgumentError: invalid number format 3.0 + 4.0im for BigInt or BigFloat

[eringh]

Good catch!

julia> v=big"3.0"+big"1.2"*im; vr=real(v); vi=imag(v); s="big\"$vr\" + big\"$vi\"*im";

julia> println(s)
big"3.0" + big"1.200000000000000000000000000000000000000000000000000000000000000000000000000007"*im

julia> a = big"3.0" + big"1.200000000000000000000000000000000000000000000000000000000000000000000000000007"*im
3.0 + 1.200000000000000000000000000000000000000000000000000000000000000000000000000007im

julia> typeof(a)
Complex{BigFloat}

Edit:
Better still would be:

julia> v=parse(Complex{BigFloat},"3.0+1.2im"); T=typeof(v); s="parse($T, \"$v\")";

julia> println(s)
parse(Complex{BigFloat}, "3.0 + 1.200000000000000000000000000000000000000000000000000000000000000000000000000007im")

julia> a = parse(Complex{BigFloat}, "3.0 + 1.200000000000000000000000000000000000000000000000000000000000000000000000000007im")
3.0 + 1.200000000000000000000000000000000000000000000000000000000000000000000000000007im

julia> typeof(a)
Complex{BigFloat}

[eringh]

Do we always want to use parse, or de we prefer normal assignment for Float64?
The former is more consistent, the latter more readable for cases when parse is not needed.

[jarlebring]

No idea. I don't see that it makes a big difference. Decide what you think is best.

[eringh]

Not sure if I do this correct but I get some interesting results. Maybe we shouldn't call parse at all.

julia> @btime begin; a = 12345.6789; end;
  0.001 ns (0 allocations: 0 bytes)

julia> @btime begin; a = parse(Float64, "12345.6789"); end;
  443.434 ns (0 allocations: 0 bytes)

julia> @btime begin; a = big"12345.6789"; end;
  1.300 ns (0 allocations: 0 bytes)

julia> @btime begin; a = parse(BigFloat, "12345.6789"); end;
  511.518 ns (2 allocations: 112 bytes)

julia> @btime begin; a = big"12345.6789"+big"456.789"*im; end;
  288.298 ns (14 allocations: 640 bytes)

julia> @btime begin; a = parse(Complex{BigFloat}, "12345.6789+456.789im"); end;
  1.410 μs (7 allocations: 320 bytes)

Perhaps uglier code, but we could rely on the @big_str macro for BigFloat and Complex{BigFloat} and do nothing for Float64? Seems like the overhead in calling parse is larger than the extra allocations in the complex case.

[jarlebring]

Not sure you are suggesting to call parse for Float64 etc. If so, the answer is no.

Note that you are now trying to optimize generated bigfloat code which we never really focused on and will not be in the paper. Make a decision and move on. ;-)