ack, first first paragraph has the sentences out of order - an example
of giving a "useful result with an implicit assumption" is:
http://reference.wolfram.com/mathematica/tutorial/IndefiniteIntegrals.html
"Mathematica gives the standard result for this integral, implicitly
assuming that n is not
Thanks for the references -- it is very good that the gmp code is so
well documented with references to the literature.
It never ceases to amaze me how much improvement is possible on Euclid!
John
On 9/12/07, David Harvey <[EMAIL PROTECTED]> wrote:
>
>
> On Sep 12, 2007, at 5:48 PM, John Cremon
> > RingElement
> > -- QuotientRingElement_generic (*new*)
> > -- -- MPolynomialQuotientRingElement (*new*)
> > -- -- QuotientRingElement
> >
> > Thoughts?
>
> Looks good to me. Somehow I'm missing the point about why
> this wouldn't just be the obvious right thing to do. Maybe you
> could post
On Sep 12, 2007, at 9:52 PM, William Stein wrote:
> Personally, I think you're applying some of the very structured
> coercion
> model thinking in this situation, which is I think the wrong approach
> for symbol pushing and symbolic calculus.
I think you're right...
> Right now one gets the f
An implementation is up to test and play with at
http://www.sagemath.org:9002/sage_trac/ticket/624
On Sep 5, 2007, at 4:55 PM, Robert Bradshaw wrote:
> On Sep 5, 2007, at 4:48 PM, David Harvey wrote:
>
>> On Sep 5, 2007, at 7:37 PM, Robert Bradshaw wrote:
>>
But I'm a bit concerned wh
> "Mathematica gives the standard result for this integral, implicitly
> assuming that n is not equal to -1."
> Integrate[x^n, x]
>
> the result is x^(1+n)/(1+n)
>
> (this even happens when you give the option GenerateConditions->True)
>
> It would be much better to return the solution and its ass
Hi John,
Despite having looked into the problem of computing gcd's efficiently,
I don't know which algorithms are in practice faster for checking
squarefreeness. In fact, to date, I am unable to tell you which
algorithm is even asymptotically fastest for computing polynomial gcd.
For integer gcd
On 9/13/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>
> An implementation is up to test and play with at
>
> http://www.sagemath.org:9002/sage_trac/ticket/624
>
1. Could you post some (impressive) benchmarks?
2. Could you post a little example session that specifically
illustrates what's happ
On 9/13/07, Martin Albrecht <[EMAIL PROTECTED]> wrote:
>
> > > RingElement
> > > -- QuotientRingElement_generic (*new*)
> > > -- -- MPolynomialQuotientRingElement (*new*)
> > > -- -- QuotientRingElement
> > >
> > > Thoughts?
> >
> > Looks good to me. Somehow I'm missing the point about why
> > th
Hi,
Since nobody says they can't do Thursday, September 20th (one week
from today), let's have
***
SAGE BUG SQUASH DAY 3
http://wiki.sagemath.org/bug3
Thursday, September 20th
On Sep 13, 2007, at 11:11 AM, William Stein wrote:
>
> Hi,
>
> Since nobody says they can't do Thursday, September 20th (one week
> from today), let's have
>
> ***
> SAGE BUG SQUASH DAY 3
>
> http://wiki.sagemath.o
Hi,
I've posted the release candidate for sage-2.8.4.2 here:
http://sage.math.washington.edu/tmp/sage-2.8.4.2.rc1.tar
If it builds for people, etc., I will release sage-2.8.4.2 later today.
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
--~-
OK, I've looked into this more carefully and the reason why I don't
know which is the best algorithm for polynomial gcd over Z is that
most people when writing papers don't consider this case carefully
when they come to do asymptotic or runtime analysis. That is
presumably because it is hard to do
On Sep 13, 2007, at 7:11 AM, William Stein wrote:
> On 9/13/07, Robert Bradshaw <[EMAIL PROTECTED]> wrote:
>>
>> An implementation is up to test and play with at
>>
>> http://www.sagemath.org:9002/sage_trac/ticket/624
>>
>
> 1. Could you post some (impressive) benchmarks?
I've put some up on tra
Having said all that, Magma uses the GCDHEU algorithm and a modular
algorithm. Note that m in the above is the size in bits of the
coefficients of the resultant, which you don't know an a priori bound
for. You can figure out a bound however, but as in both algorithms,
you need to know the roots of
Hi,
I have released sage-2.4.8.2, which is a minor incremental release,
mainly "just because" releasing early and often is vastly easier than
releasing late and rarely:
SAGE-2.8.4.2 closes the following trac tickets:
262 Alex Ghitza: extend point counting on elliptic curves
to non
Hi Bill,
Thanks for your messages--it certainly is an interesting problem when
viewed in context.
For me, my polynomials are tiny: small degree (<=11) and very small
coefficients. Moreover, I already have computed the roots to some
numerical precision and only call this when there appears to be
Hi Will,
> > (2) I have my Cython code in a tr_data.spyx file and my Python code in
> > a totallyreal.py file. How do I include the former into the latter--
> > or do I have to include both at the prompt?
>
> You can't trivially get at tr_data.spyx from totallyreal.py, but you can
> from a .sage
Hi John,
Yes those are tiny polynomials. The way NTL works is to compute the
content of both polynomials and divide out by that, compute the gcd of
the contents, break up one prime at a time and compute the gcd mod p.
After each recombination (it's all done "in place") it checks to see
if the gcd
It takes Pari 2s to do a test of 10^5 polynomials of the form you
give, for irreducibility. It also takes it 2s to check if 10^5 pairs
give you isomorphic number fields. It takes 3s to compute all the
discriminants using nfdisc.
If it is taking 57s it's off its head. Coercion should be just about
On 9/13/07, John Voight <[EMAIL PROTECTED]> wrote:
>
> Hi Will,
>
> > > (2) I have my Cython code in a tr_data.spyx file and my Python code in
> > > a totallyreal.py file. How do I include the former into the latter--
> > > or do I have to include both at the prompt?
> >
> > You can't trivially g
21 matches
Mail list logo
