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 th
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 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
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
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
ano
On Wed, Feb 25, 2009 at 2:33 PM, Maurizio 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
On Thu, Feb 26, 2009 at 9:26 AM, Maurizio 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 even
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 wrote:
> On Thu, Feb 26, 2009 at 12:26 AM, Maurizio wrote:
>
> > Carl,
> > I should thank you in advance for your great help.
>
> > Unfortunately, the dump
On Thu, Feb 26, 2009 at 12:26 AM, Maurizio 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
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
On Wed, Feb 25, 2009 at 2:33 PM, Maurizio 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 inter
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 sol
On Wed, Feb 25, 2009 at 11:05 AM, Maurizio 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 subtl
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/L
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 -
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)?
tha
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 ( )
(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*r
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
On Feb 21, 12:30 pm, Maurizio 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
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=) was S much
faster (are the dictionaries so
On Feb 19, 2009, at 2:43 PM, Harald Schilly wrote:
>
> On Feb 19, 10:18 pm, Mike Hansen 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 l
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
On Feb 19, 10:18 pm, Mike Hansen 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 si
On Thu, Feb 19, 2009 at 1:08 PM, Harald Schilly
wrote:
>
> 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
23 matches
Mail list logo
