Ralf Hemmecke <[email protected]> writes:
>> Why not? The question is: commutative with respect to which notion
>> of equality.
>
> Well, you may be right. But unless I see a mathematical definition of
> such an EqUaL, I still cannot claim commutativity, right?
>
>> Of course, equality as implemented violates commutativity. (actually,
>> I think that's my whole point: it's not the implementation of
>> multiplication that violates commutativity, but rather the
>> implementation of equality.)
>
> Ehm, I would somehow want that for domains where = is computabled then
> EqUaL is the same relation as =.
Yes, of course. I think we agreed on that?
>>> ... and on uniqueness of the unit 1? Can you claim that for
>>> PowerSeries?
>>
>> No. and there should be another assertion for that.
>
> So, it's not a monoid?
Hm, it seems to me that natural language is failing us. Again: I
believe that we can assert in FriCAS that TaylorSeries is a Ring, but
"=" is not computable.
I think that TaylorSeries should export Ring, but Ring should not export
"=". The meaning of associativity is then: whenever dealing with a
domain having Ring, we may compute x*(y*z) alternatively as (x*y)*z.
(actually, it seems to me that from this point of view, there is no "="
involved. It is just that the programmer says: I don't care whether you
compute x*(y*z) or (x*y)*z.)
> But equality is fundamental. How whould you define the concept of a
> set if you don't have equality on the elements? You must have
> equality somewhere. And I'd say, it better should be computable.
I claim that many domains are useful even though "=" might not be
computable there. (Set is probably not one of them, but TaylorSeries
certainly is :-) There is no question that it is much better to have
computable "=", but in some cases, we simply cannot get it.
Fortunately, we can sometimes do without, as in the determinant example.
There is a fast algorithm if "=" is available, and a slow one if it
isn't.
>>>> However, we have to rely on commutativity.
>>>
>>> Why?
>
>> I cannot think of an example where it matters right now, but I'm
>> sure there are. (I should add: yes, there is an established
>> definition for determinants in noncommutative rings. But I never
>> worked with such beasts so far.)
>
> That was not my point. I could also define
>
> determinant(x: %): R == 1
>
> But that is probably not a very useful concept of "determinant". But
> it's a perfect definition or rather implementation of a determinant
> function.
But it's not doing what determinant promises to do, i.e. compute the
determinant using one of the definitions found in any textbook.
It may well be that two different definitions of the determinant, while
equivalent, produce different representations of the same result, and in
case we do not have computable "=", there is no way we can have FriCAS
check that the results are the same.
However, unless there is a bug, we can be sure that the results are the
same, i.e., represent the same object.
>> In any case, the current implementations of the determinant almost
>> certainly only give the right result in the commutative case.
>
> What is "right"?
let's say that a_{i,j} are univariate formal power series in x for i,j
in {1,2,3}, and we have a way to compute the coefficient of x^n for
every fixed n. (in principle, given enough time and storage capacity)
Then an operation determinant is "right", if it is able to compute for
every fixed n the coefficient of x^n of det a_{i,j} (in principle, given
enough time and storage capacity).
The operation determinant itself does not need to know about equality in
the following sense - it is only an algorithm.
For example, as mathematicians we know that det A = det A^t. It is well
possible that the representations produced by determinant a_{i,j} and
determinant a_{j,i} are different.
> PS: Let's stop here. It doesn't lead to anything.
I hope it does. I think you made me understand the importance of
separating computability of "=" from the ring axioms. I hope you also
see progress.
Martin
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/fricas-devel?hl=en.
