ArbNumerics.jl vs. JLD2.jl
dfriedan opened this issue · 5 comments
ArbNumerics.jl and JLD2.jl seem to be incompatible.
(My first time using github. Sorry for any formatting glitches.)
example (in JupyterLab with kernel Julia v"1.10.2")
in Notebook 'save'
using JLD2
using ArbNumerics
x = ArbFloat("1.1")
@save("file.jld2", x)
in Notebook 'load'
using JLD2
using ArbNumerics
@load("file.jld2", x)
x
0.0005682636956492356473207022587786823202077626484829105
The value of x reported in the 'load' notebook is not consistent. It changes from run to run. Sometimes, the Julia kernel bombs instead of showing a value for x. The bug does not seem to appear for x=ArbFloat(1), or x=ArbFloat(0), but only when the argument of ArbFloat() is a string.
Daniel Friedan
New High Energy Theory Center
and Department of Physics & Astronomy
Rutgers University
Thank you for the report and welcome to github.
Using Julia v10.2 directly (in the "REPL", not in a notebook) this does not occur.
using ArbNumerics, JLD2
x = ArbFloat("1.1")
@save("file.jld2", x)
@load("file.jld2", x)
x # 1.1
I have no information about the notebook application.
Please try this (in the notebook). Let me know what happens.
using ArbNumerics, JLD2
x = ArbFloat(BigFloat("1.1"))
@save("file.jld2", x)
@load("file.jld2", x)
x
FYI x = ArbFloat(1.1) Julia first converts 1.1 to a Float64 (C double) and only then calls ArbFloat, so there is much less precision doing it that way.
As long as you have a way that works with the notebook, stay with the notebook. It is a good solution. And no, saving state in the "REPL" for another time is more involved .. although you can use JLD2 just like in the notebook. I will implement the use of BigFloat as an intermediary when converting strings to ArbFloat. Thanks again!
[If you need additional help with Julia, let me know]
I fear, there is no support for serializing the Arb floating point objects in the current version.
ArbNumerics.jl doesn't support serialization/deserialization. The contained fields are of type Int or UInt , but sometimes are used to encode pointers to data areas, which lose their meanings in other processes (if you serialize to a file and try to deserialize in another session).
That means, if you store a value, which uses a pointer to a memory area, but which is disguised as a UInt64, this integer value is stored. When later read in a different process, this integer value is reproduced, but its interpretation as a pointer has no sensible meaning: it points to a random memory area or leads to a segmentation violation, as was observed by the OP.
It would be necessary to support explicitly the serialization/deserialization process of JLD2 in ArbNumerics to overcome this behavior. The same is true for all other serialization packages.