In going from 5000x5000 to 1x1 Magma's time increases by a
factor of less than 4. That is impossible. Strassen will never help us
there. They must be doing something else. Probably something clever.
Bill.
On 17 May, 02:08, Bill Hart <[EMAIL PROTECTED]> wrote:
> That may not be necessary.
Hello,
SAGE is big, time is limited. Python is easy, but not all students
know it and like writing code.
I'd like SAGE to have what wxMaxima is for Maxima.
That is main actions can be achieved by clicking buttons instead of
writing code.
Html is very flexible to invent all kinds of UI,
but I don
Hello folks,
tomorrow, i.e. Saturday, won't be an official bug day, but some of us
will get together and do a coding sprint/merge sprint/general day of
getting things done. As usual we will meet in IRC and some people in
Seattle will also physically meet in some coffee shop. Either way, you
are w
That may not be necessary. It may only be necessary to know the size
of the L1 and L2 caches and then it is probably possible to figure out
the optimal values. Probably it is something like 2^k rows of B must
fit in half the L1 cache and BLOCK rows of A must fit in half the L1
cache.
I'm not sure
On 16 May, 23:05, Martin Albrecht <[EMAIL PROTECTED]>
wrote:
> On Friday 16 May 2008, Bill Hart wrote:
> > The other possibility is that Magma combines the two algorithms so
> > that there is even greater usage of the Gray code tables. This would
> > be an ugly hack, but could work.
>
> Are you
On May 17, 2:48 am, Bill Hart <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> That spike is wierd. Basically I got closer to 2x the time of Magma
> for 16384x16384, but you need different parameters than for
> 1x1 or 2x2 since the size of the M4R matrices will be
> different than in
Hi Martin,
That spike is wierd. Basically I got closer to 2x the time of Magma
for 16384x16384, but you need different parameters than for
1x1 or 2x2 since the size of the M4R matrices will be
different than in either of those cases.
For 16384x16384 my notes say that I used k = 6
Hello folks,
I finally fixed the libSingular vs. OSX 64 bit issue and also created
a binary
http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0.2/sage-3.0.2.alpha0-64bit-05-16-i386-Darwin.dmg
Caution: 0.5GB due to copious amounts of self build spkgs that I
didn't clean out.
We hav
On Fri, May 16, 2008 at 3:38 PM, Daniel Bump <[EMAIL PROTECTED]> wrote:
>
>
> In half_integral.py there is a link:
>
>ALGORITHM: Basmaji (page 55 of his Essen thesis, "Ein Algorithmus
>zur Berechnung von Hecke-Operatoren und Anwendungen auf modulare
>Kurven", http://wstein.org/scans/pa
In half_integral.py there is a link:
ALGORITHM: Basmaji (page 55 of his Essen thesis, "Ein Algorithmus
zur Berechnung von Hecke-Operatoren und Anwendungen auf modulare
Kurven", http://wstein.org/scans/papers/basmaji/).
The URL doesn't seem valid (and assuming it's Jacques Basmaji
On Friday 16 May 2008, Bill Hart wrote:
> Here are the times I get for Magma vs M4RI now. Note the crossover
> between the two programs is now above about 5000 and M4RI beats Magma
> below that point. This suggests the remaining factor of 2 is in the
> Strassen-Winograd function. Probably Winograd
On May 16, 8:08 am, "Robert Dodier" <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I've updated my copy of ECL to current CVS version and Maxima seems
> to be more broken than it was before. I'll try to figure out what is going on;
> maybe I am just doing something differently. But I'm curious to know
>
On Fri, May 16, 2008 at 12:06 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On May 16, 2008, at 12:01 PM, William Stein wrote:
>
>>
>> On Fri, May 16, 2008 at 11:58 AM, Robert Bradshaw
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> On May 16, 2008, at 8:57 AM, Nick Alexander wrote:
>>>
> (spe
On May 16, 2008, at 12:01 PM, William Stein wrote:
>
> On Fri, May 16, 2008 at 11:58 AM, Robert Bradshaw
> <[EMAIL PROTECTED]> wrote:
>>
>> On May 16, 2008, at 8:57 AM, Nick Alexander wrote:
>>
>>>
(specifically, sqrt(2) would
be an element of QQ[sqrt(2)] with a specified embedding into
On May 16, 2008, at 11:48 AM, William Stein wrote:
> On Fri, May 16, 2008 at 11:44 AM, Carl Witty
> <[EMAIL PROTECTED]> wrote:
>>
>> On May 16, 1:20 am, Robert Bradshaw <[EMAIL PROTECTED]>
>> wrote:
>>> What I think should happen is that sqrt(2) should be an element
>>> of QQ
>>> [sqrt(2)] ra
On Fri, May 16, 2008 at 11:58 AM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On May 16, 2008, at 8:57 AM, Nick Alexander wrote:
>
>>
>>> (specifically, sqrt(2) would
>>> be an element of QQ[sqrt(2)] with a specified embedding into RR, so
>>> stuff like RR(1) + sqrt(2) would work).
>>
>> Simila
On May 16, 2008, at 8:57 AM, Nick Alexander wrote:
>
>> (specifically, sqrt(2) would
>> be an element of QQ[sqrt(2)] with a specified embedding into RR, so
>> stuff like RR(1) + sqrt(2) would work).
>
> Similar to why matrices are over ZZ rather than QQ: why is sqrt(2) in
> QQ[sqrt(2)] and not in
On Fri, May 16, 2008 at 11:44 AM, Carl Witty <[EMAIL PROTECTED]> wrote:
>
> On May 16, 1:20 am, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> What I think should happen is that sqrt(2) should be an element of QQ
>> [sqrt(2)] rather than an element of SR. There is work supporting this
>> kind of
On May 16, 1:20 am, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> What I think should happen is that sqrt(2) should be an element of QQ
> [sqrt(2)] rather than an element of SR. There is work supporting this
> kind of thing in the new coercion model (specifically, sqrt(2) would
> be an element
Here are the times I get for Magma vs M4RI now. Note the crossover
between the two programs is now above about 5000 and M4RI beats Magma
below that point. This suggests the remaining factor of 2 is in the
Strassen-Winograd function. Probably Winograd-Strassen is falling out
of L2 cache (the previo
> (specifically, sqrt(2) would
> be an element of QQ[sqrt(2)] with a specified embedding into RR, so
> stuff like RR(1) + sqrt(2) would work).
Similar to why matrices are over ZZ rather than QQ: why is sqrt(2) in
QQ[sqrt(2)] and not in ZZ[sqrt(2)]?
Nick
--~--~-~--~~~--
On Friday 16 May 2008, Bill Hart wrote:
> P.S: I also tried cache hints, but no luck. They just slow it down.
>
> Bill.
Bill, thanks so much for looking into this! It is very much appreciated. I'm
going to read/try your patch right away!
Martin
PS: I have a slight delay in my replies because m
Hello,
I've updated my copy of ECL to current CVS version and Maxima seems
to be more broken than it was before. I'll try to figure out what is going on;
maybe I am just doing something differently. But I'm curious to know
whether anyone else is trying Maxima + ECL. At this point it looks like
it
P.S: I also tried cache hints, but no luck. They just slow it down.
Bill.
On 16 May, 15:59, Bill Hart <[EMAIL PROTECTED]> wrote:
> I tried cache blocking matrix B, but the times are exactly the same. I
> think the processor is happy to keep loading B one row at a time
> sequentially, and since i
I tried cache blocking matrix B, but the times are exactly the same. I
think the processor is happy to keep loading B one row at a time
sequentially, and since it is only done a handful of times in the
algorithm, it accounts for little of the runtime.
It might go faster in combination with storin
Here is the modified _mzd_mul_m4rm_impl function which gives this
speedup:
http://sage.math.washington.edu/home/wbhart/m4rmul.c
I used a crossover of 3600 and I indicate at the top of this file how
constants should be changed to get the speedups for the various values
of n. I didn't put any code
1x1 is down to 4.5s now, so nearly a 2x speedup.
2x2 is down to 32.0s, so again nearly a 2x speedup.
Bill.
On 16 May, 13:53, Bill Hart <[EMAIL PROTECTED]> wrote:
> I made some changes to the original code so it would use the cache a
> bit better. The test code seems to pass, so
The following message is a courtesy copy of an article
that has been posted to sci.math.symbolic as well.
Aldor & Axiom Workshop 2008
part of
RISC Summer 2008
I made some changes to the original code so it would use the cache a
bit better. The test code seems to pass, so I don't think I've screwed
anything up.
The time for 16384x16384 on my machine is now 20s, so a factor of
2.15x faster. The time for 2000x2000 also seems to be the same time as
Magma n
On Thu, May 15, 2008 at 11:11 PM, mhampton <[EMAIL PROTECTED]> wrote:
>
> I thought I would publicly state my own plans on this front, and some
> recent developments.
>
> Polymake is undergoing some architectural changes that may or may not
> make it more attractive for inclusion in sage. Their d
On May 16, 6:40 am, "William Stein" <[EMAIL PROTECTED]> wrote:
> I just noticed that if you type "sage math" into google (no quotes)
> then you get us first (of course),
> but you also get links to Download, Tutorial, Screen shots,
> Documentation, etc., all below. That's
> something I think we h
What I think should happen is that sqrt(2) should be an element of QQ
[sqrt(2)] rather than an element of SR. There is work supporting this
kind of thing in the new coercion model (specifically, sqrt(2) would
be an element of QQ[sqrt(2)] with a specified embedding into RR, so
stuff like RR(
This also works fine:
sage: GF(5)(-1).sqrt()
2
as does this
sage: a=GF(5)(2).sqrt()
sage: a
sqrt2
sage: a^2
2
but not GF(5)(sqrt(2)). I can see that coercing simple symbolic
expressions like sqrt(integer) into various fields would not be hard,
but handling arbitrary symbolic expressions would
We are certainly going to cause confusion if we don't implement this
symbolic simplification suggestion (+1):
sage: y=x-x
sage: y
0
sage: y==0
0 == 0
sage: 0==0
True
sage:
i.e. not all 0's ae the same. Now, I can understand why that is the
case (different rings) but it is not going to help begi
34 matches
Mail list logo
