On Thu, Oct 13, 2016 at 3:16 PM, John Cremona <john.crem...@gmail.com>
wrote:
> Thanks Peter for the explanation. Nevertheless, I'm not sure that the
> normal user could have guess that one only gets the clever stuff
> (compatible embeddings into the algebraci closure. The docstring GF?
> does imply this but again does not make a big thing of it.
>
> I think a better design (just of the user interface) would be to
> separate these two things: (i) whether or not you want the field being
> constructed to be part of the potentially costly lattice of fields,
> and (ii) whether or not you want to pick your own name.
>
In order to create finite fields with arbitrary variable names that fit
into a lattice of fields, one possibility would be able to give an
algebraic closure explicitly as an argument to GF. Is that what you're
suggesting?
sage: F = GF(3).algebraic_closure('custom')
sage: K9 = GF(9,'b',Fpbar=F)
sage: K81 = GF(81,'c',Fpbar=F)
sage: K81.has_coerce_map_from(K9)
True
This would be pretty easy to implement (feel free to suggest a name for the
keyword other than 'Fpbar').
> Kwankyu's point is also a good one. It really is not acceptable (from
> a user's point of view) to ask if there any coercions, be told there
> are none, and then be prevented from defining one!
>
This is much tougher, for technical reasons (I agree that it's not ideal
from a user's perspective). Suppose that you're trying to determine
whether there's a coercion from A to B. You know that there's a coercion
from C to B, so you check to see if there's a coercion from A to C,
discovering that there isn't. After searching for a bit, you determine
that none of the ideas for constructing a coercion from A to C worked out,
so there isn't a coercion. In order to forgo this search every time a
coercion from A to B is requested, you cache the result: there is no
coercion A to B and no coercion A to C. These caches are stored on B and C.
Now suppose that the user wants to add a coercion from A to C. If you
allowed this, then the coercion diagram becomes inconsistent, since this
coercion should have implied a coercion from A to B. But there's no easy
way to update the cache on B, since it's not stored on A or C. Sage's
solution is to not allow registering coercions A to B once it has used the
fact that there is no coercion.
Now, it's possible that one could restructure the system to make this
possible. But it wouldn't be easy, and may involve other costs. If you
have suggestions on how to update the documentation to make the issues
clearer, that's another matter. :-)
David
>
> Meanwhile, now we know what is going on we can work round it (here we
> is me + my student Marco Caselli, who came to me saying that it
> appeared to be impossible to iterate over a finite field if it was
> constructed as an extension of another -- which is true if you
> construct things in a perfectly innocent way without realising what is
> happening behind the scenes).
>
> John
>
> On 13 October 2016 at 18:25, Kwankyu Lee <ekwan...@gmail.com> wrote:
> > Hi,
> >
> > On Thursday, October 13, 2016 at 7:14:27 PM UTC+2, Peter Bruin wrote:
> >>
> >> Even though there is no coercion map in this situation, simply trying to
> >> discover a coercion "taints" the target parent by registering the fact
> >> that there is no coercion.
> >
> >
> > Then should we consider this behavior as a bug? There is a coercion rule
> > that there can be at most one coercion from a parent to another parent,
> but
> > it should not be disallowed to register one when there is none yet.
> Right?
> >
> > --
> > 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+unsubscr...@googlegroups.com.
> > To post to this group, send email to sage-devel@googlegroups.com.
> > Visit this group at https://groups.google.com/group/sage-devel.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.
>
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
