> I like using relative_precision and absolute_precision (following what
> I'm used to from MAGMA). Then there is no confusion.
Sounds good (though maybe precision_relative and precision_absolute in
order to make tab completion work?). I'll change the power series
functions to match.
> > 2. A second issue arises with extension fields. In a tower of fields
> > (or rings), we want to have functions that return the field immediately
> > below the current one, as well as the field at the bottom of the tower.
> > We were considering using "ground field" and "base field" ("ground
> > ring" and "base ring"), but base ring is used in power series to mean
> > the coefficient ring. How about "ground field" and "rock bottom field"
> > ("ground ring" and "rock bottom ring")? Also, should the function
> > names in the field and ring cases differ or should we call them both
> > ring extensions?
>
> I don't like "rock bottom field" or "rock bottom ring", since they are
> not terms used in mathematics.
Sure.
> For base ring I always define base_ring,
> and I define base_field when it happens to also be a field. But they
> should be synonyms if they are both defined.
>
> Base ring/field should always be the previous step in the tower.
> Maybe the function for the base first object in a tower of extensions
> could be called
The issue with calling the previous step in the tower base_ring is that
this choice totally conflicts with the definition of base ring for
power series. I don't want to have base ring mean two different things
in the different contexts.
>
> base_ring_of_tower()
>
> and/or
>
> base_field_of_tower()
>
> This has the advantage that you would find it very easily via tab
> completion, and it sounds mathematical and clean.
I like those, though also subject to the complaint above.
>
> > 3. There are a couple of functions in the current implementations of
> > p-adics and power series that I don't think make all that much sense to
> > be there, given their nonexact nature (also because I'm making power
> > series immutable). In particular, I would like to delete
> > additive_order, multiplicative_order, is_zero from padics and
> > __setitem__ from power series.
>
> Definitely delete __setitem__ -- I am making all ring elements immutable,
> so setitem should go (I've probably already deleted it in my copy).
>
> additive_order, multiplicative_order, and is_zero all make perfect
> sense for p-adics, so i don't want to delete them. You could require
> that each function takes a non-optional precision argument, and claim
> to only compute the answer using information up to that precision.
> E.g., is_zero would mean zero up to that precision. additive_order
> would be oo unless is_zero(prec) is True. multiplicative_order
> would involve working modulo p^n, maybe.
I replaced is_zero(self) with is_weakly_zero(self, prec) to emphasize
the fact that you're testing this inexactly. I can do that with
is_zero(self, prec) instead.
I agree that additive order can work the same way: make the user give a
nonoptional precision requirement, and raise an error if you don't know
the number to large enough precision.
I'm torn on multiplicative order. Yes, given any element x of Z/p^n,
you can extend that to a p-adic that has the same multiplicative order
as x. However, I'm not convinced that that should be the
multiplicative order of the p-adic. Maybe call the function
minimum_multiplicative_order and require a precision as well?
David
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
