Saving "singular" values (or anything with a weird Sage interface)

[Nathann Cohen]

Helloooooo everybody,

A friend of mine just reported something which may be considered as a bug:

sage: x=singular(3)
sage: save(x,"/tmp/aaa.sobj")

Several days later:

sage: load("/tmp/aaa.sobj")
(invalid object -- defined in terms of closed session)

This, because 'x' is not an integer but a reference for a singular value.

Sooo what do we do? Perhaps we should convert this reference toward a
Sage object if we can, but if we cannot then perhaps we should give a
warning? It seems that saving these objects will always turn out to be
a disappointment.

Have fuuuuuuuuun,

Nathann

P.S.: The same happens if you run the 'load' command right after the
'save'. So even if the session still exists the result is lost.

[Volker Braun]

Realistically, we don't have a chance of pickling interface objects when we don't have any deeper understanding of the object in the interfaced system. Unless the interfaced system supports pickling natively, which few do.

So my suggestion would be to define x.dumps() as x.sage().dumps(), that is, just pickle the value in Sage. Doesn't work for the singular(3) example since the conversion Singular integers->Sage integers hasn't been implemented but at least you get the error immediately and not later when you try to load the object.

[Nathann Cohen]

Helloooooooooooo,

> Realistically, we don't have a chance of pickling interface objects when we
> don't have any deeper understanding of the object in the interfaced system.
> Unless the interfaced system supports pickling natively, which few do.

Yep yep.

> So my suggestion would be to define x.dumps() as x.sage().dumps(), that is,
> just pickle the value in Sage. Doesn't work for the singular(3) example
> since the conversion Singular integers->Sage integers hasn't been
> implemented but at least you get the error immediately and not later when
> you try to load the object.

Sounds right. Better have an exception now than lost data.

Is there anybody around who would know how to change that? I don't
feel much at home around pickling and interfaces ^^;

Nathann

[Dima Pasechnik]

On Friday, 3 July 2015 10:36:45 UTC+1, Nathann Cohen wrote:

Helloooooooooooo,

> Realistically, we don't have a chance of pickling interface objects when we
> don't have any deeper understanding of the object in the interfaced system.
> Unless the interfaced system supports pickling natively, which few do.

Yep yep.

> So my suggestion would be to define x.dumps() as x.sage().dumps(), that is,
> just pickle the value in Sage. Doesn't work for the singular(3) example
> since the conversion Singular integers->Sage integers hasn't been
> implemented but at least you get the error immediately and not later when
> you try to load the object.

 

At least this will work for (most) GAP objects.
 

[Dima Pasechnik]

this is now http://trac.sagemath.org/ticket/18848

[Simon King]

Hi Nathann,

On 2015-07-03, Nathann Cohen <nathan...@gmail.com> wrote:
> Is there anybody around who would know how to change that? I don't
> feel much at home around pickling and interfaces ^^;

I can try. Is there a ticket yet?

Cheers,
Simon

[Dima Pasechnik]

you are cc'd on it now

Cheers,
Simon

[Simon King]

On 2015-07-03, Dima Pasechnik <dim...@gmail.com> wrote:
> this is now http://trac.sagemath.org/ticket/18848

Thanks!