failed test

[Ralf Hemmecke]

Hi Waldek,

the test

testEquals("omegapower(o2) + 7*omegapower(o1)", "o3")
https://github.com/fricas/fricas/blob/master/src/input/ord.input#L15
fails.


Remark about notation:

Although I can somehow understand you motivation to use * and + for
"natural" product and "natural" addition of ordinals (just reuse the
PolynomialRing domain), I would be more in favour of reserving * and +
for ordinal multiplication and ordinal addition.

In fact, I would like to show \omega * 2 as the output of \omega +
\omega (ordinal addition), not 2*\omega.

Ralf

=============================================================================
Testsuite: ordinals
failed (total): 1 (1)

failed testcases were:

---------------------------------------------------------------------------
Testcase: ordinals
failed (total): 1 (12)

failed tests were:

5: EQUL: (omegapower(o2) + 7*omegapower(o1), o3)
2 2
omega + 2 omega + 5 omega + 2 omega + 4
Output1: omega + 7 omega
4 omega 2
omega omega + 6 omega + 1
Output2: 7 omega + omega

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> the test
>
> testEquals("omegapower(o2) + 7*omegapower(o1)", "o3")
> https://github.com/fricas/fricas/blob/master/src/input/ord.input#L15
> fails.

What exactly are you doing? For me it works.

>
> Remark about notation:
>
> Although I can somehow understand you motivation to use * and + for
> "natural" product and "natural" addition of ordinals (just reuse the
> PolynomialRing domain), I would be more in favour of reserving * and +
> for ordinal multiplication and ordinal addition.

Well, it is more than that: '*' and '+' are (semi)ring operations.
That fits nice into FriCAS category structure. "Ordered" operatations
on ordinals have worse properties.

> In fact, I would like to show \omega * 2 as the output of \omega +
> \omega (ordinal addition), not 2*\omega.

I think that this goes into user control of output. More precisely
standard notation is 2*\omega, and this agrees with other domains.
User may wish different output and it is resonable to provide
some means for customization. And that is much more general
problem: users should not be forced to change types to get
y*x as output for polynomials. Sometimes x*2 may be better
than 2*x...

--
Waldek Hebisch

[Ralf Hemmecke]

On 7/3/19 11:27 AM, Waldek Hebisch wrote:
> Ralf Hemmecke wrote:
>>
>> the test
>>
>> testEquals("omegapower(o2) + 7*omegapower(o1)", "o3")
>> https://github.com/fricas/fricas/blob/master/src/input/ord.input#L15
>> fails.
>
> What exactly are you doing? For me it works.

Ummm... well, I think, it might have something to do with a change in my
local FriCAS where I have exported the degree function for
PolynomialRing in a different way. That shouldn't actually be the case,
but it needs further investigation of what the real reason is.

>> Remark about notation:
>>
>> Although I can somehow understand you motivation to use * and + for
>> "natural" product and "natural" addition of ordinals (just reuse the
>> PolynomialRing domain), I would be more in favour of reserving * and +
>> for ordinal multiplication and ordinal addition.
>
> Well, it is more than that: '*' and '+' are (semi)ring operations.
> That fits nice into FriCAS category structure. "Ordered" operatations
> on ordinals have worse properties.

OK, that's an argument. And due to our problem with renaming monoid
operations, I can / must somehow live with it.
Still, it doesn't make me happy.

>> In fact, I would like to show \omega * 2 as the output of \omega +
>> \omega (ordinal addition), not 2*\omega.
>
> I think that this goes into user control of output. More precisely
> standard notation is 2*\omega, and this agrees with other domains.
> User may wish different output and it is resonable to provide
> some means for customization. And that is much more general
> problem: users should not be forced to change types to get
> y*x as output for polynomials. Sometimes x*2 may be better
> than 2*x...

Maybe, but since with a domain where coefficients commute with
variables, that shouldn't be much of a problem.
However, for SmallOrd, how do I interpret the * in the output 2*omega?
It can only be the "natural product, right? Or is it to be interpreted
as the Cantor normal form, but just with the coefficients on the wrong side?
https://en.wikipedia.org/wiki/Ordinal_arithmetic#Cantor_normal_form

Coming back to "semiring" operations. Aren't you lying when you claim
that SmallOrdinal is a SeminRing? Or do the ordinals form indeed a group
with respect to "natural" addition?

In fact, I wonder how the compiler actually creates code for

0 == 0$Rep

, since the representation is PolynomialRing(NNI, %).

I guess that can only work, because the representation of the 0 of
PolynomialRing is the empty list. Would it fail, if it were not the
empty list?

Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> On 7/3/19 11:27 AM, Waldek Hebisch wrote:
> > Ralf Hemmecke wrote:
>
> >> In fact, I would like to show \omega * 2 as the output of \omega +
> >> \omega (ordinal addition), not 2*\omega.
> >
> > I think that this goes into user control of output. More precisely
> > standard notation is 2*\omega, and this agrees with other domains.
> > User may wish different output and it is resonable to provide
> > some means for customization. And that is much more general
> > problem: users should not be forced to change types to get
> > y*x as output for polynomials. Sometimes x*2 may be better
> > than 2*x...
>
> Maybe, but since with a domain where coefficients commute with
> variables, that shouldn't be much of a problem.
> However, for SmallOrd, how do I interpret the * in the output 2*omega?
> It can only be the "natural product, right?

Yes. "natural" product is commutative.

> Coming back to "semiring" operations. Aren't you lying when you claim
> that SmallOrdinal is a SeminRing? Or do the ordinals form indeed a group
> with respect to "natural" addition?

SemiRing means commutative monoid with respect to addition and we
have this.

>
> In fact, I wonder how the compiler actually creates code for
>
> 0 == 0$Rep
>
> , since the representation is PolynomialRing(NNI, %).
>
> I guess that can only work, because the representation of the 0 of
> PolynomialRing is the empty list. Would it fail, if it were not the
> empty list?

Yes, that is tricky. It works because we can compute 0 without
looking at the type.

--
Waldek Hebisch