On Fri, 3 Nov 2006, William Stein wrote:
>
> On Fri, 03 Nov 2006 09:54:14 -0800, Robert Bradshaw
> <[EMAIL PROTECTED]> wrote:
>> I think the problem here is that it _assumes_ that x and y commute,
>> which is not the only option.
>>
>> I am still looking for a convincing reason that
>>
>> sa
On Fri, 03 Nov 2006 09:54:14 -0800, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
> I think the problem here is that it _assumes_ that x and y commute,
> which is not the only option.
>
> I am still looking for a convincing reason that
>
> sage: (1/2) * Matrix(ZZ, 2, 2, [1,2,3,4])
>
> should n
On Nov 3, 2006, at 8:39 AM, Bill Page wrote:
> On November 3, 2006 9:48 AM David Harvey wrote:
>>
>> On Nov 3, 2006, at 9:37 AM, Bill Page wrote:
>>
>>>
>>> Maybe it is interesting to consider how Axiom handles these
>>> coercions? For example:
>>>
>>> sage: x = axiom('x::MPOLY([x],INT)')
>>> sag
On November 3, 2006 9:48 AM David Harvey wrote:
>
> On Nov 3, 2006, at 9:37 AM, Bill Page wrote:
>
> >
> > Maybe it is interesting to consider how Axiom handles these
> > coercions? For example:
> >
> > sage: x = axiom('x::MPOLY([x],INT)')
> > sage: x.type()
> > MultivariatePolynomial([x],Intege
On Fri, 03 Nov 2006 06:37:28 -0800, Bill Page
<[EMAIL PROTECTED]> wrote:
> On November 2, 2006 11:47 PM Robert Bradshaw wrote:
>> On Nov 2, 2006, at 8:28 PM, David Harvey wrote:
>> > On Nov 2, 2006, at 11:11 PM, Robert Bradshaw wrote:
> sage: x = axiom('x::MPOLY([x],INT)')
> sage: x.type()
> Mul
On Nov 3, 2006, at 9:37 AM, Bill Page wrote:
>
> Maybe it is interesting to consider how Axiom handles these
> coercions? For example:
>
> sage: x = axiom('x::MPOLY([x],INT)')
> sage: x.type()
> MultivariatePolynomial([x],Integer)
> sage: y = axiom('y::MPOLY([y],INT)')
> sage: y.type()
> Multiva
On November 2, 2006 11:47 PM Robert Bradshaw wrote:
>
> On Nov 2, 2006, at 8:28 PM, David Harvey wrote:
>
> > On Nov 2, 2006, at 11:11 PM, Robert Bradshaw wrote:
> >
> >>> This is much harder. I agree it would be nice, but how would you
> >>> handle something like
> >>>
> >>> sage: R. = ZZ["x"]
On Nov 2, 2006, at 8:54 PM, William Stein wrote:
> On Thu, 02 Nov 2006 20:06:34 -0800, David Harvey
> <[EMAIL PROTECTED]> wrote:
>> This is much harder. I agree it would be nice, but how would you
>> handle something like
>>
>> sage: R. = ZZ["x"]
>> sage: S. = ZZ["y"]
>> sage: x*y
>
> The result
On Thu, 02 Nov 2006 20:06:34 -0800, David Harvey
<[EMAIL PROTECTED]> wrote:
> This is much harder. I agree it would be nice, but how would you
> handle something like
>
> sage: R. = ZZ["x"]
> sage: S. = ZZ["y"]
> sage: x*y
The result would be in either ZZ['x,y'] or ZZ['y,x'], or even jn the
non
On Nov 2, 2006, at 8:28 PM, David Harvey wrote:
> On Nov 2, 2006, at 11:11 PM, Robert Bradshaw wrote:
>
>>> This is much harder. I agree it would be nice, but how would you
>>> handle something like
>>>
>>> sage: R. = ZZ["x"]
>>> sage: S. = ZZ["y"]
>>> sage: x*y
>>>
>>> ??
>>>
>>> David
>>
>> Now
On Nov 2, 2006, at 11:11 PM, Robert Bradshaw wrote:
>> This is much harder. I agree it would be nice, but how would you
>> handle something like
>>
>> sage: R. = ZZ["x"]
>> sage: S. = ZZ["y"]
>> sage: x*y
>>
>> ??
>>
>> David
>
> Now you could return that as an element of ZZ['x', 'y'], but I'm n
On Nov 2, 2006, at 8:06 PM, David Harvey wrote:
> On Nov 2, 2006, at 11:02 PM, Robert Bradshaw wrote:
>
>> I think if there is a natural coercion S -> R, one should also be
>> able to do
>>
>> x * y = x * y.base_extend(R)
>>
>> Right now something like
>>
>> sage: R. = ZZ['x']
>> sage: (1/2
On Nov 2, 2006, at 11:02 PM, Robert Bradshaw wrote:
> I think if there is a natural coercion S -> R, one should also be
> able to do
>
> x * y = x * y.base_extend(R)
>
> Right now something like
>
> sage: R. = ZZ['x']
> sage: (1/2) * (x^2-x)
>
> throws an "unable to find a common parent" t
I feel like I'm jumping into this discussion late, but it's something
I've been thinking about too...
On Oct 28, 2006, at 7:05 PM, William Stein wrote:
> Regarding ring and algebra elements, suppose x is in a ring R and y
> is in a K-algebra S.We want to define what "x * y" means. The
> m
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)
On Sat, 28 Oct 2006 21:16:13 -0700, David Joyner <[EMAIL PROTECTED]>
wrote:
>> I think they both make sense.
>>
>> For (x1+x2), it would coerce x1 into F2 and add in F2. Then for x2+(x1
>> +x2) it would add in F2.
>>
>> For (x2+x1) it would coerce x1 into F2 and add in F2. Then for (x2+x1)
>> +x
On Sat, 28 Oct 2006 19:36:13 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> On Oct 28, 2006, at 11:09 PM, David Joyner wrote:
>
>> I have questions about coercion rules for finite fields.
>>
>> 1. Let F1 and F2 be two finite fields of order q,
>> x1 in F1, x2 in F2. Do the planned on coercion
On Oct 29, 2006, at 12:16 AM, David Joyner wrote:
> Are these coercions canonical? Sometimes field embeddings depend on on
> choosing a root of a
> polynomial. Can this be done consistently?
Yes and no. I think SAGE should be able to do both. I was just
discussing this with Martin on IRC toda
David Harvey wrote:
> On Oct 29, 2006, at 12:08 AM, David Joyner wrote:
>
>
2. Let F1 subset F2 be two finite fields of order q,
x1 in F1, x2 in F2. Consider the sum x2+x1+x2. The sum
x2+(x1+x2) makes sense but the sum (x2+x1)+x2
does not (assuming that there is no coercion
On Oct 29, 2006, at 12:08 AM, David Joyner wrote:
>>> 2. Let F1 subset F2 be two finite fields of order q,
>>> x1 in F1, x2 in F2. Consider the sum x2+x1+x2. The sum
>>> x2+(x1+x2) makes sense but the sum (x2+x1)+x2
>>> does not (assuming that there is no coercion F2->F1).
>>>
>>
>> I'm not sure
David Harvey wrote:
>
>
>
>> 2. Let F1 subset F2 be two finite fields of order q,
>> x1 in F1, x2 in F2. Consider the sum x2+x1+x2. The sum
>> x2+(x1+x2) makes sense but the sum (x2+x1)+x2
>> does not (assuming that there is no coercion F2->F1).
>>
>
> I'm not sure what you mean by "F1
On Sat, 28 Oct 2006 19:20:31 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
>
>
> On Oct 28, 2006, at 10:05 PM, William Stein wrote:
>
>> Regarding ring and algebra elements, suppose x is in a ring R and y
>> is in a K-algebra S.We want to define what "x * y" means. The
>> most natural thi
On Oct 28, 2006, at 11:09 PM, David Joyner wrote:
> I have questions about coercion rules for finite fields.
>
> 1. Let F1 and F2 be two finite fields of order q,
> x1 in F1, x2 in F2. Do the planned on coercion
> rules imply that x1+x2 is defined?
It depends on the implementation of F1 and F2.
I have questions about coercion rules for finite fields.
1. Let F1 and F2 be two finite fields of order q,
x1 in F1, x2 in F2. Do the planned on coercion
rules imply that x1+x2 is defined? I assume so, since there
probably is a coercion map F1 -> F2 (and F2->F1).
The problem is that x1+x2 != x2+x
On Oct 28, 2006, at 10:05 PM, William Stein wrote:
> Regarding ring and algebra elements, suppose x is in a ring R and y
> is in a K-algebra S.We want to define what "x * y" means. The
> most natural thing to me would be
>
> x * yis K._coerce_(x) * y
>
> and that's it. If no c
On Sat, 28 Oct 2006 18:19:52 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> I'm a bit worried about ambiguous situations arising, although I
> can't think of any specific examples. If both objects are module
> elements (or algebra elements) then everything's ok I think. I'm more
> worried abou
On Sat, 28 Oct 2006 17:59:41 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> I'm going to read and think about all of this in a minute, but first
> I just want to clarify something about the code structure.
>
> It looks like the code is organised as follows (either by design, or
> by inertia).
On Oct 28, 2006, at 8:23 PM, William Stein wrote:
> What are the rules for algebras going to be?
>
> Suppose R and S are commutative rings (for simplicity) and M and N are
> R modules and K is an S-module.
>
> Choose x in M and y in N. Then coerce should work exactly as before.
> All the _coerc
On Oct 28, 2006, at 8:23 PM, William Stein wrote:
>
> On Sat, 28 Oct 2006 16:39:10 -0700, David Harvey
> <[EMAIL PROTECTED]> wrote:
>
>> Another issue that slightly complicates this is base rings. When I do
>> x * y, I don't always want to coerce into the same parent; sometimes
>> I want to coer
On Sat, 28 Oct 2006 16:39:10 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> Another issue that slightly complicates this is base rings. When I do
> x * y, I don't always want to coerce into the same parent; sometimes
> I want to coerce x into the "base ring" of y (or vice versa), which
> will
On Sat, 28 Oct 2006 16:39:10 -0700, David Harvey
<[EMAIL PROTECTED]> wrote:
> On Oct 28, 2006, at 7:26 PM, William Stein wrote:
>> It would be very nice to make the _coerce_ thing transitive and
>> reflexive:
>>
>> (1) elements of A always coerce to A
>> (2) if elements of A coerce to B
On Oct 28, 2006, at 7:26 PM, William Stein wrote:
> It would be very nice to make the _coerce_ thing transitive and
> reflexive:
>
> (1) elements of A always coerce to A
> (2) if elements of A coerce to B and elements of B coerce to C,
> then
> elements of A must coerce to C.
32 matches
Mail list logo
