Sorry... i forgot to display the results:
+ True
+ False
That means the bug is in the dump or the load function!
On Feb 27, 10:33 am, Kenny <masso.ke...@gmail.com> wrote:
> 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...
>
> On Feb 27, 9:51 am, Maurizio <maurizio.gran...@gmail.com> wrote:
>
> > 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:
>
> > > On Wed, Feb 25, 2009 at 2:33 PM, Maurizio <maurizio.gran...@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
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
