On 7/31/24 16:49, Waldek Hebisch wrote:>> ((*$sTO)(rs1, s3) - rs2)$sTO
>>
>> gives the same "wrong" result.
>
> It should be
>
> ((*$sTO)(s3, rs1) - rs2)$sTO
>
> and this works without the patch.
I know, but why do you claim that it must be the way you say in a
non-commutative ring? I do not think that it is only my opinion that
this is ambiguous.
>> I have nothing against introducing right-/left- division, but /
should be
>> reserved for the case when x * y^(-1) = y^(-1) * x otherwise I
would leave
>> it undefined.
> Well, division solves equation x = d*y, so we have d = x * y^(-1).
How can you say so in a non-commutative ring? I guess some people claim
that it solves x=y*d.
> This definition is necessary to have sane interaction with
multiplication.
> To do it on the other side is a different operation. If you look
> at definitions in the algebra, FreeDivisionAlgebra, Group and
> XPolynomialRing are quite explicit and define x/y as x * y^(-1).
> In most other cases order does not matter as corresponding
> multiplication is commutative. Possibly the only unclear definition
> is the one in StreamTaylorSeriesOperations.
OK, you convinced me with our definitions in FriCAS. I still see danger
that our formatters transform x/y to \frac{x}{y} also for a
non-commutative domain (I haven't actually checked) and that would be
certainly wrong.
And yes, the docstring of / in StreamTaylorSeriesOperations must
definitely reflect compatibility with FreeDivisionAlgebra and all other
(non-commutative) places.
>> In other words we should have
>>
>> if A has CommutativeRing then
>> "exquo" : (ST A,ST A) -> Union(ST A,"failed")
>> "/" : (ST A,ST A) -> ST A
>> recip : ST A -> UN
>>
>> Maybe we can a bit weaker for recip, but I would still require that
>> x * recip(x) = recip(x) * x. Otherwise recip should fail.
>
> We have:
>
> recip : % -> Union(%,"failed")
> ++ recip(a) returns an element, which is both a left and a right
> ++ inverse of \spad{a},
> ++ or \spad{"failed"} if such an element doesn't exist or cannot
> ++ be determined (see unitsKnown).
>
> So yes, x * recip(x) = recip(x) * x = e where e is the unit element
> for multiplication.
Yes, but then we should also update the docstring in
StreamTaylorSeriesOperations
recip : ST A -> UN
++ recip(a) returns the power series reciprocal of \spad{a}, or
++ "failed" if not possible.
and make this explicit. I do not like that users (even though pretty
intuitive) have to guess that the word "reciprocal" actually refers to
the docstring of recip: % -> Union(%,"failed") (somewhere else) as you
cited above, i.e. that is a left+right inverse.
Should we introduce also a function "\" into StreamTaylorSeriesOperations?
Then I will come up with then necessary modifications in a new patch.
Ralf
--
You received this message because you are subscribed to the Google Groups "FriCAS -
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/a42aaf58-7778-4902-b9ac-a95d5d17da23%40gmail.com.
