Peter,
> I think a case could be made for having two versions of the current RR: one
> like the current one (more like a model of the extended real line) and one
> where overflow or division by zero raises an exception instead of returning
> +/- infinity (more like a model of the usual r
On Monday, 7 October 2013 16:27:43 UTC-6, Volker Braun wrote:
>
> Have you tried to compile with "SAGE_INSTALL_GCC=yes make" to build our
> updated compiler? Looks like a gcc bug to me. Also, which OS, compiler
> version, bit width?
>
>>
>>
Same story after rebuilding with Sage gcc.
--
You re
On Monday, October 7, 2013 3:37:22 PM UTC-7, Peter Bruin wrote:
>
>
> I think a case could be made for having two versions of the current RR:
> one like the current one (more like a model of the extended real line) and
> one where overflow or division by zero raises an exception instead of
> r
Hi Marco,
I read that comment, but it looks like the coercion framework does what it
> should. RR(oo) == oo is evaluated by coercion to InfinityRing, where
> positive infinity equals positive infinity:
>
> sage: oo
> +Infinity
> sage: oo.parent() is InfinityRing
> True
> sage: InfinityRing.has_c
Hello,
> The implementation of RR and CC in Sage are a very direct wrapping of
> > MPFR, which is the most well-thought out efficient implementation of
> > floating point real numbers I've ever seen. It is worth visiting
> > http://www.mpfr.org/mpfr-current/mpfr.html and searching for
> > "in
On Monday, 7 October 2013 16:27:43 UTC-6, Volker Braun wrote:
>
> Have you tried to compile with "SAGE_INSTALL_GCC=yes make" to build our
> updated compiler? Looks like a gcc bug to me. Also, which OS, compiler
> version, bit width?
>>
>>
I didn't, with a hope that 4.7.2 is new enough. Also, I h
Have you tried to compile with "SAGE_INSTALL_GCC=yes make" to build our
updated compiler? Looks like a gcc bug to me. Also, which OS, compiler
version, bit width?
On Monday, October 7, 2013 10:57:33 PM UTC+1, Andrey Novoseltsev wrote:
>
> Hello,
>
> I am getting consistent failures from ecm i
Hello,
I am getting consistent failures from ecm interface, that looks like some
of the problems in an old thread:
https://groups.google.com/d/topic/sage-devel/ZLDecCbhOk8/discussion
I don't think I ever got no errors on this machine (started using it a
month or two ago): Opteron 6272 x2, Debia
On Mon, Oct 7, 2013 at 1:44 PM, Volker Braun wrote:
> Do you know where in the library the large cremona database is used?
> Grepping for cremona.db doesn't find anything.
>
It is at sage.databases.cremona, although everything in the library should
be already be up to date (e.g. the small cremon
Do you know where in the library the large cremona database is used?
Grepping for cremona.db doesn't find anything.
On Monday, October 7, 2013 9:00:05 PM UTC+1, John Cremona wrote:
>
> On 7 October 2013 13:58, Volker Braun >
> wrote:
> > Databases go to SAGE_LOCAL/share. Thats an easy change.
On Mon, Oct 7, 2013 at 12:43 PM, Marco Streng wrote:
>
>
>
> 2013/10/5 William Stein
>>
>> On Fri, Oct 4, 2013 at 1:56 PM, Greg Laun wrote:
>> > Thanks Peter. I agree that infinity in RR is a big problem. For those
>> > following the discussion, Peter updated Trac ticket #11506 to reflect
>> >
On Monday, October 7, 2013 11:35:47 AM UTC-7, Volker Braun wrote:
>
> I think you are missing the point that it is supposed to be a mixin class.
>
Ah, right. Perhaps it could be used like that, and it looks like it was
before pyrexification. Presently it's just not used at all, and its last
use w
On 7 October 2013 13:58, Volker Braun wrote:
> Databases go to SAGE_LOCAL/share. Thats an easy change.
I hope so. All that database_cremona_ellcurve does is to put one file
into the right place, which cannot be hard. Of course the library
code has to know where that palce is.
John
>
>
> On Mon
2013/10/5 William Stein
> On Fri, Oct 4, 2013 at 1:56 PM, Greg Laun wrote:
> > Thanks Peter. I agree that infinity in RR is a big problem. For those
> > following the discussion, Peter updated Trac ticket #11506 to reflect
> this
> > concern and it is now marked as a critical bug.
>
> I've add
I think you are missing the point that it is supposed to be a mixin class.
Of course that is not possible in matrices, which brings me to the second
point: The matrix classes are a completely atypical example in Sage.
Matrices are much more optimized than what would be appropriate in the rest
o
2013/10/7 Jori Mantysalo
> On Mon, 7 Oct 2013, John Cremona wrote:
>
> sage: R. = ZZ[]; print (4*x^2-1).factor()
>> --**--**
>> ---
>> NotImplementedError Traceback (most recent call
>> last)
>>
>
> But tha
On Monday, October 7, 2013 9:40:20 AM UTC-7, Volker Braun wrote:
>
> On Monday, October 7, 2013 5:05:52 PM UTC+1, Nils Bruin wrote:
>>
>> I think this holds uniformly, i.e., the class can go, being an
>> inappropriate abstraction. I think in all cases a simple boolean (both in
>> cython and in
On Monday, October 7, 2013 5:05:52 PM UTC+1, Nils Bruin wrote:
>
> I think this holds uniformly, i.e., the class can go, being an
> inappropriate abstraction. I think in all cases a simple boolean (both in
> cython and in python code) will do better.
>
I don't think the Python attribute is going
See:
http://trac.sagemath.org/ticket/13949
It's not just a technical issue: matrices used to have a 'mutability'
instance stored on an attribute, to encode a simple boolean. That increases
memory footprint and reduces performance significantly. Just storing the
boolean straight away should be
On Monday, October 7, 2013 4:14:23 PM UTC+1, Martin Albrecht wrote:
>
> This http://sagemath.github.io/git-developer-guide/index.html doesn't
> seem to
> discuss it?
>
http://trac.sagemath.org/ticket/14480
> For example, what's checksums.ini?
>
Auto-generated by sage-fix-pkg-checksums
sage.structure.mutability was added very recently, so there isn't anything
yet that uses it afaik. Feel free to be the first ;-)
On Monday, October 7, 2013 3:57:40 PM UTC+1, Daniel Krenn wrote:
>
> mutability.pyx:45 self._is_immutable = 1
> sequence.py: self._is_immutable = True
>
T
Where the new (PKG) directory layout documented, so that i can try to fix it?
This http://sagemath.github.io/git-developer-guide/index.html doesn't seem to
discuss it?
For example, what's checksums.ini?
On Monday 07 Oct 2013 05:58:51 Volker Braun wrote:
> Databases go to SAGE_LOCAL/share. Thats
There is sage.structure.mutability.Mutability to inherit from. It seems
the this class is not used; at least using grep [1] to search for
"Mutability" gives just two files (sage/matrix/matrix0.pyx and
sage/matrix/matrix_integer_2x2.pyx), where this class is imported. It
seems that commenting out th
On Monday, October 7, 2013 4:20:15 PM UTC+2, Ivan Andrus wrote:
>
> Valgrind complains about glibc being too recent. It should be updated
> from 3.7.0 to 3.8.1 anyway. This is
> http://trac.sagemath.org/ticket/13060which unfortunately has issues on OS X.
>
Indeed, on OSX, Valgrind build syste
Valgrind complains about glibc being too recent. It should be updated from
3.7.0 to 3.8.1 anyway. This is http://trac.sagemath.org/ticket/13060 which
unfortunately has issues on OS X. I suggest that we move forward with the spkg
at that ticket and worry about OS X later since otherwise it may
On Mon, 7 Oct 2013, Burcin Erocal wrote:
I got few floating point exceptions, but they seems to be already
reported: http://trac.sagemath.org/ticket/14658
However, I also found one new error:
Can you check if these problems are still there with the Singular spkg
posted on #14333?
I compile
Databases go to SAGE_LOCAL/share. Thats an easy change.
On Monday, October 7, 2013 1:48:52 PM UTC+1, Martin Albrecht wrote:
>
> It seems to me the database_* packages fail because there is no
> $SAGE_ROOT/data any more. Where should databases be installed to now?
>
>
> On 7 October 2013 12:52, V
Hi Jori,
On Mon, 7 Oct 2013 13:29:45 +0300 (EEST)
Jori Mantysalo wrote:
> I just make a small test:
>
> P.=QQ[]
> for i in range(1,10):
> p1=ZZ.random_element(1,5)*P.random_element()
> p2=ZZ.random_element(1,5)*P.random_element()
> p3=ZZ.random_element(1,5)*P.random_element()
It seems to me the database_* packages fail because there is no
$SAGE_ROOT/data any more. Where should databases be installed to now?
On 7 October 2013 12:52, Volker Braun wrote:
> We need to make sure that the optional spkg still work with the new git
> directory layout. I've tried to build al
We need to make sure that the optional spkg still work with the new git
directory layout. I've tried to build all optional spkgs and the following
ran into problems installing. Some failures may be trivial, but some spkgs
will need updating. If you care about one of these, please check the build
I also failed to install it in Sage. But on the other hand it was
trivial to install it with the package manager on Debian/Ubuntu (and
any Unix I guess)... does anyone know how far the GSoC project of
having the builtin Python instead of the one shipped with Sage has
gone ?
Vincent
2013/10/7, Jer
I just make a small test:
P.=QQ[]
for i in range(1,10):
p1=ZZ.random_element(1,5)*P.random_element()
p2=ZZ.random_element(1,5)*P.random_element()
p3=ZZ.random_element(1,5)*P.random_element()
p=p1*p2*p3
if p==0:
continue
print p
f=p.factor()
tulo=f.unit(
It seems that vtk has never truly been supported in Sage and the Sage
package has been abandoned for quite some time. So the "real" bug is the
fact that the package is still mentioned in the documentation.
See http://trac.sagemath.org/ticket/12652
--
You received this message because you are s
Harald,
I would be more than happy to participate in such a thing here in Wien!
Just let me know how can I help...
On 29 September 2013 16:41, Harald Schilly wrote:
> On Sun, Sep 29, 2013 at 1:44 PM, John Cremona
> wrote:
> > +Bristol perhaps. Yes, enough people. I'm not sure what such a gr
On Mon, 7 Oct 2013, John Cremona wrote:
sage: R. = ZZ[]; print (4*x^2-1).factor()
---
NotImplementedError Traceback (most recent call last)
But that is just what I would like to "implement", i.e. make
On 7 October 2013 08:15, Jori Mantysalo wrote:
> On Fri, 4 Oct 2013, Marco Streng wrote:
>
>> Just take the factorization over QQ, then for each factor, make it a
>> primitive integral polynomial, i.e., multiply by the lcm of the
>> denominators of the coefficients and divide by the gcd of the num
On Fri, 4 Oct 2013, Marco Streng wrote:
Just take the factorization over QQ, then for each factor, make it a
primitive integral polynomial, i.e., multiply by the lcm of the
denominators of the coefficients and divide by the gcd of the numerators of
the coefficients. Then you have a factorization
37 matches
Mail list logo
