On 10/06/2018 10:51, Marc Mezzarobba wrote:
Travis Scrimshaw wrote:
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 agree with that.
Mee t
Travis Scrimshaw wrote:
>> 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 agree with that.
>> Though, close to what Nils talked about
On Saturday, June 9, 2018 at 7:44:45 AM UTC-7, William wrote:
>
>
> Fortunately, for sage floats // is an error, rather than a wrong answer:
>
> sage: 2.5 // 3.5
> TypeError: unsupported operand parent(s) for //: 'Real Field with 53
> bits of precision' and 'Real Field with 53 bits of precisio
On Saturday, June 9, 2018 at 7:44:45 AM UTC-7, William wrote:
>
> That "QQ(1) // QQ(2)" returns 1/2 in Sage is surely a mistake.
It may be a mistake, but I am very happy with the consequence. This is what
I'd expect // to do on the rationals.
FWIW in magma:
> 5 div 2;
2
> R:=pAdicRing(7); a:=R!
On Saturday, June 9, 2018 at 4:44:45 PM UTC+2, William wrote:
>
> (also, it's called "floor division"!)
>
And ^ is called bitwise xor... Arguably we are just switching // to be
something else than floor division since that doesn't make a whole lot of
sense in a math system that comes with many
On Sat, Jun 9, 2018 at 7:18 AM, Jeroen Demeyer wrote:
> On 2018-06-09 11:12, Volker Braun wrote:
>>
>> But thats the thing about //, it is not natural wrt. embedding in a
>> larger ring. The whole point is that it throws away information, so you
>> cannot expect the diagram to commute:
>>
>> sage:
On 2018-06-09 11:12, Volker Braun wrote:
But thats the thing about //, it is not natural wrt. embedding in a
larger ring. The whole point is that it throws away information, so you
cannot expect the diagram to commute:
sage: ZZ(1) // ZZ(2)
0
sage: QQ(1) // QQ(2)
1/2
True, I didn't know that. I
On Saturday, June 9, 2018 at 9:13:15 AM UTC+1, Marc Mezzarobba wrote:
>
> Travis Scrimshaw wrote:
> > 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
On Saturday, June 9, 2018 at 9:54:03 AM UTC+2, Jeroen Demeyer wrote:
>
> It should stay in the same ring, but what should the result be? I
> personally would expect (1 // x) == 0 for Laurent polynomials because
> that extends the // operation (Euclidean division) of ordinary
> polynomials.
Bu
Travis Scrimshaw wrote:
> 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.
Yes, but is that rea
On 2018-06-09 07:13, Nils Bruin wrote:
and often it is suggested that "//" works to stay in the ring, and it does:
It should stay in the same ring, but what should the result be? I
personally would expect (1 // x) == 0 for Laurent polynomials because
that extends the // operation (Euclidean d
On Friday, June 8, 2018 at 9:56:56 AM UTC-7, vdelecroix wrote:
>
>
> 2) Laurent polynomials should conform to the rule (R0) and a / b
> should always be a rational fraction
>
> +1 to this. That seems to be the only consistent choice. There is a bit of
an issue, with the partial "division" operat
On 2018-06-08, John Cremona wrote:
> On 8 June 2018 at 10:25, Jeroen Demeyer wrote:
>
>> I vote for
>>
>> 2) Laurent polynomials should conform to the rule (R0) and a / b
>>> should always be a rational fraction
>>>
>>
>> by analogy with other parents, in particular polynomials.
>
>
> +1
+1, too
13 matches
Mail list logo
