On Sat, Jun 9, 2018 at 8:03 PM Travis Scrimshaw <tsc...@ucdavis.edu> wrote:
>
>
> On Sunday, June 10, 2018 at 12:12:46 AM UTC+10, vdelecroix wrote:
>>
>> On 09/06/2018 04:00, Travis Scrimshaw wrote:
>> > What Vincent has neglected to mention is the reasoning why I am
>> suggesting
>> > to keep the current behavior for Laurent polynomials. A casual user
>> will
>> > almost certainly do
>> >
>> > 1 / x^k
>> >
>> > and then try to do a method on Laurent polynomials (say, iterate over
>> such
>> > element). The rational functions code does not have many of the methods
>> and
>> > features that Laurent polynomials have.
>> >
>> > Also, they (or at least I) would be quite surprised when x^-1 does not
>> > behave the same as 1/x as they are mathematically equivalent. Also,
>> what
>> > about ~x, should that be the same as 1/x or x^-1? You now have to
>> choose
>> > the correct inverse to get working code. I think this inconsistency is
>> far
>> > worse.
>>
>> Mathematically equivalent is first of all vague
>
>
> Can I frame that quote? :P
>
>
>> and secondly not
>> relevant within most CAS since there are tons of different 0 that behave
>> very differently.
>>
>
> I agree that for a CAS, we sometimes need to sacrifice mathematical
> statements for programming reasons (0 is good, plus things like ==, RR).
>
>>
>> I agree that having x^-1 and 1/x being different is confusing. I will
>> update the branch at #25524 to make them identically return a rational
>> fraction.
>>
>
> I think this is even worse than the confusion. I would suspect we will get
> a ton of AskSage questions asking how do we construct x^-1 in the Laurent
> polynomial ring (maybe efficiently). At least, upon seeing this behavior,
> my first approach would be L(1/x) because I know I would leave the ring,
> but then need to come right back (well, if I didn't know that x // y was
> suppose to always return a result in the ring you started).
>
I think I agree with Travis here that Laurent polynomials are different
from every other ring currently in Sage in their relationship to division.
The reason is that they are constructed via localization (like fraction
fields) but the corresponding multiplicative subset is not just R\{0} (and
thus there are non-zero non-invertible elements). Elements of
localizations are explicitly defined as ratios, and if we force divisions
to leave the ring it becomes very awkward to work with elements.
It's already the case that division doesn't always land in the fraction
field, since some rings are not integral domains and thus don't have
fraction fields:
sage: parent(mod(6,8)/mod(3,8))
Ring of integers modulo 8
The standard that I would propose is the following:
1. If R has been constructed as a localization (namely, if the
construction() method returns some kind of localization functor) then the
result of a/b will lie in R. If b is not invertible in R (like 0 in a
field), raise an error. This error can provide instructions on using the
fraction field if R is an integral domain.
2. Otherwise, if R is an integral domain, a/b will live in the fraction
field of R.
3. Finally, if R is not an integral domain, a/b will live in R, raising an
error if b is not a unit.
Of course, currently the construction method for Laurent polynomials is a
special LaurentPolynomialFunctor, but this can be changed. I think an
approach that treats localizations differently is important if we want to
support other kinds of localizations in a reasonable way.
David
>> > I think that any comparison to the integers is a bit unfair given that
>> ZZ
>> > and QQ are generally very good with ducktyping and there is no natural
>> way
>> > to create the inverse of the variables (i.e., what makes them Laurent
>> > polynomials) other than by division or exponentiation.
>>
>> "natural" sounds strange in that context. As already mentioned there is
>>
>> 1 // x
>>
>> to get the inverse of x. And x.inverse_of_unit() also does the job.
>>
>
> Nobody is going to want to type inverse_of_unit() when they want x^-1;
> plus I would never have thought of that to get x^-1.
>
> I had the same first thought as Jeroen with 1 // x == 0, but then I
> thought in terms of quo_rem, and 1 // x should return the quotient, which
> in this case is x^-1. However, it would take a little bit for me to realize
> this is what I have to do.
>
>>
>> Though, close to what Nils talked about, there is no straight
>> method for "internal division or raise error".
>
>
> I thought inverse_of_unit() did this?
>
> Best,
> Travis
>
> --
> 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.
