On Monday 16 November 2009 01:14:41 pm William Stein wrote:
Can you run make test on your 32 and 64 bit installs of sage-4.2.1
sometime, and report if they pass?I'm curious.
I do not know about 4.2.1, but I'm pretty certain all tests passed on most
versions of sage up till 4.1 on gentoo
On Wednesday 08 April 2009 06:08:50 am Joel B. Mohler wrote:
* n.exact_log can be done faster for small bases by making careful use
of the identity log_m(n) = log_2(n)/log_2(m) (I wrote a crappy broken
python implementation and timed this - I don't know how to write it
properly as I don't
On Wednesday 08 April 2009 02:17:48 am Bill Hart wrote:
* n.bits takes much longer than n.binary(), but the latter needs to
compute the former first!!!
This is sage types and lack of C-level optimization killing your performance.
The binary method does it's work using gmp (mpir, I guess
On Wednesday 01 April 2009 07:44:17 am John Cremona wrote:
I had already tried that variation. No luck!
mas...@host-56-150%echo $SAGE_PATH
/home/masgaj/sage
mas...@host-56-150%pwd
/home/masgaj/sage
mas...@host-56-150%sage -t /home/masgaj/sage/egros.py
sage -t /home/masgaj/sage/egros.py
On Friday 27 March 2009 02:37:44 pm Bill Hart wrote:
Could you be more specific about what you think these guys don't
understand?
Not to answer your question. I'm curious about William's reasoning as well.
However, I think they don't give a lot of evidence about why they believe
their
On Monday 16 March 2009 12:27:10 pm kcrisman wrote:
sage: integrate(y^2)
---
TypeError Traceback (most recent call
last)
TypeError: cannot coerce type 'type
On Monday 16 March 2009 02:51:30 pm Joel B. Mohler wrote:
On Monday 16 March 2009 12:27:10 pm kcrisman wrote:
sage: integrate(y^2)
-
-- TypeError Traceback (most recent call
last
On Saturday 14 March 2009 02:45:13 pm William Stein wrote:
William, shall we treat the case where the only variables in the
expression is x and y specially, and allow not specifying the variables
for the axis then? I think this makes the notation confusing and
inconsistent.
I have never
On Sunday 17 August 2008 01:05:53 pm John Cremona wrote:
I have needed the following. g(x) is a univariate polynomial which I
know to be a square, and i want its square root. g.factor() does too
much, as does g.squarefree_decomposition(). I can get the sqrt via
g.gcd(g.derivative()), which
On Monday 18 August 2008 11:44:11 am Bill Hart wrote:
Assuming FLINT is in fact being used for the GCD in Z[x], the
implementation is only fast up to degree about 250. It depends on
your definition of fast though. :-) In a later release of FLINT, GCD
will be asymptotically faster, and
On Monday 18 August 2008 12:06:06 pm Bill Hart wrote:
Doh, there's another simple way. Maybe Joel already does this. Simply
substitute a large prime or sufficiently high power of 2 and take the
square root of the resulting integer. Read off the square root of the
polynomial from the p-adic
On Tuesday 15 July 2008 06:57:57 pm Chris Swierczewski wrote:
My Question (Finally): How do I go about wrapping this C++ class with
this strange little define hanging around the class declaration?
Methinks I'm having compile issues precisely because of this addition.
I checked the Cython wiki
On Friday 27 June 2008 04:59:37 am Burcin Erocal wrote:
On Thu, 26 Jun 2008 12:40:34 -0700 (PDT)
Bjarke Hammersholt Roune [EMAIL PROTECTED] wrote:
This is definitely a bug since the docs explicitly say:
PolynomialRing(base_ring, name, sparse=False) returns a univariate
polynomial
Hi,
I cannot figure out how to force sage to construct a ring as a multivariate
ring with only a single generator. In the past, I used MPolynomialRing to
force multi-variate implementation, but that is now deprecated.
Specifically, the output below really bugs me. I had code relying on
This might be obvious to all involved, but working on
http://www.sagetrac.org/sage_trac/ticket/1293
might be a good idea in this regard. I'm pretty sure that I have only one
sage install and virtually nothing else and I'm on this list.
Now, I don't use my sage install on sage.math all that
On Friday 18 April 2008 03:08:58 pm mabshoff wrote:
This might be obvious to all involved, but working
onhttp://www.sagetrac.org/sage_trac/ticket/1293 might be a good idea in
this regard. I'm pretty sure that I have only one sage install and
virtually nothing else and I'm on this list.
On Friday 11 April 2008 05:39:03 pm Martin Albrecht wrote:
PS: In any case, If anyone wants to work on an optional GIAC spkg, please
speak up!
I tried to build GIAC and it didn't go so well. The seemingly obvious way to
have it pick up sage pre-installed components (--prefix=...) allowed
On Wednesday 09 April 2008 07:37:56 pm gerhard wrote:
* The actual bounds used for the axes
can yield very surprising results.
Should the range bounds be honored if
the user sets them explicitely?
Since we had a thread about this a bit ago and I was allegedly going to write
a
On Tuesday 08 April 2008 03:25:40 pm Mike Hansen wrote:
Today 03:25:40 pm
I have added a benchmark link with Fermat gcd tests, giac seems 5 to
10 * faster than maxima. I don't have magma, it is most probably
another factor of 10 * faster.
I think that comparison with Magma is a
On Thursday 03 April 2008 10:37, Alex Ghitza wrote:
Note that at the moment 0.digits() does (2) and 0.ndigits() does (1),
which is really bad.
Yes, this is very bad. I was not aware of the ndigits convention until after
the digits patch I wrote was included. On this topic, we also need a
On Thursday 03 April 2008 15:14, John Cremona wrote:
We have to regard 0 as a special case, I don't think there's any point
in pretending otherwise. If all leading zeros were stripped off in
all cases then the string representing 0 would be the empty string,
and obviously that would be
On Monday 31 March 2008 07:04:18 am Mike Hansen wrote:
Here are the timings I get by pretty much just copying balanced_list_prod.
About a month ago, I mailed sage-devel with a related issue:
sage: N=1000
sage: R.x,y=QQ[]
sage: L2=[x^i for i in range(N)]
sage: sum(L2)
...
The above sum behaves
On Monday 31 March 2008 07:38:48 pm William Stein wrote:
On Mon, Mar 31, 2008 at 4:27 PM, Mike Hansen [EMAIL PROTECTED] wrote:
Hi Roman,
It seems that for characteristic 0, Maxima is quite a bit faster than
Singular, but there's some overhead in talking to Maxima over the
pexpect
On Wednesday 26 March 2008 11:34, dean moore wrote:
At this link, http://sagemath.org/doc/html/prog/node1.htmlwe have,
Absolutely *everybody* who uses *Sage* should contribute something back
to *Sage* at some point.
I have had my fun with sage, and debated, How can I return something to
On Wednesday 26 March 2008 13:55, Jason Grout wrote:
Mercurial 1.0 is out now and one of the new standard extensions is the
churn command, which apparently gives the numbers of lines of changed
code per person (well, per email address). I thought the output (see
below) was interesting. This
On Wednesday 26 March 2008 15:16, Craig Citro wrote:
Did we check in a big chunk of the ntl wrapper under your name? (That
one would be fair, of course). Or maybe when we moved libcsage into
the sage tree, that went in under your name?
I suspect that both of these things are a big contributor
On Tuesday 04 March 2008 04:47:44 am Mike Hansen wrote:
Hello all,
Figleaf is a module for doing line coverage of Python code. I've made
an spkg at http://sage.math.washington.edu/figleaf-latest.spkg for
anyone who wants to try it out. It contains a script sage-figleaf
which I threw
Hi,
These methods set_si set_str violate immutability:
sage: n=300
sage: n.set_si(12)
sage: n
12
Shouldn't they be called _set_unsafe_xx? Better yet, shouldn't they be
deleted altogether since I can't find anywhere they are used in code aside
from doc-tests? Or, was that the point -- to
that.
--
Joel
On Mon, Mar 3, 2008 at 8:02 AM, Joel B. Mohler [EMAIL PROTECTED]
wrote:
Hi,
These methods set_si set_str violate immutability:
sage: n=300
sage: n.set_si(12)
sage: n
12
Shouldn't they be called _set_unsafe_xx? Better yet, shouldn't they be
deleted altogether since I
Integer ndigit method isn't so hot at the low end. Remarkably, the low end is
pretty high!
sage: n=2^500
sage: %timeit len(n.digits(10))
1 loops, best of 3: 61.6 µs per loop
sage: %timeit n.ndigits(10)
1 loops, best of 3: 98.4 µs per loop
sage: len(n.digits(10))==n.ndigits(10)
True
Hi,
Recently, I wanted to apply the digits method of an integer with a large base.
I ran into problems and entered:
http://trac.sagemath.org/sage_trac/ticket/2362
Now, I thought I'd sit down and fix the bug but there are two other bugs that
I'd like discussion on:
-coverage should be satisfied. We don't want to have to be reminded of
a missing doc-test if we've established that it is ok to be missing.
It's the same principle as not wanting compiler warnings.
--
Joel
- Robert
On Mar 1, 2008, at 6:02 PM, Joel B. Mohler wrote:
On Saturday 01 March 2008 04:51
Hi,
I just noticed that the timeit short-cut seems more broken than normal (at
least I think this worked previous to 2.10.2:
sage: R.x=ZZ[]
sage: f=x^2-1
sage: timeit f.factor()
File ipython console, line 1
timeit f.factor()
On Monday 25 February 2008 10:56, William Stein wrote:
On Mon, Feb 25, 2008 at 7:49 AM, Joel B. Mohler [EMAIL PROTECTED]
wrote:
Hi,
I just noticed that the timeit short-cut seems more broken than normal
(at least I think this worked previous to 2.10.2:
sage: R.x=ZZ[]
sage: f=x^2
On Thursday 21 February 2008 06:42:17 pm Ted Kosan wrote:
2) Would sage-devel be willing to expose a standard API that can be
used to access the Sage calculation engine?
It would be my opinion that this is already started actually:
sage: mathml(1)
mn1/mn
sage: mathml(pi)
mipi;/mi
sage:
Hi,
In 2.10.2.alpha0, there appears to be a small problem with the cython skipping
step. To illustrate the bug:
1) Start with a 2.10.2.alpha0 (with padic import patch) which is built
up-to-date
2) Add a new patch which adds a new .pyx file
3) sage -br
4) The bug is that you get a message
Hi,
I've finally got around to polishing off the implementation I made over
Christmas of multi-variate factoring over ZZ. For small cases singular
(working over QQ) beats it by a large factor, but for some larger cases they
become much more comparable. My favorite horrific example (in which
On Wed, Jan 30, 2008 at 10:13:09AM -0600, Jason Grout wrote:
Now, for the ncurses part. It seems like it would be very, very nice to
have a minimal admin menu using ncurses or newt (with the python snack
module) or dialog. Each of these has a python module, so hopefully it
should be
Hi,
A long time ago I noticed a comment in the prod function about doing a
divide-and-conquer product scheme so as to take advantage of asymptotically
fast
multiplication. Ironically, at the time I thought it was a pretty esoteric
idea
which would only be useful in bizarre cases. But,
Hi,
This question arises from the patch here
http://www.sagetrac.org/sage_trac/ticket/1413
but my question is rather tangential. The patch is for _sig_on/_sig_off added
to the mpoly libsingular code.
Micheal pointed out that a Ctrl+c signal to singular could produce some
corruption because
On Fri, Dec 21, 2007 at 01:51:37PM -0700, William Stein wrote:
* With a site license, accessing Mathematica functionality remotely is
permitted so long as the originating computer is eligible to have
Mathematica installed under the same site license.
That very surprising. This means
On Wednesday 19 December 2007 23:42, Bill Hart wrote:
Here is a graph that uses slightly bigger coefficients, up to 1
bits.
http://sage.math.washington.edu/home/wbhart/flint-trunk/graphing/factor2.pn
g
I don't see the speed increase you mentioned for large coefficients,
but this might
=ntl.ZZX([1234157])
sage: timeit s^300
1 loops, best of 3: 94.6 �s per loop
I don't know, that seems bizarre to me!
--
Joel
John
On 19/12/2007, Joel B. Mohler [EMAIL PROTECTED] wrote:
Ticket
http://trac.sagemath.org/sage_trac/ticket/1558
has some new code to use NTL to factor
http://www.sagetrac.org/sage_trac/ticket/1441
I agree that the observed symptom is not desirable, but I think that latex'ing
x1 as x_1 is more desirable than fixing the bug. Therefore, I offer my vote
that this bug is invalid.
--
Joel
--~--~-~--~~~---~--~~
To
http://www.sagetrac.org/sage_trac/ticket/1418
The optional doc-tests have me confused for this bug. The doc-tests in
sage/interfaces/magma.py don't fail on my PC but I don't have magma installed.
However, the patch there adds a doc-test section for __floordiv__ which fails
on
my PC. Why
Hi,
I don't think that the trac 1460 is really fixed. The bug just got moved
around.
http://trac.sagemath.org/sage_trac/ticket/1460
# sage 2.9
sage: t=var('t')
sage: f=t*sin(0)
sage: float(f(1))
# goes boom for a different reason than in 2.8.15
It seems the originally submitted patch by was
On Monday 17 December 2007 11:41, William Stein wrote:
This is *not* a bug. The is by design. Since f has no variables it
is no longer
implicitly callable:
Sorry for the double reply. Perhaps I should be very explicit about why I
think the current state is very error-prone (and hence,
On Wednesday 12 December 2007 18:24, William Stein wrote:
Anyway, Yi just made this planet sage blog thing:
http://sage.math.washington.edu/home/yqiang/psage/output/
So I looked at it, and saw Martin Albrecht's blog posts, which I
hadn't looked at before. Those led me to the Giac site,
Hi,
I've noticed a very recent regression -- it worked 2 months ago.
sage: t=var('t')
sage: f=t*cos(0)
sage: float(f(1))
1.0
sage: f=t*sin(0)
sage: float(f(1))
Traceback...
type 'exceptions.TypeError': float() argument must be a string or a number
--
Joel
On Tue, Dec 11, 2007 at 07:28:24PM +0100, Ondrej Certik wrote:
Hi,
there is an inconsistency problem with subs:
sage: e = x**2 + 1
sage: e
x^2 + 1
sage: e.subs(x= x**2)
x^4 + 1
sage: e.subs(x**2= x)
File ipython
Hi,
Here's a couple of questions that have occurred to me as I tried to make
fraction fields of mpolynomials tolerable to work with.
1) In the reduce method in the file fraction_field_element.py (line 72), we
call quo_rem to divide the gcd out of the numerator and denominator. Now, by
Hi,
I decided to try out Macaulay2 for some of the things that I've been
struggling with through singular. Unfortunately, the spkg install fails for
me with details in the P.S. The crucial bit seems to be
***
/bin/sh: etags: command not found
***
A little bit of google rewards me with the
I think this would be great. Do recursive dependencies get caught now? They
didn't 6 months ago. For example, if I have a .pxd included (cimported,
whatever) in another .pxd which is included in a .pyx: i.e.
a.pxd - b.pxd - c.pxd - c.pyx
then modifications of a.pxd should trigger c.pyx to
On Thu, Dec 06, 2007 at 04:47:25AM -0800, mabshoff wrote:
Chances are it won't work anyway. You should go over to the google
group Macaulay2 and read the top topic. Get somebody over there to fix
the issue of library detection and I will create a M2 spkg from latest
svn. Working on the old
Hi (I'm sending this to sage-devel as well -- there's a bunch of interest there
to get our multivariate stuff up to speed),
I've put some examples of things that are slow up at
http://sage.math.washington.edu/home/jbmohler/singular/
These are things that I ran into just this morning in my
On Tuesday 04 December 2007 02:31, William Stein wrote:
I think we discussed this on the list before. For univariate you want
van hoeij's algorithm and for multivariate some variant of GCDHEU or
EZGCD.
I think the algorithm Singular are using, EZGCD, is probably pretty
good. They just
Hi,
I've been researching this slow mpolynomial factorization a bit more and
haven't come up with any good news. Hans (from singular) replied to my forum
post at
http://singular.mathematik.uni-kl.de/forum/viewtopic.php?t=1652
It seems as though singular's random choices of evaluation points
On Mon, Dec 03, 2007 at 09:19:38AM -0800, mabshoff wrote:
On Dec 3, 6:15 pm, William Stein [EMAIL PROTECTED] wrote:
On Dec 3, 2007 8:56 AM, mabshoff
[EMAIL PROTECTED] wrote:
Cpu time = 0.80, User time = 1
This is not so good, really.
I know, but it seems to beat every open source
I've observed that variable substitutions in fraction fields of mpolynomial
rings can be very slow. I believe this is because of the many gcd computations
which occur in intermediate steps of the substitution. In my special case I'm
doing substitutions of monomials and fractions of
On Monday 26 November 2007 07:34, Ondrej Certik wrote:
David Roe:
I would prefer that direction too. In order to make that happen, the
SymPy __add__ function has to recognize a sage element and call its
__add__ method instead. This sounds like it should be doable.
I am not sure it's a
On Mon, Nov 26, 2007 at 02:31:31PM +0100, Ondrej Certik wrote:
(In reality, I think that sympy and sage should simply merge. However, I
don't know enough about sympy to know how feasible that is. I put this in
parenthesis, because I fear it's kind of a demeaning thing to say. I don't
On Friday 23 November 2007 22:46, mabshoff wrote:
Bill has fixed a couple of bugs in flint since r1072 that were corner
cases that only happened on Core Duos, so I have updated the spkg to
r1075. It is available at
http://sage.math.washington.edu/home/mabshoff/flint-0.9-r1075.spkg
On a
Hi,
I've been noticing that singular's factoring is grotesquely slow at times.
What's really strange is that the speed fluctuates wildly. I've observed this
speed fluctuation other places in singular as well. I found
http://www.sagetrac.org/sage_trac/ticket/872
and thought it might be
On Fri, Nov 23, 2007 at 07:08:02AM -0800, mabshoff wrote:
Hello Joel,
I'm also posting this
athttp://www.singular.uni-kl.de/forum/viewforum.php?f=10
as soon as I get registered on the forum.
You don't need to be registered at the Singular forum in order to be
able to post. The
On Friday 23 November 2007 16:57, William Stein wrote:
Singular errors or not, Singular is really pitiful at this problem
compared to Magma -- which is what we should have as a baseline
for solid robust behavior in this case:
In SAGE (via libsingular) on a 2.33Ghz laptop:
sage:
On Tue, Nov 13, 2007 at 01:01:47AM +, Robert Bradshaw wrote:
This is the issue, which is also the issue with the __richcmp__
(you'll need to remove that and __cmp__ to get __hash__ to work).
http://webmaster.iu.edu/tool_guide_info/python/api/type-structs.html
This field is
On Thursday 08 November 2007 02:43, Martin Albrecht wrote:
Hashing string is definitely one of the easiest ways to get a lot of
semantics that we want ... i.e. agreement with '=='. In all other
respects, it seems like one of the most awful hash algorithms one could
imagine. However, I'm
On Wednesday 07 November 2007 10:42, Martin Albrecht wrote:
Sorry to reply to myself when I should have done my research beforehand.
The issue is that multivariate polynomials over ZZ override hash and hash
the tuple of tuples of exponents (roughly speaking). This is in stark
contrast to
Hi,
I'd like some confirmation for the patch at
http://www.sagetrac.org/sage_trac/ticket/1075
The purpose of the patch is to fix the lack of substitution in the following
code snippet (it also has other ramifications in similar contexts):
sage: R.x,y=ZZ[]
sage: (x/y).subs({x:1})
x/y
The patch
On Wednesday 07 November 2007 08:33, Joel B. Mohler wrote:
I'd like some confirmation for the patch at
http://www.sagetrac.org/sage_trac/ticket/1075
The purpose of the patch is to fix the lack of substitution in the
following code snippet (it also has other ramifications in similar
contexts
I was trawling through old tickets and came across this
http://sagetrac.org/sage_trac/ticket/598
which I was responsible for getting entered (I guess). I subsequently fixed
some of it, but not all of it and didn't realize the ticket was there.
Here is current 2.8.11 operation:
sage: M.x,y =
On Fri, Nov 02, 2007 at 07:45:34AM -0700, mabshoff wrote:
mabshoff: Are you sure you ran doc-tests with the *patched* version of
sage?
Because that doc-test wasn't even in the vanilla version.
Everything is possible, but I am fairly sure that the behavior of the
doctests only
On Friday 02 November 2007 10:45, mabshoff wrote:
On Nov 2, 12:45 pm, Joel B. Mohler [EMAIL PROTECTED] wrote:
Everything is possible, but I am fairly sure that the behavior of the
doctests only changes if the patch made it in. Can you check that your
patch applied against rc1 passes doctests
On Friday 02 November 2007 15:38, mabshoff wrote:
The patch applied against rc1 passes with flying colors. You need to use
the second bundle on the ticket since the first bundle is already in (but
backed out). Maybe there is a correct way to back out the back out, but
I don't know it.
On Mon, Oct 29, 2007 at 02:00:18PM -0700, William Stein wrote:
On 10/29/07, Joel B. Mohler [EMAIL PROTECTED] wrote:
sage: P.alpha_15=ZZ[[]]
sage: latex(P)
\mathbf{Z}[[\alpha_{15}]]
sage: P,alpha_beta12=PolynomialRing(ZZ,'alpha_beta12').objgen()
sage: latex(alpha_beta12)
\alpha_
On Tue, Oct 30, 2007 at 10:48:47AM -0700, William Stein wrote:
Anyhow, I guess my rock bottom question is whether this design restraint
could
be reconsidered? I'd be much happier to see some concrete systems that it
breaks that we need (and mathematica doesn't count in my mind since it
Hi,
I feel like this is a really dumb question, but how do you create a polynomial
ring with elements that don't commute? I expected MPolynomialRing to have a
parameter 'commutative', but I can't find any evidence of it.
So, as an alternative I tried a FreeAlgebra and it appears promising.
Oops, forget the patch! Now it is attached.
On Thu, Oct 18, 2007 at 04:09:04PM -0400, Joel B. Mohler wrote:
A couple of days ago I wrote to sage-support complaining about margins on
plots
-- I think they are too big. Ironically, it seems that vanilla matplotlib is
even worse
A couple of days ago I wrote to sage-support complaining about margins on plots
-- I think they are too big. Ironically, it seems that vanilla matplotlib is
even worse for this in some respects, but sage does a couple of funny things
that I'd like a plotting guru to look at. It seems there
On Thursday 18 October 2007 17:00, alex clemesha wrote:
A couple of days ago I wrote to sage-support complaining about margins on
plots
-- I think they are too big. Ironically, it seems that vanilla
matplotlib is
even worse for this in some respects, but sage does a couple of funny
Thanks for the discussion about this topic. I send this mail to re-iterate
and summarize. It seems there are two things that you might want:
1) Get the coefficient of a specific monomial in the multivariate polynomial
ring.
2) Get the coefficient of the polynomial in a tower of (two)
On Friday 12 October 2007 11:41, didier deshommes wrote:
But:
coeff(f,y,0);
x + 1
returns the right answer
Actually I like Maple's notation better here over the dictionary
notation you proposed: it is as intuitive and I have to type less
On Friday 12 October 2007 13:36, Mike Hansen wrote:
If you're doing a dictionary anyway, doesn't it make more sense to use
**kwargs? For example,
sage: P.x,y=ZZ[]
sage: f=x*y^2+x*y+y+x+1
sage: f.coefficient(y=2)
x
sage: f.coefficient(y=1)
x + 1
sage: f.coefficient(x=1, y=2)
1
It
This e-mail is too long. Here's the bottom line: I suggest that the
coefficient method on a multivariate polynomial ring take a dictionary
indicating the variables and degrees that you want to restrict your attention
to.
It seems that the multivariate polynomial coefficient function is a
I find the two following results contradictory:
sage: FractionField(ZZ) is QQ
True
sage: is_FractionField(QQ)
False
Is that a bug?
--
Joel
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group,
On Friday 12 October 2007 11:25, William Stein wrote:
sage: FractionField(ZZ) is QQ
True
sage: is_FractionField(QQ)
False
No. all of the many dozens of is_* methods do *type* checking.
They are not checking some abstract mathematical properties.
There is a specific data type in Sage
On Friday 12 October 2007 15:52, Nils Bruin wrote:
Both the poly.coefficients({x:1,y:2}) and poly.coefficients(x=1,y=2)
seem confusing to me (the latter one downright scary. Exponents and
variable names have no business being on opposite sides of an equality
sign).
Yes, I agree,
was actually).
http://trac.sagemath.org/sage_trac/ticket/822
--
Joel
On Wednesday 03 October 2007 21:52, Joel B. Mohler wrote:
Hi,
It would have been nice to sit down in person with Robert and/or William
about this at Clay, but I only fully realized the extent of my questions
about 1.5 hours before
On Thursday 04 October 2007 15:38, Robert Bradshaw wrote:
Craig's reply is a good summary of what I was going to say. I'm
getting an
abort: unknown parent e91367eb18c1!
Well, it looks like William succeeded in looking at it as the patch is
changed.
Craig mentioned the call to MatrixSpace
Hi,
It would have been nice to sit down in person with Robert and/or William about
this at Clay, but I only fully realized the extent of my questions about 1.5
hours before I wanted to leave :). Anyhow, the matrix multiplication process
is looking a bit inefficient to me.
Here's the
On Sunday 23 September 2007 15:46, William Stein wrote:
However, in the COPYING file for Sage itself, I wrote: All original
SAGE code is distributed under the terms of the GNU General Public
License *Version 2*.
Just out of curiosity, would anybody be angry if I were to remove the
words
On Sunday 23 September 2007 20:26, David Joyner wrote:
On 9/23/07, Joel B. Mohler [EMAIL PROTECTED] wrote:
Well, I wouldn't say I'd be angry, but I dislike the GPLv3. My
principle reason for disliking it is section 3. I didn't read up on
acticle 11 of WIPO, but my understanding
Hi,
I'm working on some computations with multi-variable polynomials over QQ. I'm
finding some very weird performance characteristics. For instance, I have
two polynomials which I want to divide one by the other and have an element
of the fraction field. This requires computing a gcd
Dear Hans and sage-devel readers,
As I wrote on sage-devel a bit earlier, I had some polynomials that were
causing singular gcd to slow down dramatically. I had thought this was
inconsistent, but upon more investigation it seems very consistent (on two
different computers).
Here's some
On Wednesday 19 September 2007 15:55, William Stein wrote:
Just for clarity, why not just compute the GCD with mathematica?
Well, I am doing that. I assumed that I had found a slow corner case that
singular folks would want to fix. I'm not entirely sure that this point how
small that corner
On Wednesday 19 September 2007 16:22, William Stein wrote:
I think those timings are way out of date, since Singular 3 seems
to be *very* fast at mod p multivariate GCD computation, even
though it sucks over QQ. Check out this paper:
http://www.cecm.sfu.ca/CAG/papers/brown.ps
On Tuesday 18 September 2007 14:34, Robert Bradshaw wrote:
I still like the [a..b] notation that makes
things totally obvious, and I am as surprised as Peter Doyle at the
shift of topic of whether or not indices should be 0-based (which we
don't have a choice about while sticking with
On Saturday 15 September 2007 10:47, Bill Hart wrote:
OK, here is an important question. The only way SAGE has of moving
polynomials between Maxima, NTL, Pari, Magma, SINGULAR, etc, at
present, is via text strings, yes?
Increasingly that is not true and it should be less true than it is. The
On Friday 14 September 2007 15:31, Robert Bradshaw wrote:
Currently, ZZ[x] - QQ[x] does
ntl_ZZ - str - list - list of rationals - str - pari
Perhaps QQ[x] should be implemented as ZZ[x] + denominator?
Well, this will probably be more efficient with-in the week.
More generally, I think the
Hi,
Consider the following:
sage: x,y=ZZ['x,y'].gens()
sage: f=(x+1)*(y+1)*(1-x*y)
sage: f.factor()
...
type 'exceptions.TypeError': no conversion to a Singular ring defined
It certainly seems to me that this should coerce just fine to a Singular ring.
Is this a bug?
--
Joel
1 - 100 of 180 matches
Mail list logo
