Hi,
I could not find a gcc-4.5 install on eno, to replicate the bug.
On which machine did you run it? (before I start compile it!)
Could you also attach the linbox config.log to ticket #8769 ?
Thanks.
Clément
William Stein a écrit :
Hi,
Main point of this email: if anybody else is trying to
RJF asks me to forward this, since it bounced for him, evidently.
-- Forwarded message --
From: Richard Fateman
Date: Mon, Apr 26, 2010 at 10:15 PM
Subject: Re: [sage-devel] numerically stable fast univariate
polynomial multiplication over RR[x]
To: William Stein
Cc: sage-d
On Mon, Apr 26, 2010 at 6:29 AM, Stephen Loo wrote:
> Hi,
>
> I have upgraded source from 4.3.5 under Mac OS X 10.6.3 x86-64. And
> output error message below
Try forcing a rebuild of ecl with
sage -f ecl-10.2.1.spkg
Then try "sage -upgrade" again.
William
>
> Summary:
> ECL enabled. Exec
On Apr 25, 2010, at 12:30 AM, Simon King wrote:
Hi Robert!
On 25 Apr., 07:30, Robert Bradshaw
wrote:
Are you looking for something
likehttp://www.sagemath.org/doc/reference/sage/structure/coerce.html
? It could probably be written up better, but we don't want too
much
redundancy.
This
On Apr 25, 2010, at 8:25 AM, Nathan O'Treally wrote:
On 25 Apr., 07:30, Robert Bradshaw
wrote:
Are you looking for something
likehttp://www.sagemath.org/doc/reference/sage/structure/coerce.html
? It could probably be written up better, but we don't want too
much
redundancy.
There's als
On Apr 25, 2010, at 8:38 AM, Nathan O'Treally wrote:
On 25 Apr., 09:30, Simon King wrote:
* Other users may believe that a rose is a rose is a rose, and 1 is 1
is 1. Such users would find it gross that GF(2)(1)==1 and 1==GF(3)
(1),
but GF(3)(1)!=GF(2)(1).
Btw, a rose might be a rose in Pyt
On Apr 26, 2010, at 8:07 PM, William Stein wrote:
On Mon, Apr 26, 2010 at 8:00 PM, Jason Grout
wrote:
When multiplying two univariate polynomials over RR[x], Sage uses
the naive
O(n^2) algorithm. The docstring for _mul_ cites numerical
stability as the
reason to not use asymptotically fas
> I think Robert Miller is the one to ask though.
I would love to answer.. After I defend my dissertation in two weeks!
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more op
On Mon, Apr 26, 2010 at 8:00 PM, Jason Grout
wrote:
> When multiplying two univariate polynomials over RR[x], Sage uses the naive
> O(n^2) algorithm. The docstring for _mul_ cites numerical stability as the
> reason to not use asymptotically faster algorithms:
>
> "Here we use the naive `O(n^2)`
When multiplying two univariate polynomials over RR[x], Sage uses the
naive O(n^2) algorithm. The docstring for _mul_ cites numerical
stability as the reason to not use asymptotically faster algorithms:
"Here we use the naive `O(n^2)` algorithm, as asymptotically faster
algorithms such as Kar
On Mon, 26 Apr 2010 18:02:40 -0700 (PDT)
kcrisman wrote:
> On Apr 26, 4:09 pm, John Cremona wrote:
> > This is certainly a bug:
> >
> > sage: a = sqrt(-3)
> > sage: a
> > sqrt(-3)
> > sage: a.conjugate()
> > sqrt(-3)
> >
> > sage: bool(a==a.conjugate())
> > True
> >
>
> Yeah, this is bad, and a
I'm used to the number-theoretic norm too, so I wasn't so worried
about it. I would point out that having "native" support of Gaussian
integers/primes would be very convenient for educational purposes (for
instance, a.is_prime() is not implemented for SR, but unfortunately
also not for these guys
On Mon, Apr 26, 2010 at 5:05 PM, Dima Pasechnik wrote:
> Hi William,
> I'll clean this up.
> When I was preparing it I was wondering whether that Windows stuff must be
> dropped, but as noone objected it remained there :)
Thanks Dima! You were right to wonder, and I was sloppy to not object.
-
On Mon, Apr 26, 2010 at 5:14 PM, kcrisman wrote:
>
>
> On Apr 26, 4:15 pm, William Stein wrote:
>> Hi,
>>
>> Main point of this email: if anybody else is trying to port Sage work
>> with GCC-4.5.0, we won't duplicate effort.)
>>
>> I'm working on trying to port Sage-4.4 to GCC-4.5.0. There are m
On Apr 26, 4:15 pm, William Stein wrote:
> Hi,
>
> Main point of this email: if anybody else is trying to port Sage work
> with GCC-4.5.0, we won't duplicate effort.)
>
> I'm working on trying to port Sage-4.4 to GCC-4.5.0. There are many
> issues on various OS's.
>
> * pynac (solved) --http:
On Mon, Apr 26, 2010 at 7:59 PM, Dima Pasechnik wrote:
> I work a lot with (large, say, 5000 vertices) (di)graphs having large
> automorphism groups (often vertex-transitive, etc).
> Such graphs are very efficiently represented in GAP (via GRAPE)
> package.
> (one needs to keep representatives of
Hi William,
I'll clean this up.
When I was preparing it I was wondering whether that Windows stuff must be
dropped, but as noone objected it remained there :)
Best,
Dima
On 27 April 2010 07:54, William Stein wrote:
> Hello,
>
> Including Windows binaries with Sage's source code distribution
> (s
On Mon, Apr 26, 2010 at 1:05 PM, Nathan O'Treally wrote:
> On 26 Apr., 19:23, Robert Bradshaw
> wrote:
>> On Apr 25, 2010, at 9:26 AM, Nathan O'Treally wrote:
>>
>> > On 25 Apr., 17:11, Gonzalo Tornaria wrote:
>> >> Also, the "== doesn't fail" part seems to force this, since it would
>> >> be ev
I work a lot with (large, say, 5000 vertices) (di)graphs having large
automorphism groups (often vertex-transitive, etc).
Such graphs are very efficiently represented in GAP (via GRAPE)
package.
(one needs to keep representatives of arc orbits, and few other
things, to be able to check adjacency of
Hello,
Including Windows binaries with Sage's source code distribution
(sage-x.y.z.tar) is bad, in my opinion, because binaries can hide
viruses, especially Microsoft Windows binaries. We are currently
shipping some, because of GAP.
This email concerns the gap-4.4.12.p1 spkg that is included in
On 04/25/2010 10:11 AM, Gonzalo Tornaria wrote:
With respect to NaN, it seems to me sage gets it wrong...
sage: 0.0/0.0 == 0.0/0.0
True
See http://trac.sagemath.org/sage_trac/ticket/8074 for a ticket
addressing this and other corner cases in RealField.
(the ticket needs a patch,
On 04/26/2010 02:48 PM, Gonzalo Tornaria wrote:
On Mon, Apr 26, 2010 at 4:26 PM, John Cremona wrote:
In number theory it is very useful to have this norm-alisation, as
well as the square root one also called abs. It's a special case of
the algebraic concept of norm(a) = product of conjugates o
> To follow up on myself one last time, here's what appears to be the
> minimal example exhibiting thisproblem
>
> def prob():
> for i in xrange(100):
> a = var('a')
> eqn = (a - 1)/(a)
> eqn.numerator()
I've gone ahead and filed this in Trac as
http://trac.sagemat
There is abs() function which behaves likes Norm of Mathematica. I
think that the function names of sage are more appropriate.
Rishi
On Apr 26, 3:26 pm, John Cremona wrote:
> In number theory it is very useful to have this norm-alisation, as
> well as the square root one also called abs. It's a
Hi,
Main point of this email: if anybody else is trying to port Sage work
with GCC-4.5.0, we won't duplicate effort.)
I'm working on trying to port Sage-4.4 to GCC-4.5.0. There are many
issues on various OS's.
* pynac (solved) -- http://trac.sagemath.org/sage_trac/ticket/8753
* libpng -- ht
This is certainly a bug:
sage: a = sqrt(-3)
sage: a
sqrt(-3)
sage: a.conjugate()
sqrt(-3)
sage: bool(a==a.conjugate())
True
But I have no idea where to look for it, since symbolic expressions
are a mystery to me!
John
On 26 April 2010 20:48, Gonzalo Tornaria wrote:
> On Mon, Apr 26, 2010 at 4
On 26 Apr., 19:23, Robert Bradshaw
wrote:
> On Apr 25, 2010, at 9:26 AM, Nathan O'Treally wrote:
>
> > On 25 Apr., 17:11, Gonzalo Tornaria wrote:
> >> Also, the "== doesn't fail" part seems to force this, since it would
> >> be even more awkward to hide the coercion failure.
>
> > See my last two
On Mon, Apr 26, 2010 at 4:26 PM, John Cremona wrote:
> In number theory it is very useful to have this norm-alisation, as
> well as the square root one also called abs. It's a special case of
> the algebraic concept of norm(a) = product of conjugates of a.
And the determinant of the action of a
In number theory it is very useful to have this norm-alisation, as
well as the square root one also called abs. It's a special case of
the algebraic concept of norm(a) = product of conjugates of a.
If this was really a problem to non-number-theorists, we could
possibly live with it (possibly by
Why does Sage say the norm of a complex number a+b*I is a^2+b^2?
sage: norm(1+2*I)
5
In MMA:
In[1]:= Norm[1+2*I]
Out[1]= Sqrt[5]
Wikipedia and mathworld both agree that the norm should be sqrt(5)
(i.e., the square root of the number times its conjugate).
Note that abs() seems right:
sag
One approach would be to store all the variables in a nested
dictionary, eg n[1, 2][2, 2], and use var('n_1_2_2_2',
latex_name='n_{(1,2),(2,2)}') to create the variables.
Here's an example:
nn = dict( [ ((i, j), {}) for i in [1..2] for j in [1..2] ] )
nn[(1, 1)] = dict( [ ((i, j),
var
On Mon, 26 Apr 2010 08:48:26 -0700 (PDT)
Ryan Hinton wrote:
> I'm using variable names with non-alphanumeric characters for
> convenience. (Longer story: I have variables with two vector
> subscripts.) Should the following be supported?
>
> sage: nn = var('n(0.1)(3.)')
The variable names shou
On Apr 25, 2010, at 9:26 AM, Nathan O'Treally wrote:
On 25 Apr., 17:11, Gonzalo Tornaria wrote:
Also, the "== doesn't fail" part seems to force this, since it would
be even more awkward to hide the coercion failure.
See my last two posts. In addition, Sage behaves different to Python
in many
On Apr 25, 2010, at 7:13 AM, Nathan O'Treally wrote:
On 25 Apr., 08:10, Robert Bradshaw
wrote:
On Apr 23, 2010, at 7:07 PM, Nathan O'Treally wrote:
Though e.g. C and C++ do have automatic (or implicit) conversion, it
is usually referred to as (different kinds of) type *casts*.
C++ does have a
On Apr 26, 9:48 am, Ryan Hinton wrote:
> sage: nn = var('n(0.1)(3.)')
>
> Creating expressions using ``nn`` seems to work fine -- as long as
> everything stays in Sage. But when I try to do some non-trivial
> equality comparisons, Sage punts the decision to Maxima, which chokes
> on the variable
Could not you use another way to use these subscripts. The following
may be ugly, but works
sage: n=var('n__0_3__0_1')
sage: maxima(n+1)
n__0_3__0_1+1
On 26 abr, 17:48, Ryan Hinton wrote:
> I'm using variable names with non-alphanumeric characters for
> convenience. (Longer story: I have varia
I think that this is a problem inherent to the way that sage
communicates to maxima. And would be difficult to correct unless every
symbolic variable/function has a different maxima, pari etc. name that
does not cause this problem.
For example I would not like the following to be supported
sage:
I'm using variable names with non-alphanumeric characters for
convenience. (Longer story: I have variables with two vector
subscripts.) Should the following be supported?
sage: nn = var('n(0.1)(3.)')
Creating expressions using ``nn`` seems to work fine -- as long as
everything stays in Sage. B
Hi,
I have upgraded source from 4.3.5 under Mac OS X 10.6.3 x86-64. And
output error message below
Summary:
ECL enabled. Executable name: "ecl"
default lisp: ecl
wish executable name: "wish"
Now building maxima; this takes a few minutes
Since we're using OS X and there is a very weird
bug with bu
On 25 April 2010 21:44, Mike Hansen wrote:
> On Sun, Apr 25, 2010 at 1:39 PM, Dr. David Kirkby
> wrote:
>> I can do the following in Mathematica.
>>
>> In[1]:= TrigReduce[ Sin[x] Cos[y]]
>>
>> Sin[x - y] + Sin[x + y]
>> Out[1]= ---
>> 2
>>
>> Is there
Hi William!
On Apr 26, 2:20 pm, William Stein wrote:
> Yes, you should definitely import from sage.all or sage.rings.all
> whenever possible, instead of directly from some module. The API of
> the "all.py" files are much more stable (especially the higher they
> are in the directory structure).
On Mon, Apr 26, 2010 at 1:08 AM, Sergey Bochkanov
wrote:
> Hello, Case.
>
> You wrote 23 апреля 2010 г., 19:30:20:
>
>> (1) Python numeric values are assumed to be immutable. If not, they
>> cannot be used as dictionary keys. This forces all results to be new
>> objects, hence source/destination o
I think the problem here is that David Roe's major rewrite of the
finite field code was (sensibly) split into several separate tickets,
of which the first 2 or 3 have been merged in 4.4, while the rest are
still awaiting review / work after review. And David tried hard to
make each ticket in the s
On Mon, Apr 26, 2010 at 5:10 AM, Simon King wrote:
> Hi David!
>
> On 26 Apr., 13:49, David Roe wrote:
>> Marshall's right that you need to change where the import comes from, but
>> you actually want
>> from sage.rings.finite_rings.constructor import FiniteField
>>
>> The class in sage.rings.fin
On 04/26/2010 06:49 AM, David Roe wrote:
Marshall's right that you need to change where the import comes from,
but you actually want
from sage.rings.finite_rings.constructor import FiniteField
Is this a compatibility issue that should have a deprecation period? I
wonder how many people it wi
Hi David!
On 26 Apr., 13:49, David Roe wrote:
> Marshall's right that you need to change where the import comes from, but
> you actually want
> from sage.rings.finite_rings.constructor import FiniteField
>
> The class in sage.rings.finite_rings.finite_field_base is the base class,
> whereas Finit
Marshall's right that you need to change where the import comes from, but
you actually want
from sage.rings.finite_rings.constructor import FiniteField
The class in sage.rings.finite_rings.finite_field_base is the base class,
whereas FiniteField in constructor is the UniqueFactory that makes finit
Hi Marshall!
On 26 Apr., 13:32, mhampton wrote:
> A number of tickets such as #8218 refactored quite a bit of finite
> field code. The FiniteField class you were using can be imported by:
>
> from sage.rings.finite_rings.finite_field_base import FiniteField
Thank you! And "from sage.all" works
A number of tickets such as #8218 refactored quite a bit of finite
field code. The FiniteField class you were using can be imported by:
from sage.rings.finite_rings.finite_field_base import FiniteField
-Marshall
On Apr 26, 6:08 am, Simon King wrote:
> Hi!
>
> I just upgraded to sage-4.4. I get
Hi!
I just upgraded to sage-4.4. I get:
sage: from sage.rings.finite_field import FiniteField
---
ImportError Traceback (most recent call
last)
/home/king/ in ()
/home/king/SAGE/sage-4.3.1/loca
Excellent Burcin - thanks!
Ill try your ideas below.
Ross
On Sat, Apr 24, 2010 at 7:42 PM, Burcin Erocal wrote:
> On Thu, 22 Apr 2010 20:52:53 -0700 (PDT)
> Ross Kyprianou wrote:
>
>> Addendum: I suppose a general query would be how do we incorporate new
>> knowledge into Sage (narrowing this do
51 matches
Mail list logo
