On Mon, Nov 26, 2012 at 12:35 PM, Nils Bruin <nbr...@sfu.ca> wrote:
> On Nov 26, 10:01 am, Christian Stump <christian.st...@gmail.com>
> wrote:
>> 2. accessing the UCF as myUCF = UniversalCyclotomicField(
>> genname="E"). Do people prefer name or names (as in CyclotomicField)
>> over genname ? This would also mean that there is nothing to
>> initialize at startup, and thus no startup time difference.
>
> Almost ... "import" on a file that only contains class and function
> definitions is still not free.
In fact it's often the finding/loading of the file that's more
expensive than actually executing the Python code.
> But we can't really do anything about
> it, short of requiring people to start putting "import" statements at
> the start of their code. Lazy import might still help a little.
FWIW, lazy imports work great for constructors, but horrible for
actual constructed objects.
>> 3. Having myUCF.gen(n) returning the "smallest" primitive n-th root of
>> unity. What about UCF.gen(n,k) to get E(n)^k for the same cost as
>> getting E(n), this is currently as well provided by the function "E".
>
> There are very few examples of "gen" methods that take more than one
> parameter. I only found:
>
> combinat/sloane_functions.py:5362: def gen(self,a0,a1,d):
> combinat/sloane_functions.py:5710: def gen(self,a0,a1,d):
>
> and that's in old and not-much used code. There are gen(self) and
> gen(self,i=0) definitions, so there is a precedent that gen is a
> little variadic. I imagine gen(self,n,k=1) would cause very little
> problems, would fit in nicely with the normal gens and allow for cheap
> specification of the exponent.
>
> There is this precedent for an infinitely generated structure in sage:
>
> sage: P.<A>=InfinitePolynomialRing(QQ)
> sage: A[0]+A[1]
> A_1 + A_0
>
> which means that in your code, one would have UCF.gen(0) == UCF.E
> I'm not sure whether that's appropriate. With that interface one could
> do
>
> sage: Qzeta.<zeta> = UniversalCyclotomicField()
> sage: QE.<E> = UniversalCyclotomicField()
>
> and do
>
> sage: zeta[3]+zeta[5]
>
> or
>
> sage: E[3]+E[5]
>
> This precludes the in my opinion more logical:
>
> sage: Qzeta.3+Qzeta.5
> sage: E=QE.gen # whether defined by default or explicitly
> sage: E(3)+E(5)
>
> from working, so I'd not be a big fan of the "indexed generator"
> paradigm in this case.
Given that one will never request all the generators, it might be
possible to support both. Qzeta.0 wouldn't work, but the others could,
and E(3) on the first returned generator could be supported just as
well as E[3]. This seems the best option I've seen so far (and in
terms of discoverability, maps well to how number fields or polynomial
rings are defined).
> Anyway, to get that working:
>
> sage: preparse("Qzeta.<zeta> = UniversalCyclotomicField()")
> "Qzeta = UniversalCyclotomicField(names=('zeta',)); (zeta,) =
> Qzeta._first_ngens(1)"
>
>> But different embeddings do not seem to be possible for the UCF if I
>> am not mistaken.
>
> There are. The Galois group over Q is Zhat, so UCF has a huge
> automorphism group over Q and hence many embeddings into CC. There are
> also other fields that are not (canonically) subfields of CC that have
> a field isomorphic to UCF as a subfield, for instance the p-adic
> completed algebraic closure C_p.
>
> This is more a matter of future-proofing the design than providing
> functionality right away. Just don't assume there will be only one
> instance of your class. It likely hardly affects your code and it
> keeps much more options open in the future.
For cyclotomic fields we provide, by default, the "standard" embedding
of zeta_N to exp(2*pi*i/N), which lets them all coerce into each other
as well as mix with the real/complex types if need be. (We do the same
for quadratic fields too.) One can, of course, create cyclotomic
fields without such a choice of embedding by passing an extra argument
to the constructor. I think it makes a lot of sense to do that here as
well.
- Robert
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send email to
sage-devel+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
