I was at a conference this weekend where someone presented a maple
package they had been writing for doing certain differential geometry
computations. His packages is mostly independent of anything maple
specific however it does use their PDE solver intensively. This PDE
Solver is a part of maple
On Sun, 29 Oct 2006 19:50:16 -0800, Nils Bruin <[EMAIL PROTECTED]> wrote:
>> One possibility, which I haven't quite thought through, is to allow the
>> user to get away with:
>>
>> R=PolynomialRing(ZZ)
>>
> In principle, the only reason why one *has* to give the indeterminates
> a name, is to make
> One possibility, which I haven't quite thought through, is to allow the
> user to get away with:
>
> R=PolynomialRing(ZZ)
>
In principle, the only reason why one *has* to give the indeterminates
a name, is to make sure that polynomials can print in a sensible way.
However, in the absence of vari
> I like using relative_precision and absolute_precision (following what
> I'm used to from MAGMA).Then there is no confusion.
Sounds good (though maybe precision_relative and precision_absolute in
order to make tab completion work?). I'll change the power series
functions to match.
> > 2.
On Oct 29, 2006, at 6:36 PM, William Stein wrote:
> additive_order, multiplicative_order, and is_zero all make perfect
> sense for p-adics, so i don't want to delete them.
I'm not sure I agree with this. When I ask for e.g. the
multiplicative order of an element of a p-adic field, the best an
On Sun, 29 Oct 2006 15:21:30 -0800, David Roe <[EMAIL PROTECTED]> wrote:
>
> Hey all,
> So, I'm making progress on p-adics and power series, though slowly. A
> couple of questions about unifying the terminology.
>
> 1. There are numerous possibilities for talking about the various
> types of pr
Hey all,
So, I'm making progress on p-adics and power series, though slowly. A
couple of questions about unifying the terminology.
1. There are numerous possibilities for talking about the various
types of precision (eg precision, relative precision, modulus,
big_oh...). There are two concepts
BTW, thanks to David Harvey for helping me track down a particularly
nasty bug in my code.
Bill.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more option
I have written an in place, recursive FFT/SS algorithm for multiplying
polynomials over ZZ, since it is more cache friendly than the iterative
algorithm in NTL.
On my machine, NTL takes 17.7 seconds to multiply 1000 pairs of
polynomials of degree 255 with coefficients of 1000 bits. The new
algori
On Sun, 29 Oct 2006 11:09:44 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> On Oct 29, 2006, at 12:01 PM, William Stein wrote:
>> After building, from the interpreter I did this:
>>
>> sage: import sage.modular.modsym.p1list as p
>> sage: p.test_foo(10)
>> 100
>
> Sweet. Well, maybe we should
On Oct 29, 2006, at 12:01 PM, William Stein wrote:
> After building, from the interpreter I did this:
>
> sage: import sage.modular.modsym.p1list as p
> sage: p.test_foo(10)
> 100
Sweet. Well, maybe we should be doing that in a few places then.
Seems very clean and natural.
David
--~--~---
On Sun, 29 Oct 2006 09:08:27 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> You CAN export module-level cdef functions from one pyrex module to
> another.
I didn't realize this...
> I added the following to arith.pyx:
>
> ==
> cdef public int my_function(int x):
>
On Sun, 29 Oct 2006 04:18:09 -0700, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> Incidentally, although SAGE might assign certain canonical isomorphisms
> and inclusions as canonical, the user should be able to reassign what
> the canonical homomorphism is for any ring.
I'm not convinced.
> This wo
On Sun, 29 Oct 2006 04:08:02 -0700, Bill Hart <[EMAIL PROTECTED]> wrote:
>
> Actually, I am wrong. It is no more difficult to decide whether the
> user should be allowed to coerce something from one ring into another
> than it is to have sage do it automatically. So the user should not
> have to
On Sun, 29 Oct 2006 03:53:15 -0700, Bill Hart <[EMAIL PROTECTED]> wrote:
> One possibility, which I haven't quite thought through, is to allow the
> user to get away with:
>
> R=PolynomialRing(ZZ)
>
> When asked what R is, SAGE will report that it is a univariate
> polynomial ring over ZZ.
>
> But
On Sun, 29 Oct 2006 03:10:55 -0700, Bill Hart <[EMAIL PROTECTED]> wrote:
> I believe that there is no reason to have a default indeterminate x
> defined when SAGE starts, any more. I know I was basically one of the
> people advocating this, but Bill Page's principle of least surprise has
> convinc
On Oct 29, 2006, at 6:08 AM, Bill Hart wrote:
> Maybe you guys have already had this discussion.
Indeed it is a never-ending discussion that comes up almost every
day. It's a very difficult problem. You can get some sense of how we
are thinking by looking at some other recent threads on
On 10/28/06, William Stein <[EMAIL PROTECTED]> wrote:
>
>
> >> 3. Does 0 coerce into any other finite field? In other words, does
> >> F2(0)+F1(0) make sense?
> >
> > Good question. I guess it wouldn't make any more or less sense than
> > any other elements of those fields.
>
> Yes, F2(0) + F1(0)
Perhaps I should use the word natural, not canonical.
Natural inclusions, natural homomorphisms to quotient rings and the
obvious map from one ring to another that is defined the same way would
all be automatically declared the distinguished map suitable for
automatic coersion.
--~--~-~
Incidentally, although SAGE might assign certain canonical isomorphisms
and inclusions as canonical, the user should be able to reassign what
the canonical homomorphism is for any ring. This would apply even if
the rings weren't isomorphic, or one included in another. The user
should be able to sp
Actually, I am wrong. It is no more difficult to decide whether the
user should be allowed to coerce something from one ring into another
than it is to have sage do it automatically. So the user should not
have to specify coersions all the time.
If SAGE were being really clever, the only rings it
One possibility, which I haven't quite thought through, is to allow the
user to get away with:
R=PolynomialRing(ZZ)
When asked what R is, SAGE will report that it is a univariate
polynomial ring over ZZ.
But if a user tries to use a function which displays indeterminates
from the ring R, then i
I believe that there is no reason to have a default indeterminate x
defined when SAGE starts, any more. I know I was basically one of the
people advocating this, but Bill Page's principle of least surprise has
convinced me that I'm wrong.
What I think *is* valuable, is being able to define:
x =
Works like a charm. Great!!!
Bill.
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-dev
24 matches
Mail list logo
