For example one could have that
TaylorSeries(Integer) has RingOperations
meaning that all the usual ring operations are available, but you
don't assert anything about axioms these operations fulfill.
I guess it's only a difference in naming, but I'd call
TaylorSeries(Integer) a Ring, but I wouldn't require Ring to have
equality -- thus I'd make it the same as your RingOperations.
http://en.wikipedia.org/wiki/Ring_%28mathematics%29#Formal_definition
If you want this, then you basically violate any axiom that involves =.
What I mean with "such a scheme" is a *useful* set of categories that
assert various meanings for equality. (it seems to me that
computability problems occur most frequently for equality)
We probably are in favour of the same thing, so we shouldn't argue too much.
Having the same =: (%, %) -> % with a different definition might not be
a big problem, but can become one. For example, one cannot have equality
in Stream(Integer), but if one imposes additionaly properties, namely
finite-stream, then of course that = would be computable. Now what ++
documentation applies? So it seems, having the same name is not a good
idea. I would like to reserve = for a computable total function.
There is some thinking required, however: should some of these
operations have the same signature, but different meaning?
Look into the Aldor library. The most basic type is PrimitiveType. It
implements equality, but look at the documentation that Bronstein has
specified for =.
#if ALDOC
\alpage{$=$}
\Usage{a = b\\ a $\sim=$ b}
\Signatures{
$=$: & (\%,\%) $\to$ \altype{Boolean}\\
$\sim=$: & (\%,\%) $\to$ \altype{Boolean}\\
}
\Params{ {\em a, b} & \% & elements of the type\\ }
\Retval{ If $a = b$ returns \true, then $a$ and $b$ are guaranteed to
represent the same element of the type. The behavior if $a = b$ returns
\false~depends on the type, since a full equality test might not be
available. At least, it is guaranteed that $a$ and $b$ do not share the
same memory location in that case. The semantics of $a~\sim= b$ is
the boolean negation of $a = b$.}
#endif
Ralf
--
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.
