Ralf Hemmecke <[email protected]> writes: >> I think it would be good to define and implement such a scheme. I'd >> think that for quite a few domains we can answer some questions in a >> useful way. > > I don't know what exactly you mean by "such a scheme", but although I > found it somehow strange in the beginning, Aldor's Algebra library > went a more conservative way. There, for example, Float is *not* a > Field. We all know floating point computation is not even > associative, so why should Float be a field. Float is only a model > for the real numbers, it is not the real numbers itself. > > (2) -> TaylorSeries(Integer) has Ring > > (2) true > Type: Boolean > > That is wrong, as well. Well, I don't care whether it is called Ring > or whatever, the problem is that the current classification is not > finegrained enought to cover all cases. > > 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. 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) There is some thinking required, however: should some of these operations have the same signature, but different meaning? Probably not, but I didn't think it through. Proposals welcome! I do not think that it would be difficult to implement a thought through proposal. 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.
