On Jan 14, 6:05 pm, adrian wrote:
> Hi,
Hi,
> > It goes back to CDE, so it has been around for a while. If you look
> > into /usr/dt/bin there is all kinds of other goodies that might be
> > useful. Since backward compatibility is extremely high on Solaris I
> > think this solution will work
Hi,
> It goes back to CDE, so it has been around for a while. If you look
> into /usr/dt/bin there is all kinds of other goodies that might be
> useful. Since backward compatibility is extremely high on Solaris I
> think this solution will work for a while :)
I just compiled xdg-utils in the oth
On Jan 14, 5:34 pm, adrian wrote:
Hi Adrian,
> I downloaded the file from
>
> http://portland.freedesktop.org/download/xdg-utils-1.0.2.tgz
>
> and compiled it locally. It worked!
Ok, I am somewhat surprised those freedesktop bits are not shipped
with Solaris 10, but maybe OpenSolaris has th
I downloaded the file from
http://portland.freedesktop.org/download/xdg-utils-1.0.2.tgz
and compiled it locally. It worked!
I was using the cholesterol free desktop (xfce), and then the terminal
spat the exo-open not found, as it seems to be the one used by the
xfce to open files.
In this mac
On Thursday 15 January 2009, dmharvey wrote:
> On Jan 14, 5:41 pm, Bill Hart wrote:
> > There's only one conclusion possible. The Schoenhage/Nussbaumer FFT
> > David has written in zn_poly for multiplication of polys over Z/pZ is
> > truly much better on Intel than the Kronecker Segmentation/Scho
On Jan 14, 4:55 pm, adrian wrote:
> Hi Michael,
Hi,
> > I guess the fix did not make it into that binary. Manually opening the
> > notebook should work and I added getting the fix into Sage 3.3 to my
> > list.
>
> The strange thing is that it did open the default browser and showed
> the (emp
On Jan 14, 5:41 pm, Bill Hart wrote:
> There's only one conclusion possible. The Schoenhage/Nussbaumer FFT
> David has written in zn_poly for multiplication of polys over Z/pZ is
> truly much better on Intel than the Kronecker Segmentation/Schoenhage-
> Strassen FFT method used in FLINT.
zn_pol
Hi Michael,
> I guess the fix did not make it into that binary. Manually opening the
> notebook should work and I added getting the fix into Sage 3.3 to my
> list.
The strange thing is that it did open the default browser and showed
the (empty) list of worksheets the first time. Only the second
On Jan 14, 4:41 pm, "William Stein" wrote:
> On Wed, Jan 14, 2009 at 4:33 PM, adrian wrote:
>
> > This is the actual info. By looking at the file, it shows a criptic
> > $@, so I assume that it is called from somewhere else with that extra
> > argument.
>
> If you run the notebook command wit
On Wed, Jan 14, 2009 at 4:33 PM, adrian wrote:
>
> This is the actual info. By looking at the file, it shows a criptic
> $@, so I assume that it is called from somewhere else with that extra
> argument.
If you run the notebook command without the open_viewer=False command,
then sage tries to op
On Jan 14, 4:33 pm, adrian wrote:
Hi Adrian,
> This is the actual info. By looking at the file, it shows a criptic
> $@, so I assume that it is called from somewhere else with that extra
> argument.
Yeah, this is some annoying buglet I did fix in some other build, but
I guess the fix did no
This is the actual info. By looking at the file, it shows a criptic
$@, so I assume that it is called from somewhere else with that extra
argument.
/export/user1/sage/local/src/sage-3.2.3-Solaris-10_US_IIIi/local/bin/
sage-native-execute: line 8: xdg-open: command not found
On Jan 14, 5:30 pm,
I tried the binary, and here is what I got:
First I modified the file toolchain.bash
then I did
source toolchain.bash
And then, now with the right enviroment, went to the sage directory
and ran sage
Then I ran sage -notebook
The first time I had no problems.
The second time, it did not open
Hi,
I have rebuild Sage 3.2.3 + more fixes than previously with a new
toolchain that fixes the numpy/scipy crashes. The binary and its
toolchain can be found in
http://sage.math.washington.edu/home/mabshoff/solaris-binaries/
* sage-3.2.3-Solaris-10_SSE3.tar.gz at 380 MB
* x86_64-solaris-gc
Here's some more info:
It's not a caching issue. I've tried adjusting the expected cache size
in FLINT from very small to very large. It makes little difference.
It's quite amazing that these Intel machines appear completely
oblivious to how big their caches are.
The total time taken for the lar
mhampton wrote:
> I agree this is a bug. Another way that works in the above example
> is:
>
> vector(RDF, vector((1, 6.8)))
>
> which I like a little better because I think its good when code is
> explicit about what sort of object is being dealt with.
Then you are changing the ring, though.
I agree this is a bug. Another way that works in the above example
is:
vector(RDF, vector((1, 6.8)))
which I like a little better because I think its good when code is
explicit about what sort of object is being dealt with.
Marshall
On Jan 14, 3:41 pm, Jason Grout wrote:
> slabbe wrote:
> >
Properly tuned, for a length 10^6 multiplication with 40 bit modulus,
zn_poly takes 1.59s and FLINT 2.22s on sage.math. So zn_poly is quite
a bit faster on Intel machines than FLINT. No idea why that is. But it
is very impressive!!
Bill.
On 14 Jan, 20:37, Bill Hart wrote:
> I did some more timi
slabbe wrote:
> Hi,
>
> Is there a reason why, in sage 3.2.2, the following works :
>
> sage: vector(vector((1, 6)))
> (1, 6)
>
> but the following doesn't :
>
> sage: vector(vector((1, 6.8)))
> Traceback (most recent call last):
> ...
> TypeError: _vector_() takes exactly one argument (0 give
Hi,
Is there a reason why, in sage 3.2.2, the following works :
sage: vector(vector((1, 6)))
(1, 6)
but the following doesn't :
sage: vector(vector((1, 6.8)))
Traceback (most recent call last):
...
TypeError: _vector_() takes exactly one argument (0 given)
???
Thank you,
Sébastien Labbé
UQA
I did some more timings and I've been bitten by the timing
irregularities on my Opteron again.
For length 1,000,000 and 40 bits FLINT takes about 1.57s and zn_poly
1.46s. I tried using the --use-flint option in zn_poly, but presumably
this multiplication is outside the KS range and so the timing
On Wed, Jan 14, 2009 at 9:49 AM, james hughes wrote:
>
> On Jan 14, 2009, at 9:08 AM, james hughes wrote:
>>
>> In terms of Sage, is there an equivalent thing to GridMathematica? We have
>> machines with 256 hardware threads and I really want to demo Sage using them
>> all.
>
> I see both DSage a
On the 2.4GHz Opteron zn_poly reports that it takes 1.46s for this
multiplication. That is certainly faster than FLINT. So it looks like
zn_poly really is better for longer length polynomials now.
It's not clear what the improvement was, but it looks like better
tuning code, from the zn_poly CHAN
On a 2.4Ghz Opteron FLINT takes 1.92s for the multiplication. So at
least there is no serious speed regression in FLINT.
I now need to time zn_poly and see if it does better than FLINT on the
Opteron.
Bill.
On 14 Jan, 17:09, Bill Hart wrote:
> I did the timings from FLINT directly and indeed i
I did the timings from FLINT directly and indeed it takes 2.5s for a
40 bit modulus and length 10^6. This agrees with what comes out of
Martin's version of Sage.
So, only 3 possibilities remain:
1) Serious speed regression in FLINT
2) David's improved tuning for zn_poly *really* makes a differen
On Wed, Jan 14, 2009 at 8:44 AM, Bill Hart wrote:
>
> I'm trying to inspect the gmp in your installation to see if maybe the
> Core 2 patches aren't installed or something, but I'm having trouble
> opening the spkg named gmp-4.2.2.p1.fake. Is that where the gmp is? I
> thought these were just tar
I'm trying to inspect the gmp in your installation to see if maybe the
Core 2 patches aren't installed or something, but I'm having trouble
opening the spkg named gmp-4.2.2.p1.fake. Is that where the gmp is? I
thought these were just tar files or bzip2 files?
Bill.
On 14 Jan, 16:29, Martin Albre
On Wednesday 14 January 2009, Bill Hart wrote:
> I checked back through the correspondence I had and the timing I am
> thinking of is for a 40 bit modulus at length 1,000,000. David and I
> compared at the time and zn_poly version 0.4.1 took 2.06s compared to
> FLINT at 2.37s, at that stage, on th
On Wednesday 14 January 2009, Bill Hart wrote:
> On 13 Jan, 12:17, Martin Albrecht
>
> wrote:
> > The following is multiplication of two random polynomials over
> > GF(140737488355328) of length n
> >
> > n FLINT zn_poly
> >
> > 131072 0.292 0.220
> > 262144 0.612 0.454
> >
I checked back through the correspondence I had and the timing I am
thinking of is for a 40 bit modulus at length 1,000,000. David and I
compared at the time and zn_poly version 0.4.1 took 2.06s compared to
FLINT at 2.37s, at that stage, on the old sage.math.
The zn_poly changelog shows that Davi
On 13 Jan, 12:17, Martin Albrecht
wrote:
> The following is multiplication of two random polynomials over
> GF(140737488355328) of length n
>
> n FLINT zn_poly
> 131072 0.292 0.220
> 262144 0.612 0.454
> 524288 1.522 1.028
> 1048576 3.136 2.096
These are unexpected
On Jan 13, 10:13 pm, DavidS wrote:
> Hi Michael,
Hi David,
> So the previous problem disappeared, but I ran into 2 more problems,
> one of which is still unresolved.
> It has been reported earlier that the fortran compiler that comes with
> sage does not work well with Archlinux. The work-aro
Hi,
I spend some more time on getting clisp to play nice with Maxima on
Solaris 10/Sparc and after building gcc *3.2.3* (quite ironic) I got a
binary that for now works. Since clisp will be gone from Sage in the
next week I guess this was kind of pointless, but at least I got it to
work :).
I ha
33 matches
Mail list logo
