I was a bit reluctant to post this question here since "support"
shouldn't mean teaching me how to write programs. But Jason Grout
suggested me to post it here anyway.
Here is a very short script that I want to maximize the speed
def lspec(n):
return sorted([k if k^2 < 2*n else 2*n/k for k
> Another puzzling thing is that
> b=[ ]
> %timeit b.extend([2])
> 100 loops, best of 3: 801 ns per loop
>
> type(b)
>
>
> but then when I run
>
> %timeit b+[2]
> 10 loops, best of 3: 88.9 ms per loop
>
> That's much slower, in fact if you simple type b and hit enter... SAGE
> hangs.
This is
> In trying to utilize the method of unknown coefficients I ended up
> with this doozy:
>
> y=A*Exp(3*t)+B*t*Exp(3*t)+C*t^2*Exp(3*t)+D
>
> How can I get sage to treat A-D as arbitrary constants when
> differentiating.
You just have to tell sage to think of them as variables:
sage: var('A B C D t
This is just a quick question
In trying to utilize the method of unknown coefficients I ended up
with this doozy:
y=A*Exp(3*t)+B*t*Exp(3*t)+C*t^2*Exp(3*t)+D
How can I get sage to treat A-D as arbitrary constants when
differentiating.
--~--~-~--~~~---~--~~
To post
On Nov 15, 2008, at 5:02 PM, pong wrote:
>
> According to diveintopython .extend should be faster than + since the
> former does not return a value.
> I was curious and tried
>
> %timeit [ ]+[2]
> 100 loops, best of 3: 741 ns per loop
> and
>
> %timeit [ ].extend([2])
> 100 loops, best of
According to diveintopython .extend should be faster than + since the
former does not return a value.
I was curious and tried
%timeit [ ]+[2]
100 loops, best of 3: 741 ns per loop
and
%timeit [ ].extend([2])
100 loops, best of 3: 870 ns per loop
so + actually beats .extend slightly.
I
On Sat, Nov 15, 2008 at 1:03 AM, Jason Grout
<[EMAIL PROTECTED]> wrote:
>
> William Stein wrote:
>>> * Vector and field visualization
>>
>> New? I wonder how? It seems like they have had this for a long time.
>
> There are lots of cool visualations you could do with vector fields that
> they don
On Sat, Nov 15, 2008 at 10:20 AM, Jason Grout
<[EMAIL PROTECTED]> wrote:
>
> pong wrote:
>>
>> I have turned some codes that I have from PARI/GP into SAGE script but
>> I find that they are order of magnitude slower than the original
>> codes. Both types of codes are complied (i.e. I have .run in
Jason Grout wrote:
> pong wrote:
>> I have turned some codes that I have from PARI/GP into SAGE script but
>> I find that they are order of magnitude slower than the original
>> codes. Both types of codes are complied (i.e. I have .run in PARI and
>> spyx files for SAGE) and running on the same ma
pong wrote:
>
> I have turned some codes that I have from PARI/GP into SAGE script but
> I find that they are order of magnitude slower than the original
> codes. Both types of codes are complied (i.e. I have .run in PARI and
> spyx files for SAGE) and running on the same machine.
>
> I am sure
I have turned some codes that I have from PARI/GP into SAGE script but
I find that they are order of magnitude slower than the original
codes. Both types of codes are complied (i.e. I have .run in PARI and
spyx files for SAGE) and running on the same machine.
I am sure that's because I don't kno
11 matches
Mail list logo
