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 l
On Aug 27, 1:00 pm, luisfe 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 some reaso
On 4 Aug, 15:05, Robert Miller 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 is cubic,
> de
On 2 Aug, 10:39, Michael Brickenstein 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
>
> In [11]: a
On 2 Aug, 09:57, Michael Brickenstein wrote:
> I just tried it and the standard library functions also use that
> "optimization".
>
> In [1]: from copy import copy
>
> In [2]: l="slkl"
>
> In [3]: copy(l) is l
> Out[3]: True
>
> Cheers,
> Michael
Perhaps my knowledge of Python isn't strong enough
Dear all,
As I'm sure most people here know, polynomials in Sage are kind of
immutable - they are meant to be immutable and (most) methods are
allowed to assume this to improve their performance, but sometimes
there an interface is (see _unsafe_mutate) to modify a polynomial
nonetheless.
I've rec
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 this
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,
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 so
> 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
On Jan 29, 2:22 pm, Willem Jan Palenstijn 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
I think there might have been some progress:
sage: R. = 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
fmpz_poly_m
On Jan 29, 10:13 am, Bill Hart 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
> quantity of time unless the
On Jan 29, 12:54 am, Bill Hart 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 (Sage 4.3.1.rc0, with the
Dear Bill,
Thank you for looking at this thread!
On Jan 29, 12:54 am, Bill Hart 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. Have you got access to
Dear all,
I am writing to ask for help with analysing a very strange problem
that came up a few days ago on trac ticket #4000.
After reviving the work from last September/ October with some
significant help of Mike Hansen at Sage Days 19 a week ago, we finally
had a version of the patch that appl
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 simila
Jason, you beat me to it. Thank you for letting me know, though!
Sebastian
On Jan 7, 5:01 pm, Jason Grout 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 instance
I'll test this now and, if nothing fails, upload the
patch later today.
Sebastian
On Jan 7, 4:50 pm, John Cremona wrote:
> 2010/1/7 Sebastian Pancratz :
>
>
>
> > Further to my earlier post, a search for "def factor(self," in the
> > Sage library reveals
uld be documented in the
method "factor" for multivariate polynomials.
Sebastian
On Jan 7, 4:11 pm, Sebastian Pancratz 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 f
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 explai
this, that would be great.
Sebastian
On Jan 5, 12:57 pm, Burcin Erocal wrote:
> Hi Sebastian,
>
> On Tue, 5 Jan 2010 04:10:08 -0800 (PST)
>
> Sebastian Pancratz wrote:
> > Dear all,
>
> > When looking at trac ticket #7730 (which essentially ends with sa
Dear Martin,
Thank you for the details.
Sebastian
On Jan 5, 4:55 pm, Martin Rubey
wrote:
> Martin Rubey writes:
> > Sebastian Pancratz writes:
>
> >> I am wondering whether there is a good reason for doing this.
>
> >> Typically, assuming that (or even on
ave enough time to start
& finish this.
Sebastian
On Jan 5, 12:57 pm, Burcin Erocal wrote:
> Hi Sebastian,
>
> On Tue, 5 Jan 2010 04:10:08 -0800 (PST)
>
> Sebastian Pancratz wrote:
> > Dear all,
>
> > When looking at trac ticket #7730 (which essentially end
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 do
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 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 l
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 turne
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 ha
.4 (625 loops, best of 3: 364 µs per loop)
MUL
35.79
285.680
NA (Manually terminated before completion)
57 (625 loops, best of 3: 570 µs per loop)
[/Performance comparison]
On Nov 15, 2:05 am, William Stein wrote:
> On Sat, Nov 14, 2009 at 5:59 PM, Sebastian Pancratz wrote:
>
> > De
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 my
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 1.4.0
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 p
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. = RR[]
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 method
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 attribu
> 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 quotien
> > 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.
Dear all,
At SAGE Days 16 I implemented some code for division-free matrix
operations, which is being tracked as ticket #6441. The main
contribution is code to compute the characteristic polynomial without
divisions, and this leads to code to compute the characteristic
polynomial, the adjoint ma
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"
wrote:
> I'd be interested what you get if you build th
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
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)
h
43 matches
Mail list logo
