ArbNumerics.jl vs. JLD2.jl

[dfriedan]

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

[JeffreySarnoff]

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.

[dfriedan]

Hi, Your version works fine in a single notebook. I don't know the "REPL". (I'm a newcomer to Julia.) Can you do the save in one session of the "REPL" and then the load in a separate session? My main application for JLD2 is to save ode solutions for later analysis. Thanks for the quick response. Not sure how I should reply to your email so I replied twice, hitting the 'reply' button and then the 'reply list' button (in Thunderbird). best regards, Daniel

…

On 2024-05-28 5:31 PM, Jeffrey Sarnoff wrote: 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. — Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BIZJCCKDO3K4UGNHGLQEBATZETZTZAVCNFSM6AAAAABINSRRG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZWGE2DIMZSGU>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[JeffreySarnoff]

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]

[KlausC]

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.

[dfriedan]

Interesting. I guess I'll have to give up on trying to use ArbNumerics.jl. I need to be able to save a sample of my ode to disk, so I can resume running the ode later on (in real time). I suppose I can save in BigFloat form (with high precision). But I'm uneasy to change number format in the middle of an ode. thanks, Daniel Daniel Friedan

…

On 2024-05-28 6:48 PM, Klaus Crusius wrote: 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. — Reply to this email directly, view it on GitHub <#69 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BIZJCCISBAEWZP2CAARH5ULZEUCTRAVCNFSM6AAAAABINSRRG2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZWGIZTCMBVHE>. You are receiving this because you authored the thread.Message ID: ***@***.***>