Dear Luis,
I think the points you raise are valid ones. Perhaps the following
would be a sensible solution?
Implement gcd and lcm for general field elements just as you suggest.
(So gcd(x,y) is 1 unless (x,y) is (0,0), in which case it is 0.) It
should be just fine for inexact fields, too, so
On Aug 27, 1:00 pm, luisfe lftab...@yahoo.es wrote:
I have added a new ticket for adding a default gcd and lcm for field
elements.
http://trac.sagemath.org/sage_trac/ticket/9819
For the case of field elements gcd and lcm methods are not of great
interest. However, they can be addecuated for
On 4 Aug, 15:05, Robert Miller r...@rlmiller.org wrote:
http://en.wikipedia.org/wiki/Dodgson_condensation
Chris Godsil pointed out to me yesterday that determinants over
generic rings uses expansion by minors, which is exponential. Much
better would be to use Charles Dodgson's method, which
On 2 Aug, 10:39, Michael Brickenstein brickenst...@mfo.de wrote:
str is very much immutable.
So you can't even set some custom attribute.
For that you have to sublass. Look what happens, when you subclass str
and get some mutable class
this way:
In [10]: class A(str):
: pass
Dear all,
A mere two years after ticket #4000 was opened on trac and a little
work during Sage Days 24 in Linz, there is now a set of patches (ready
for review!) attached to the ticket that provides an implementation of
QQ[] via FLINT 1.
This note's main purpose is to let everyone know about
Indeed. Unfortunately, the patch file is rather large, which makes it
difficult to have it tested and reviewed, and to keep it alive as
other Sage code changes. A while ago I spoke to Martin Albrecht about
this and we are both still interested in trying to push #4000 a little
harder again very
Dear Pierre,
I'm trying to find a workaround for my particular example, can someone
help ?
Would it be an option for you to apply the patch at
http://trac.sagemath.org/sage_trac/ticket/4000
? If I remember correctly, everything should be contained in the last
patch file on that ticket,
On Jan 29, 10:13 am, Bill Hart goodwillh...@googlemail.com wrote:
I wonder if it is possible to recreate the problem just using FLINT,
without any Sage, i.e. just write a short FLINT program which
replicates the problem.
I don't understand how the multiplication could take any serious
I think there might have been some progress:
sage: R.x = QQ[]
sage: f = 3/2*x - 1/3
sage: _ = f % f
Begin: fmpz_poly_pseudo_divrem(quo, r.num, m, a.num, b.num)
a.num = 9*t-2
fmpz_poly_length(a.num) = 2
fmpz_poly_max_limbs(a.num) = 1
b.num = 9*t-2
fmpz_poly_length(b.num) = 2
On Jan 29, 2:22 pm, Willem Jan Palenstijn w...@usecode.org wrote:
On Fri, Jan 29, 2010 at 05:58:39AM -0800, Sebastian Pancratz wrote:
The value of m is set by the call fmpz_poly_pseudo_divrem(quo, r.num,
m, a.num, b.num), where as the output above shows we have a.num and
b.num both equal
By the way, fmpz_poly_pseudo_rem should be faster if you don't require
the quotient.
Bill.
I originally wrote the Cython code against FLINT 1.4.0 and at the time
there was a bug in fmpz_poly_pseudo_mod, as a result of which I was
just using fmpz_poly_pseudo_divrem. I think Sage currently
Dear Bill,
Thank you for looking at this thread!
On Jan 29, 12:54 am, Bill Hart goodwillh...@googlemail.com wrote:
That certainly looks like an error message FLINT would output.
One possibility is that the problem occurs only on 32 bit machines or
only 64 bit machines and not the other kind.
On Jan 29, 12:54 am, Bill Hart goodwillh...@googlemail.com wrote:
One possibility is that the problem occurs only on 32 bit machines or
only 64 bit machines and not the other kind. Have you got access to
both 32 and 64 bit architectures to try this on?
Running the commands on a similar set up
Dear all,
In Sage 4.3, I came across the following problem when trying to coerce
rational numbers into the fraction field of Z[t].
sage: F = Frac(PolynomialRing(ZZ, 't'))
sage: F(1/2)
...
TypeError: no conversion of this rational to integer
I am guessing that this might be
Dear John,
I haven't written any of the code involved, so I am not absolutely
sure about this, but after looking at the code for a few minutes, I
think the following is the case:
The FractionFieldElement objects have a method factor, but this
takes no arguments other than self. This explains
in the
method factor for multivariate polynomials.
Sebastian
On Jan 7, 4:11 pm, Sebastian Pancratz s...@pancratz.org wrote:
Dear John,
I haven't written any of the code involved, so I am not absolutely
sure about this, but after looking at the code for a few minutes, I
think the following is the case
test this now and, if nothing fails, upload the
patch later today.
Sebastian
On Jan 7, 4:50 pm, John Cremona john.crem...@gmail.com wrote:
2010/1/7 Sebastian Pancratz s...@pancratz.org:
Further to my earlier post, a search for def factor(self, in the
Sage library reveals that there are a lot
Jason, you beat me to it. Thank you for letting me know, though!
Sebastian
On Jan 7, 5:01 pm, Jason Grout jason-s...@creativetrax.com wrote:
Sebastian Pancratz wrote:
Further to my earlier post, a search for def factor(self, in the
Sage library reveals that there are a lot of instances
this, that would be great.
Sebastian
On Jan 5, 12:57 pm, Burcin Erocal bur...@erocal.org wrote:
Hi Sebastian,
On Tue, 5 Jan 2010 04:10:08 -0800 (PST)
Sebastian Pancratz s...@pancratz.org wrote:
Dear all,
When looking at trac ticket #7730 (which essentially ends with saying
that GCD
Dear all,
When looking at trac ticket #7730 (which essentially ends with saying
that GCD computations over multivariate polynomial rings are slow), I
noticed that the current implementation of multiplication in fraction
fields computes the product (a/b) * (c/d) by first computing a*c and
b*d, and
Dear John,
At present we cannot rely on the input to + being reduced, since they
might have been created with reduce=False; in which case the value
returned by + (after using your idea) would not be reduced either --
is there any harm in that?
Well, as long as the behaviour is clearly
time to start
finish this.
Sebastian
On Jan 5, 12:57 pm, Burcin Erocal bur...@erocal.org wrote:
Hi Sebastian,
On Tue, 5 Jan 2010 04:10:08 -0800 (PST)
Sebastian Pancratz s...@pancratz.org wrote:
Dear all,
When looking at trac ticket #7730 (which essentially ends with saying
that GCD
Dear Martin,
Thank you for the details.
Sebastian
On Jan 5, 4:55 pm, Martin Rubey martin.ru...@math.uni-hannover.de
wrote:
Martin Rubey martin.ru...@math.uni-hannover.de writes:
Sebastian Pancratz s...@pancratz.org writes:
I am wondering whether there is a good reason for doing
Dear all,
Today I tried to build SAGE 4.2.1 from source and ran into what I
think is the same problem as described by John Cremona in his original
post. Namely, the build process failed when building R and the
complaint was `GCC_4.2.0' not found.
Just in case it helps, the computer used is a
The problem is here:
http://trac.sagemath.org/sage_trac/attachment/ticket/6441/trac_6441_b_df_charpoly_412rebase.patch
new lines 1084--1089
When I wrote the code for computing characteristic polynomials in a
division-free way in order for it to work over more general base
rings, it
Dear all,
Some might remember that in September I put a lot of effort into
rewriting Q[t] to use FLINT. While the patch (see trac #4000) was
very usable in practice already, despite the help of many people there
remained a few doctest failures throughout SAGE.
In short, while using SAGE with
(Manually terminated before completion)
57 (625 loops, best of 3: 570 µs per loop)
[/Performance comparison]
On Nov 15, 2:05 am, William Stein wst...@gmail.com wrote:
On Sat, Nov 14, 2009 at 5:59 PM, Sebastian Pancratz s...@pancratz.org wrote:
Dear all,
Some might remember that in September I
Dear William,
Thank your for the reply. I hadn't used PARI for this before, but
when I tried this right now I am getting very similar results.
About the strange CPU info, I actually cannot quite see where the
discrepancy is coming from. As perhaps you guessed from the format,
in each case I
Dear all,
Yesterday I ran into a problem when using the FLINT pseudo division
methods in SAGE. Below I am copying part of an email I sent to Bill
Hart already.
Sebastian
[Bug report]
While working on re-implementing QQ[] in SAGE, I came across the
following inconsistency. From the FLINT
Dear all,
The implementation of QQ[] using FLINT is making lots of progress and
it seems as if everything should be *much* faster than it is now.
At the moment, I've got two questions. First one is about the design
of the gcd method, and possibly affects other rings too. The second
method is
Dear all,
Here is the report of a bug report I came across when working on the
re-implementation of QQ[] via FLINT. I think it applies to many base
rings and appears on a rather high level, catching corner cases, but I
am not sure about this and haven't looked at it too closely.
sage: R.t =
Thank you for the reply. All methods in fmpq_poly_linkage.pxi are now
covered, and I've uploaded a new patch to trac ticket 4000. The
methods all just refer to the appropriate method in FLINT, except for
modular exponentiation. I am currently struggling to make SAGE use
this new implementation
Dear all,
I've finally started to work on this, and as already pointed out
earlier it's under trac ticket #4000. Martin Albrecht implemented a
prototype to help me get started and I've now looked at it in some
more details and implemented almost all the functionality, except for
the three
I think as a first step I'll only implement the additional argument
for the two methods is_field and is_integral_domain.
For the other suggestion, namely to allow the user to assert that a
ring is in fact a field, would the following be the right way to
implement this? 1. Add a new attribute to
In this file, the current behaviour is the following,
o Try to establish the answer (yes or no).
o If this doesn't work, throw an exception.
although the actual behaviour is down to the inheriting classes.
From the point of view of the ring, this might seem sensible. But I
I agree that consistent behaviour is good, but I don't see the point
of the proof=True option: Catching an error is not more difficult
than putting an extra argument proof=False.
I am not sure about this. In the current implementation, none of the
intermediate methods (e.g. for quotient
On my laptop with
OS: Windows 2000
CPU: Intel Pentium M 1500MHz
Compiler: GCC 3.4.2 (from an old-ish MinGW)
it compiles fine and produces the same output as on your Blade 2000.
Sebastian
On Jul 18, 4:09 pm, Dr. David Kirkby david.kir...@onetel.net
wrote:
I'd be interested what
Hi there,
After writing some SAGE code, profiling it and talking about it with
Martin Albrecht (more on that in another post a bit later), it turns
out that it spends a lot of time creating, adding and multiplying
univariate polynomials over the rationals. There is already a ticket
(#4000)
Hi all,
I have written some code which involves a lot of matrix operations,
where the base ring is a univariate polynomial ring over the
rationals. I think there are (at least) three ways to speed this up:
(1) Improve my code to perform fewer matrix operations, but I
guess that's something
39 matches
Mail list logo
