reusing solutions in functions

[Harald Schilly]

In IRC I had a question and I don't know how to do it ...

If you have a solution of an equation, how to apply the result to a
function?

sage: var('x y')
(x, y)
sage: solve([x+y==6, x-y==4], x, y)
[[x == 5, y == 1]]
sage: f = 2*x+y

The best I came up is

sage: f.subs(dict([ (s.lhs() , s.rhs()) for s in sol[0]]))
11

My proposal is, that Sage does this automatically, e.g. just

sage: f(sol[0])
11

Other ideas? Is this already possible?

Harald

[Mike Hansen]

I'd do something like this:

sage: var('x y')
(x, y)

sage: d, = solve([x+y==6, x-y==4], x, y, solution_dict=True)
sage: d
{y: 1, x: 5}
sage: f = 2*x+y
sage: f.subs(d)
11

--Mike

[Harald Schilly]

On Feb 19, 10:18 pm, Mike Hansen <mhan...@gmail.com> wrote:
> I'd do something like this:

yes, thanks. it's just not very intuitive because you have to know the
solution_dict parameter in advance. i don't know, but it would be
interesting if a syntax like f(sol[0]) could be implemented - or does
it have too many side effects...

h

[rjf]

Maxima's solve sometimes produces answers (assuming they can be found)
as lists of equations, e.g. [x=a,y=b].

The syntax for substitution has several versions.

subst(3,x,x+y) ---> y+3.

subst(x=3,x,x+y)

subst([x=3,y=4],x+y) --> 7

Solve can also produce systems of solutions, e.g.

sols: [[x=a,y=b], [x=c,y=d]]


in which case subst(sols[1],x+y) ---> a+b

There are also cases in which solve cannot find a closed form, in
which case it might return something like

x=sin(x) where x appears on lhs and rhs.

It would generally be a bad idea to use a "solution" like this if you
wanted x to disappear.

If Sage just uses Maxima, you might want to know about these options.
If Sage is re-inventing this kind of
facility, you might find this worth either emulating or explicitly
rejecting for something else.

RJF

[Robert Bradshaw]

I think this is a very worthwhile thing to implement, at least if the
LHS are all single variables.

- Robert

[Maurizio]

That was the way I used to do it when I discovered the solution_dict
param.

So, I started using the dictionaries to do substitution even in
complex expressions... The result was to wait so much time!

On the contrary, I found that the subs(expr, x=<value>) was SOOOO much
faster (are the dictionaries so slow to deal with?).

So, I implemented a subList function, where I can pass an expression,
and a list of substitution, in the very same way that the solve()
function returns the results.

So, now I put all my subsets of numerical values in list like this:
set = [x == 10, y == 20, z == 30, ...]
and do the substitution like this:
result = subList(expr, set)

Within the function, I just iterate the subs(expr, x = <value>) on the
number of list elements.

This seems to me much faster than using dictionaries, especially for
complex expressions.

Maurizio

[Harald Schilly]

On Feb 21, 12:30 pm, Maurizio <maurizio.gran...@gmail.com> wrote:
> So, I started using the dictionaries to do substitution even in
> complex expressions... The result was to wait so much time!

That sounds bad, can you give an example? Or create one so that others
can investigate it?

> result = subList(expr, set)

I still think that it would be nice enhancement for the call function
of an expression, to work for such solution sets or dicts.

H

[Robert Bradshaw]

On Feb 21, 2009, at 3:30 AM, Maurizio wrote:

> That was the way I used to do it when I discovered the solution_dict
> param.
>
> So, I started using the dictionaries to do substitution even in
> complex expressions... The result was to wait so much time!
>
> On the contrary, I found that the subs(expr, x=<value>) was SOOOO much
> faster (are the dictionaries so slow to deal with?).
>
> So, I implemented a subList function, where I can pass an expression,
> and a list of substitution, in the very same way that the solve()
> function returns the results.
>
> So, now I put all my subsets of numerical values in list like this:
> set = [x == 10, y == 20, z == 30, ...]
> and do the substitution like this:
> result = subList(expr, set)
>
> Within the function, I just iterate the subs(expr, x = <value>) on the
> number of list elements.
>
> This seems to me much faster than using dictionaries, especially for
> complex expressions.

If this is the case, this is clearly a bug.

- Robert

[Maurizio]

People, please let me understand this! Let me give you my example so
that you can help me recognizing where is my mistake

I've this function:

G_igr_d ( <class 'sage.calculus.calculus.SymbolicArithmetic'> )

(2*Iin*rCb/Lf + 2*Vb/Lf)*(s*rCf*(1/(Cf*rCf + Cf*Rs) + s)/((rCf +
Rs)*(s*((1/(Cf*rCf + Cf*Rs) + s)*(2*rCf*rQ/(Lf*rCf + Lf*Rs) +
2*Rs*rQ/(Lf*rCf + Lf*Rs) + rCf*rLf/(Lf*rCf + Lf*Rs) + Rs*rLf/(Lf*rCf +
Lf*Rs) + 2*Iin*rCb*rCf/(Lf*rCf + Lf*Rs) + Rs*rCf/(Lf*rCf + Lf*Rs) +
Rs*2*Iin*rCb/(Lf*rCf + Lf*Rs) + s) + Rs^2/((Cf*rCf + Cf*Rs)*(Lf*rCf +
Lf*Rs))) - (2*Duty/Cb - 1/Cb)*(1/Lf - 2*Duty/Lf)*(1/(Cf*rCf + Cf*Rs) +
s))) + Rs*s/((rCf + Rs)*(Cf*rCf + Cf*Rs)*(s*((1/(Cf*rCf + Cf*Rs) +
s)*(2*rCf*rQ/(Lf*rCf + Lf*Rs) + 2*Rs*rQ/(Lf*rCf + Lf*Rs) +
rCf*rLf/(Lf*rCf + Lf*Rs) + Rs*rLf/(Lf*rCf + Lf*Rs) +
2*Iin*rCb*rCf/(Lf*rCf + Lf*Rs) + Rs*rCf/(Lf*rCf + Lf*Rs) +
Rs*2*Iin*rCb/(Lf*rCf + Lf*Rs) + s) + Rs^2/((Cf*rCf + Cf*Rs)*(Lf*rCf +
Lf*Rs))) - (2*Duty/Cb - 1/Cb)*(1/Lf - 2*Duty/Lf)*(1/(Cf*rCf + Cf*Rs) +
s)))) - 2*ILf*((2*Duty/Lf - 1/Lf)*rCf*(1/(Cf*rCf + Cf*Rs) + s)/((rCf +
Rs)*(s*((1/(Cf*rCf + Cf*Rs) + s)*(2*rCf*rQ/(Lf*rCf + Lf*Rs) +
2*Rs*rQ/(Lf*rCf + Lf*Rs) + rCf*rLf/(Lf*rCf + Lf*Rs) + Rs*rLf/(Lf*rCf +
Lf*Rs) + 2*Iin*rCb*rCf/(Lf*rCf + Lf*Rs) + Rs*rCf/(Lf*rCf + Lf*Rs) +
Rs*2*Iin*rCb/(Lf*rCf + Lf*Rs) + s) + Rs^2/((Cf*rCf + Cf*Rs)*(Lf*rCf +
Lf*Rs))) - (2*Duty/Cb - 1/Cb)*(1/Lf - 2*Duty/Lf)*(1/(Cf*rCf + Cf*Rs) +
s))) - (1/Lf - 2*Duty/Lf)*Rs/((rCf + Rs)*(Cf*rCf + Cf*Rs)*(s*((1/
(Cf*rCf
+ Cf*Rs) + s)*(2*rCf*rQ/(Lf*rCf + Lf*Rs) + 2*Rs*rQ/(Lf*rCf + Lf*Rs) +
rCf*rLf/(Lf*rCf + Lf*Rs) + Rs*rLf/(Lf*rCf + Lf*Rs) +
2*Iin*rCb*rCf/(Lf*rCf + Lf*Rs) + Rs*rCf/(Lf*rCf + Lf*Rs) +
Rs*2*Iin*rCb/(Lf*rCf + Lf*Rs) + s) + Rs^2/((Cf*rCf + Cf*Rs)*(Lf*rCf +
Lf*Rs))) - (2*Duty/Cb - 1/Cb)*(1/Lf - 2*Duty/Lf)*(1/(Cf*rCf + Cf*Rs) +
s))))/Cb

and

params = [
rCf == 1*m_, Cf == 4.7*u_,
rCb == 10*m_, Cb == 22*u_,
rLf == 1*m_, Lf == 1.65*m_,
rQ == 10*m_,
Iin == 300/400,
Rs == 0.2,
Vrms == 220,
Vgr_pk == 220*sqrt(2),
]

paramsd = {
"rCf" : 1*m_, "Cf" :4.7*u_,
"rCb" :10*m_, "Cb" :22*u_,
"rLf" :1*m_, "Lf" :1.65*m_,
"rQ" :10*m_,
"Iin" :300/400,
"Rs" :0.2,
"Vrms" :220,
"Vgr_pk" :220*sqrt(2),
}

NOTE: the m_, u_, etc. are just the multipliers previously defined in
a .sage file (m_ = 1e-3, u_ = 1e-6, etc.)

They are exactly the same subset

If I do

time dizSub = G_igr_d.subs(paramsd)
CPU time: 14.40 s, Wall time: 31.44 s

time G_id = subList(G_igr_d,params)
CPU time: 1.17 s, Wall time: 5.59 s

Why is it so? Please note that this has been done with SAGE : 'SAGE
Version 3.1.2, Release Date: 2008-09-19'

I've tried out this at home (but with simpler expressions) with the
latest SAGE, and the subs with the dictionary actually was faster.

Thank you

Maurizio

On Feb 21, 4:48 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:

[Maurizio]

excuse me guys, I didn't want to bother you with my long example (I
thought that could be a good idea to give something reproducible) ,
but can you at least tell me some reason why in my case the subs with
the dictionary is so slow (especially with respect to the substitution
with equations)?

thanks

Maurizio

[YannLC]

If I try your example at home with sage-3.3, I obtain:

sage: time dizSub=G_igr_d.subs(paramsd)
CPU times: user 0.03 s, sys: 0.00 s, total: 0.03 s
Wall time: 0.03 s
sage: dizsub
(0.00497512437811*s*(s + 1058537.10173)/(s*((s + 22.4212271973)*(s +
1058537.10173) + 127669181.574) - (606.060606061 - 1212.12121212*Duty)*
(90909.0909091*Duty - 45454.5454545)*(s + 1058537.10173)) +
1053270.74799*s/(s*((s + 22.4212271973)*(s + 1058537.10173) +
127669181.574) - (606.060606061 - 1212.12121212*Duty)*
(90909.0909091*Duty - 45454.5454545)*(s + 1058537.10173)))*
(1212.12121212*Vb + 9.09090909091) - 90909.0909091*ILf*
(0.00497512437811*(1212.12121212*Duty - 606.060606061)*(s +
1058537.10173)/(s*((s + 22.4212271973)*(s + 1058537.10173) +
127669181.574) - (606.060606061 - 1212.12121212*Duty)*
(90909.0909091*Duty - 45454.5454545)*(s + 1058537.10173)) -
1053270.74799*(606.060606061 - 1212.12121212*Duty)/(s*((s +
22.4212271973)*(s + 1058537.10173) + 127669181.574) - (606.060606061 -
1212.12121212*Duty)*(90909.0909091*Duty - 45454.5454545)*(s +
1058537.10173)))

[Maurizio]

Thank you very much Yann!!
Today I upgraded to SAGE 3.3, to check if there was an improvement,
but I had the very same results than before.

Now I see this strange behaviour:

time dizSub = G_igr_d.subs(paramsd)
Time: CPU 10.64 s, Wall: 21.53 s

But if I do:

var('s')
temp = (2*Iin*rCb/Lf + 2*Vb/Lf)*(s*rCf*(1/(Cf*rCf + Cf*Rs) + s)/((rCf

+
Rs)*(s*((1/(Cf*rCf + Cf*Rs) + s)*(2*rCf*rQ/(Lf*rCf + Lf*Rs) +
2*Rs*rQ/(Lf*rCf + Lf*Rs) + rCf*rLf/(Lf*rCf + Lf*Rs) + Rs*rLf/(Lf*rCf +

Lf*Rs) + rCb*rCf/(Lf*rCf + Lf*Rs) + Rs*rCf/(Lf*rCf + Lf*Rs) +
Rs*rCb/(Lf*rCf + Lf*Rs) + s) + Rs^2/((Cf*rCf + Cf*Rs)*(Lf*rCf +

Lf*Rs)))
- (2*Duty/Cb - 1/Cb)*(1/Lf - 2*Duty/Lf)*(1/(Cf*rCf + Cf*Rs) + s))) +
Rs*s/((rCf + Rs)*(Cf*rCf + Cf*Rs)*(s*((1/(Cf*rCf + Cf*Rs) +
s)*(2*rCf*rQ/(Lf*rCf + Lf*Rs) + 2*Rs*rQ/(Lf*rCf + Lf*Rs) +

rCf*rLf/(Lf*rCf + Lf*Rs) + Rs*rLf/(Lf*rCf + Lf*Rs) + rCb*rCf/(Lf*rCf +
Lf*Rs) + Rs*rCf/(Lf*rCf + Lf*Rs) + Rs*rCb/(Lf*rCf + Lf*Rs) + s) +

Rs^2/((Cf*rCf + Cf*Rs)*(Lf*rCf + Lf*Rs))) - (2*Duty/Cb - 1/Cb)*(1/Lf -
2*Duty/Lf)*(1/(Cf*rCf + Cf*Rs) + s)))) - 2*ILf*((2*Duty/Lf -
1/Lf)*rCf*(1/(Cf*rCf + Cf*Rs) + s)/((rCf + Rs)*(s*((1/(Cf*rCf + Cf*Rs)
+
s)*(2*rCf*rQ/(Lf*rCf + Lf*Rs) + 2*Rs*rQ/(Lf*rCf + Lf*Rs) +

rCf*rLf/(Lf*rCf + Lf*Rs) + Rs*rLf/(Lf*rCf + Lf*Rs) + rCb*rCf/(Lf*rCf +
Lf*Rs) + Rs*rCf/(Lf*rCf + Lf*Rs) + Rs*rCb/(Lf*rCf + Lf*Rs) + s) +

Rs^2/((Cf*rCf + Cf*Rs)*(Lf*rCf + Lf*Rs))) - (2*Duty/Cb - 1/Cb)*(1/Lf -
2*Duty/Lf)*(1/(Cf*rCf + Cf*Rs) + s))) - (1/Lf - 2*Duty/Lf)*Rs/((rCf +

Rs)*(Cf*rCf + Cf*Rs)*(s*((1/(Cf*rCf + Cf*Rs) + s)*(2*rCf*rQ/(Lf*rCf +
Lf*Rs) + 2*Rs*rQ/(Lf*rCf + Lf*Rs) + rCf*rLf/(Lf*rCf + Lf*Rs) +

Rs*rLf/(Lf*rCf + Lf*Rs) + rCb*rCf/(Lf*rCf + Lf*Rs) + Rs*rCf/(Lf*rCf +
Lf*Rs) + Rs*rCb/(Lf*rCf + Lf*Rs) + s) + Rs^2/((Cf*rCf + Cf*Rs)*(Lf*rCf

+
Lf*Rs))) - (2*Duty/Cb - 1/Cb)*(1/Lf - 2*Duty/Lf)*(1/(Cf*rCf + Cf*Rs) +
s))))/Cb

So I manually write down the same expression in a new variable, I get:

time dizTemp = temp.subs(paramsd)
Time: CPU 0.01 s, Wall: 0.01 s

And temp and G_igr_d have the same type!!

Where can the lag arise from? This seems really subtle to me!
Please note that the expression is coming from some matrix
combinations and then extraction

Regards

Maurizio

[Carl Witty]

On Wed, Feb 25, 2009 at 11:05 AM, Maurizio <maurizio...@gmail.com> wrote:
> So I manually write down the same expression in a new variable, I get:
>
> time dizTemp = temp.subs(paramsd)
> Time: CPU 0.01 s, Wall: 0.01 s
>
> And temp and G_igr_d have the same type!!
>
> Where can the lag arise from? This seems really subtle to me!
> Please note that the expression is coming from some matrix
> combinations and then extraction

Maybe you could publish a notebook worksheet, or attach a script,
showing a complete worked example to demonstrate the slowness?

Carl

[Maurizio]

Carl,
this is certainly reasonable, but maybe a little unfeasible.

The reason is that, I use some scripts of mine in the process of the
evaluation, and the whole process is pretty long.

The algorithm basically starts from a couple of linear systems of
equations; they are solved, and from the solution is derived the
(averaged) state space representation of the system, in terms of:

dx/dt = A*x + B*u
y = C*x + B*u

Then, the matrices are combined to get the matrix of input-to-state
and input-to-output transfer functions (in the Laplace transform
domain) as:
x/u = (s*I - A)**(-1)*B
y/u = C*(s*I - A)**(-1)*B + D

So, the G_igr_d (the function initially shown), is one element of this
matrix.

As you can see, the process is not particularly complex, but a bit
long, and that would oblige me to upload some custom scripts as well.

Can you derive some information from this description, or has this
been useless? Maybe I can provide something like the last part of the
notebook, placing some intermediate expression by hand.

Could you also show me where should I look at for better understanding
this? Is it a good idea to verify the types of the expressions used?
Is it a problem interfacing to any symbolic package different from the
ordinary maxima one? I don't exactly recall if I took advantage of
others.

Thanks

Maurizio

On Feb 25, 9:17 pm, Carl Witty <carl.wi...@gmail.com> wrote:

[Carl Witty]

On Wed, Feb 25, 2009 at 2:33 PM, Maurizio <maurizio...@gmail.com> wrote:
>
> Carl,
> this is certainly reasonable, but maybe a little unfeasible.

...

> Can you derive some information from this description, or has this
> been useless? Maybe I can provide something like the last part of the
> notebook, placing some intermediate expression by hand.

The description doesn't help me. I'm willing to take a brief look if
I have a simple reproduction case, but your description doesn't give
me much hope of reproducing the problem. (It might be enough to give
a hint to somebody familiar with the code, but I'm not.)

You could try:
test = loads(dumps(bad_expr))
where bad_expr is the slow one. If test acts the same as bad_expr (is
similarly slow), then that means that you can just do:
save(bad_expr, 'slow_substitution.sobj')
and post slow_substitution.sobj.

> Could you also show me where should I look at for better understanding
> this? Is it a good idea to verify the types of the expressions used?
> Is it a problem interfacing to any symbolic package different from the
> ordinary maxima one? I don't exactly recall if I took advantage of
> others.

I see that you're substituting in a symbolic value. Does it change
anything if you change Vgr_pk to a numeric value instead?

Looking at types is good.

Probably where I would start is by running the slow command, pressing
Control-C when it's about halfway through, and looking at the
backtrace to see if I could figure out what was going on. The problem
would almost certainly be related to something on the backtrace, so
that's a reasonable place to start. My first guess would be that
you'll discover that the slowness is because it's interacting with
maxima somehow; if that's the case, then you need to figure out why.

Using other symbolic packages might or might not be a problem. (It's
not supposed to be a problem, but we're assuming there's a bug
somewhere. Interfaces between separate packages are always a fruitful
place for bugs.)

Carl

[Maurizio]

Carl,
I should thank you in advance for your great help.

Unfortunately, the dumps test doesn't improve the result:

time test = loads(dumps(G_igr_d.subs(paramsd)))
Time: CPU 13.32 s, Wall: 33.21 s

Moreover, I'm working from the notebook, so I am not able to get the
backtrace by interrupting the process

Right now, I've saved into three .sobj the three key elements:
G_igr_d, paramsd, and the result of G_igr_d.subs(paramsd) (what you
called "bad_expr"), now can you show me a point where I can upload it
so that you can have a look?

I really appreciate

Regards

Maurizio

> You could try:
> test = loads(dumps(bad_expr))
> where bad_expr is the slow one.  If test acts the same as bad_expr (is
> similarly slow), then that means that you can just do:
> save(bad_expr, 'slow_substitution.sobj')
> and post slow_substitution.sobj.
>
> > Could you also show me where should I look at for better understanding
> > this? Is it a good idea to verify the types of the expressions used?
> > Is it a problem interfacing to any symbolic package different from the
> > ordinary maxima one? I don't exactly recall if I took advantage of
> > others.
>
> I see that you're substituting in a symbolic value.  Does it change

> anything if you changeVgr_pkto a numeric value instead?

[Carl Witty]

On Thu, Feb 26, 2009 at 12:26 AM, Maurizio <maurizio...@gmail.com> wrote:
>
> Carl,
> I should thank you in advance for your great help.
>
> Unfortunately, the dumps test doesn't improve the result:
>
> time test = loads(dumps(G_igr_d.subs(paramsd)))
> Time: CPU 13.32 s, Wall: 33.21 s
>
> Moreover, I'm working from the notebook, so I am not able to get the
> backtrace by interrupting the process
>
> Right now, I've saved into three .sobj the three key elements:
> G_igr_d, paramsd, and the result of G_igr_d.subs(paramsd) (what you
> called "bad_expr"), now can you show me a point where I can upload it
> so that you can have a look?

I was actually calling G_igr_d "bad_expr", but it doesn't matter.

If you don't have any publicly available web space, you could just
email them to me privately and I'll stick them in public space on
sage.math (and take a quick look myself).

Carl

[Maurizio]

You are certainly very kind.
I really appreciate your help. I'm going to email you the expressions.

Thank you

On 26 Feb, 18:15, Carl Witty <carl.wi...@gmail.com> wrote:

[Carl Witty]

On Thu, Feb 26, 2009 at 9:26 AM, Maurizio <maurizio...@gmail.com> wrote:
>
> You are certainly very kind.
> I really appreciate your help. I'm going to email you the expressions.

The files are now available at
http://sage.math.washington.edu/home/cwitty/slow-substitution/
I won't be able to look at them until this evening (maybe now+8 hours).

Carl

[Carl Witty]

On Wed, Feb 25, 2009 at 2:33 PM, Maurizio <maurizio...@gmail.com> wrote:

> Is it a problem interfacing to any symbolic package different from the
> ordinary maxima one? I don't exactly recall if I took advantage of
> others.

OK, I spent some time looking at this, and this may indeed be the
problem. I have a workaround for your case, but I may need more
information to get somebody to actually fix the problem.

Can you try this test:

var('Cb')
G_igr_d._operands[1]._operands[1] is Cb

and report what the last line prints?

If it prints False, then you're seeing what I'm seeing: somehow you
have two different synbolic variable objects, both named Cb.
Ordinarily you would only ever have one such object. With two
separate objects, Python can't immediately answer the question whether
Cb_1==Cb_2, so it asks Maxima (which says yes, they're equal).

In that case, the workaround is to do:
G_works = SR(repr(G_igr_d))
This is an ugly hack that prints out G_igr_d, and then parses it back
in; doing so makes it use the standard variable objects.

If this is the problem, can you try to remember how you actually got
G_igr_d? It seems like the problem actually might be the integration
with some other symbolic system, and it would be very helpful to know
which one.

Carl

[Maurizio]

Carl,
you were totally right.

The results are matching your previsions. I get:

var('Cb')
G_igr_d._operands[1]._operands[1] is Cb

False

G_works = SR(repr(G_igr_d))
time G_works.subs(paramsd)

Time: CPU 0.16 s, Wall: 0.86 s



I add now another aspect: the G_igr_d is symbolically evaluated in
another worksheet, then I save it, and I load it back in the "numeric"
worksheet, where I do all the numerical maths.

If I go to the "symbolic" worksheet, I get:

G_igr_d._operands[1]._operands[1] is Cb

True

What does this mean?
Please note that in the symbolic worksheet, the Cb is declared only
once (on top) as:
var('Cb rCb Cf rCf Lf rLf Rs rQ')

in the same way it is done in the numeric worksheet:
var('rQ rCb rLf rCf Duty')
var('Cb Lf Cf')

What am I missing? I don't seem to catch any particular interaction
with other symbolic system. The functions I use are:
solve and subs, symplify and expand, matrix operations ( + * **(-1) ),
matrix augmentation (augment), and then matrix extraction of elements
(by column and row index)

Any other info is needed? Hopefully this can fix an undiscovered bug,
or at least fix my mistake (which maybe can be helpful as well to the
community!)

Maurizio

On 27 Feb, 02:58, Carl Witty <carl.wi...@gmail.com> wrote:

[Kenny]

I've took a look a the example code, and so I think that the bug is
in the dumps and load function:

var('Rs')
mio = Rs + Rs*Rs + sqrt(10)
tuo=loads(dumps(mio))
print mio._operands[0]._operands[0] is Rs
print tuo._operands[0]._operands[0] is Rs

IAt this time I've not looked inside the code, but I think that it
will be simple for the developer of
this functions to find the solution! :)

If there is not an intrepid volunteer I will look at that on
Saturday...

[Kenny]

Sorry... i forgot to display the results:

+ True
+ False

That means the bug is in the dump or the load function!

[Maurizio]

Hello,

I was able to reproduce this in Sage 3.3

var('a b c')
first = a + b + c
first._operands[0]._operands[0] is a

True

second = loads(dumps(first))
second._operands[0]._operands[0] is a

False

Should anyone open a bug in trac? I am not sure of how to do that and
which function to address this bug, but it seems definitely something
worth it, don't you think?

Thank you

Maurizio

On 27 Feb, 10:35, Kenny <masso.ke...@gmail.com> wrote:
> Sorry... i forgot to display the results:
>
> + True
> + False
>

> That means thebugis in thedumpor the load function!

[Maurizio]

Is anybody interested in looking at this?

Thank you very much

[Mike Hansen]

On Tue, Mar 10, 2009 at 1:57 AM, Maurizio <maurizio...@gmail.com> wrote:
>
> Is anybody interested in looking at this?

There is no problem with loads/dumps -- it is something specific to
the SymbolicVariable class. In any case, I put a patch up at
http://trac.sagemath.org/sage_trac/ticket/5466 with a more appropriate
description.

--Mike

[Georg S. Weber]

On 10 Mrz., 09:57, Maurizio <maurizio.gran...@gmail.com> wrote:
> Is anybody interested in looking at this?
>
> Thank you very much
>

Hi,

it is now trac ticket #5471 --- any volunteers to work on it?

Cheers,
gsw

[Georg S. Weber]

Ups,

soory Mike,
I was caught by the "25 messages cutoff" and didn't see your post.
The ticket newly created by me is a double, of course :-(

Cheers,
gsw

On 10 Mrz., 21:14, "Georg S. Weber" <GeorgSWe...@googlemail.com>
wrote:

[Georg S. Weber]

Hi,

trac ticket #5466 now has a positive review.


Cheers,
gsw

[Maurizio]

this is really meaningful to me, and a very positive feedback from
this wonderful community

thanks!