On Fri, May 16, 2008 at 12:06 PM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On May 16, 2008, at 12:01 PM, William Stein wrote:
>
>>
>> On Fri, May 16, 2008 at 11:58 AM, Robert Bradshaw
>> <[EMAIL PROTECTED]> wrote:
>>>
>>> On May 16, 2008, at 8:57 AM, Nick Alexander wrote:
>>>
> (spe
On May 16, 2008, at 12:01 PM, William Stein wrote:
>
> On Fri, May 16, 2008 at 11:58 AM, Robert Bradshaw
> <[EMAIL PROTECTED]> wrote:
>>
>> On May 16, 2008, at 8:57 AM, Nick Alexander wrote:
>>
>>>
(specifically, sqrt(2) would
be an element of QQ[sqrt(2)] with a specified embedding into
On May 16, 2008, at 11:48 AM, William Stein wrote:
> On Fri, May 16, 2008 at 11:44 AM, Carl Witty
> <[EMAIL PROTECTED]> wrote:
>>
>> On May 16, 1:20 am, Robert Bradshaw <[EMAIL PROTECTED]>
>> wrote:
>>> What I think should happen is that sqrt(2) should be an element
>>> of QQ
>>> [sqrt(2)] ra
On Fri, May 16, 2008 at 11:58 AM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On May 16, 2008, at 8:57 AM, Nick Alexander wrote:
>
>>
>>> (specifically, sqrt(2) would
>>> be an element of QQ[sqrt(2)] with a specified embedding into RR, so
>>> stuff like RR(1) + sqrt(2) would work).
>>
>> Simila
On May 16, 2008, at 8:57 AM, Nick Alexander wrote:
>
>> (specifically, sqrt(2) would
>> be an element of QQ[sqrt(2)] with a specified embedding into RR, so
>> stuff like RR(1) + sqrt(2) would work).
>
> Similar to why matrices are over ZZ rather than QQ: why is sqrt(2) in
> QQ[sqrt(2)] and not in
On Fri, May 16, 2008 at 11:44 AM, Carl Witty <[EMAIL PROTECTED]> wrote:
>
> On May 16, 1:20 am, Robert Bradshaw <[EMAIL PROTECTED]>
> wrote:
>> What I think should happen is that sqrt(2) should be an element of QQ
>> [sqrt(2)] rather than an element of SR. There is work supporting this
>> kind of
On May 16, 1:20 am, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> What I think should happen is that sqrt(2) should be an element of QQ
> [sqrt(2)] rather than an element of SR. There is work supporting this
> kind of thing in the new coercion model (specifically, sqrt(2) would
> be an element
> (specifically, sqrt(2) would
> be an element of QQ[sqrt(2)] with a specified embedding into RR, so
> stuff like RR(1) + sqrt(2) would work).
Similar to why matrices are over ZZ rather than QQ: why is sqrt(2) in
QQ[sqrt(2)] and not in ZZ[sqrt(2)]?
Nick
--~--~-~--~~~--
What I think should happen is that sqrt(2) should be an element of QQ
[sqrt(2)] rather than an element of SR. There is work supporting this
kind of thing in the new coercion model (specifically, sqrt(2) would
be an element of QQ[sqrt(2)] with a specified embedding into RR, so
stuff like RR(
This also works fine:
sage: GF(5)(-1).sqrt()
2
as does this
sage: a=GF(5)(2).sqrt()
sage: a
sqrt2
sage: a^2
2
but not GF(5)(sqrt(2)). I can see that coercing simple symbolic
expressions like sqrt(integer) into various fields would not be hard,
but handling arbitrary symbolic expressions would
On Thu, May 15, 2008 at 4:23 PM, David Joyner <[EMAIL PROTECTED]> wrote:
>
> I'm not disagreeing but want to point out one difference.
> RR is an ordered field and this fact is used to differentiate between
> i and -i. However, a finite field such as GF(5) is not, so there is
> some ambiguity to i
On Thu, May 15, 2008 at 4:00 PM, John H Palmieri <[EMAIL PROTECTED]> wrote:
>
> The fact that i is not in CC doesn't bother me too much, since i is a
> "formal square root of -1":
>
> sage: i in CC
> False
>
> I can force it to be in CC by doing this:
>
> sage: CC(i)
> 1.00*I
>
> B
I'm not disagreeing but want to point out one difference.
RR is an ordered field and this fact is used to differentiate between
i and -i. However, a finite field such as GF(5) is not, so there is
some ambiguity to i. It seems to me that this should be resolved somehow.
On Thu, May 15, 2008 at 7:0
13 matches
Mail list logo
