Hello Simon,
> One can of course try the following rule for constructing C: If the
> minimal polynomial used in the construction of GF(8,'x') is obtained
> from the minimal polynomial used in the construction of GF(8,'y') by
> substitution y->x, then the map extends to an isomorphism that shall
>
On 18 September 2015 at 16:21, Simon King wrote:
> Hi Nathann,
>
> On 2015-09-18, Nathann Cohen wrote:
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1(1) == K2(1)
False
>>>
>>> Not a bug, because cross-parent comparison would only make sense if
>>> there is some kind of a c
Hi Nathann,
On 2015-09-18, Nathann Cohen wrote:
>>> sage: K1 = GF(8,'x')
>>> sage: K2 = GF(8,'y')
>>> sage: K1(1) == K2(1)
>>> False
>>
>> Not a bug, because cross-parent comparison would only make sense if
>> there is some kind of a canonical map of one parent (and not just of a
>> single elemen
Simon,
>> sage: K1 = GF(8,'x')
>> sage: K2 = GF(8,'y')
>> sage: K1(1) == K2(1)
>> False
>
> Not a bug, because cross-parent comparison would only make sense if
> there is some kind of a canonical map of one parent (and not just of a
> single element!) into the other or of both parents into a third
Hi Nathann,
On 2015-09-17, Nathann Cohen wrote:
> Here is another discovery after 15 minutes of debugging:
>
> sage: K1 = GF(8,'x')
> sage: K2 = GF(8,'y')
> sage: K1(1) == K2(1)
> False
Not a bug, because cross-parent comparison would only make sense if
there is some kind of a canonical map of o
On Thu, Sep 17, 2015 at 8:00 AM, Nils Bruin wrote:
> On Thursday, September 17, 2015 at 2:54:15 AM UTC-7, Simon King wrote:
>>
>> The real problem here is that *conversion* gives rise to an error
>> that mentions *coercion*.
>>
>> sage: K. = GF(25)
>> sage: L. = GF(25)
>> sage: K(y)
>> Tra
On Thursday, September 17, 2015 at 2:54:15 AM UTC-7, Simon King wrote:
>
> The real problem here is that *conversion* gives rise to an error
> that mentions *coercion*.
>
> sage: K. = GF(25)
> sage: L. = GF(25)
> sage: K(y)
> Traceback (most recent call last):
> ...
> TypeError:
On Thu, Sep 17, 2015 at 2:53 AM, Simon King wrote:
> Hi!
>
> On 2015-09-17, Jeroen Demeyer wrote:
>> On 2015-09-16 16:43, Jean-Pierre Flori wrote:
>>> Hi,
>>>
>>> I guess one of the issue is that there is no canonical map between two
>>> different representations of the same finite field (so no c
Equals is not transitive in Sage. Addition (of floating point
numbers) is not commutative either. And many, many other things that
are different from our perfect abstractions when you try to model
infinite objects in a finite machine. I definitely do not consider
this a bug:
sage: K1 = GF(8,'x
This one is also fun:
sage: K = GF(8, 'a')
sage: K(1) == ZZ(1) == QQ(1)
True
sage: K(1) == QQ(1)
False
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+
Another instance of our non-transitive equality
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1.one() == 1 == K2.one()
True
On 17/09/15 07:19, Nathann Cohen wrote:
Here is another discovery after 15 minutes of debugging:
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1(1) == K2(1)
False
Here is another discovery after 15 minutes of debugging:
sage: K1 = GF(8,'x')
sage: K2 = GF(8,'y')
sage: K1(1) == K2(1)
False
Nathann
On 17 September 2015 at 12:15, Vincent Delecroix
<20100.delecr...@gmail.com> wrote:
>
>
> On 17/09/15 06:53, Simon King wrote:
>>
>> Hi!
>>
>> On 2015-09-17, Jero
On 17/09/15 06:53, Simon King wrote:
Hi!
On 2015-09-17, Jeroen Demeyer wrote:
On 2015-09-16 16:43, Jean-Pierre Flori wrote:
Hi,
I guess one of the issue is that there is no canonical map between two
different representations of the same finite field (so no coercion).
The question is real
Hi!
On 2015-09-17, Jeroen Demeyer wrote:
> On 2015-09-16 16:43, Jean-Pierre Flori wrote:
>> Hi,
>>
>> I guess one of the issue is that there is no canonical map between two
>> different representations of the same finite field (so no coercion).
>
> The question is really: is the map between repre
14 matches
Mail list logo