Yes the basic reference is ONAG. I will put a more precise
reference in the source (but I need to go to the library
to fetch ONAG). Basically the two rules for multiplying
nimbers are
(1) The product of any number of distinct Fermat powers
is the ordinary product.
(2) If f is a Fermat power then
Great! I am once again amazed by your speed.
I set SAGE_SERVER as you said, but my attempt at installing fails to
get the package. The output is appended below. I doing this on a PPC
(G4) Apple powerbook, with sage 2.0 upgraded to 2.3.
I had tried to read the documentation you suggested - I
Woo-hoo! Thank you!!!
I had the same error as before on my Mac Pro - the
'...
in open_local_file
raise IOError(e.errno, e.strerror, e.filename)
IOError: [Errno 2] No such file or directory: 'www.sagemath.org/
packages/optional/biopython-1.43.spkg'
sage: Failed to download package
On Mar 20, 2007, at 09:30 , Hamptonio wrote:
Just to clarify: the downloading problem isn't biopython-specific - I
can't get anything from www.sagemath.org through sage, only from a
browser. For example, 'sage -optional' fails as well.
www.sagemath.org seems to be down for the count. I'm
Hi,
Good news -- I took this downtime as a chance to install RHEL (Redhat
Enterprise Linux) on sage.math.washington.edu. By default it booted up with
a kernel that works and correctly recognizes all SIXTEEN cores on sage.math.
So now sage.math is twice as super, since before with Ubuntu only
On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
For some reason, google won't let me grab your patch. Anyway,
converting to string is not a good idea. Better to hash a tuple of
real, imag I think. (Maybe you did this already?)
You have to be really careful, since if a == b,
then
My guess is that the pari conversion code is not being careful with
the variable names, but I haven't really tried it. Makes it pretty
hard to work with number fields, no?
Nick
sage: (QQ['x'].0^2 + 1).is_irreducible()
True
sage: (QQ['a'].0^2 + 1).is_irreducible()
On 3/20/07, Nick Alexander [EMAIL PROTECTED] wrote:
My guess is that the pari conversion code is not being careful with
the variable names, but I haven't really tried it. Makes it pretty
hard to work with number fields, no?
Nick
sage: (QQ['x'].0^2 + 1).is_irreducible()
True
sage:
how hard would it be to make this work?
W.w1,w2 = ZZ['w1','w2']
factor(w1*w2)
big traceback
i'm using sage 2.3. if somebody could send me a code snippet,
it would be hugely appreciated.
kyle
--~--~-~--~~~---~--~~
To post to this group, send email to
On 3/20/07, Kyle Schalm [EMAIL PROTECTED] wrote:
how hard would it be to make this work?
W.w1,w2 = ZZ['w1','w2']
factor(w1*w2)
big traceback
i'm using sage 2.3. if somebody could send me a code snippet,
it would be hugely appreciated.
Work over QQ instead:
sage: W.w1,w2 =
Work over QQ instead:
sage: W.w1,w2 = QQ['w1','w2']
sage: factor(w1*w2)
w2 * w1
One can reduce factoring over ZZ to over QQ, with some work.
Volunteers...?
William
oh good, an easy workaround. the same trick doesn't seem to work if the
base ring is a polynomial ring, that is,
On Tuesday 20 March 2007 5:30 pm, Kyle Schalm wrote:
Work over QQ instead:
sage: W.w1,w2 = QQ['w1','w2']
sage: factor(w1*w2)
w2 * w1
One can reduce factoring over ZZ to over QQ, with some work.
Volunteers...?
William
oh good, an easy workaround. the same trick doesn't seem
there is trouble with the determinant method on a matrix over a funky ring
(yes, the same funky ring causing all my other problems). in its simplest
form:
In [43]: W.w=QQ['w']
In [44]: WZ.z=W['z']
In [45]: matrix(WZ,2,2,[1,z,z,z^2]).det()
Out[45]: kaboom!!!
the analog over a shallower
On 3/20/07, Kyle Schalm [EMAIL PROTECTED] wrote:
there is trouble with the determinant method on a matrix over a funky ring
(yes, the same funky ring causing all my other problems). in its simplest
form:
In [43]: W.w=QQ['w']
In [44]: WZ.z=W['z']
In [45]: matrix(WZ,2,2,[1,z,z,z^2]).det()
On Mar 20, 4:12 pm, William Stein [EMAIL PROTECTED] wrote:
On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
For some reason, google won't let me grab your patch. Anyway,
converting to string is not a good idea. Better to hash a tuple of
real, imag I think. (Maybe you did this
On Mar 21, 2007, at 1:19 AM, Nick Alexander wrote:
On Mar 20, 4:12 pm, William Stein [EMAIL PROTECTED] wrote:
On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
For some reason, google won't let me grab your patch. Anyway,
converting to string is not a good idea. Better to hash a
On Mar 20, 2007, at 10:27 PM, David Harvey wrote:
On Mar 21, 2007, at 1:19 AM, Nick Alexander wrote:
On Mar 20, 4:12 pm, William Stein [EMAIL PROTECTED] wrote:
On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
For some reason, google won't let me grab your patch. Anyway,
converting
On 3/20/07, David Harvey [EMAIL PROTECTED] wrote:
On Mar 21, 2007, at 1:19 AM, Nick Alexander wrote:
On Mar 20, 4:12 pm, William Stein [EMAIL PROTECTED] wrote:
On Tuesday 20 March 2007 4:00 pm, Nick Alexander wrote:
For some reason, google won't let me grab your patch. Anyway,
On Mar 21, 2007, at 1:38 AM, William Stein wrote:
That said, we simply can't require
(*) a == b == hash(a) == hash(b)
in SAGE, because mathematics is simply too complicated for this sort
of rule. So what is done in SAGE is to _attempt_ to satisfy (*)
when it
is reasonably easy to do
On Mar 21, 2007, at 1:37 AM, Robert Bradshaw wrote:
One could also force all keys of a
hashtable to live in a given ring.
I don't think you'd want to do that. First, it wouldn't even solve
the problem (e.g. because of the precision issues you raised before
-- you can have two elements of
20 matches
Mail list logo
