Waldek Hebisch <[email protected]> writes: >> Yes, that's precisely the question of above. It seems both of us rather >> had a = b mean just that, and then have additionally >> >> | true | false >> ------------------------------------------------------------------ >> a = b | a and b are equal | otherwise >> provablyEqual | a and b are equal | a and b might be equal >> provablyDifferent | a and b are different | a and b might be different >> >> right? Ring could then export provablyEqual and provablyDifferent (with >> silly default false) but equality would be reserved for domains with >> computable equality like Integer, IntegerMod, AlgebraicNumber, >> Polynomial R, Fraction R, Matrix R, List R, ... (whenever R has >> ComputableEquality). >> >> Are we on the same track? > > I believe to "normal" domains should be computable and our definition > of computable should include equality. In more detail: power of > matchematical reasoning comes from ability to compose results > in arbitrary ways. Once not all operations are computable > reasoning about correctness and code gets _much_ more complicated. > Since not all things are computable we have to provide some > "uncomputable" operations (approximations, probabilistic routines > etc.). But we should prefer computable equivalents if possible.
I think we agree. However, currently the situation is really messy, just consider Stream, Float and Expression. > Coming back to start of this thread: it is possible to compute > determinant in power series domains, but it has to be done > differently than in other domains. More precisely, expanding > determinat into products is inpractical for large matrices > (it seems that already 15 by 15 is inpractical). I did > not check other methods which avoid zero test (it is easy to > find methods which are slightly better than full expansion, > I am not sure if there is something much better). But > in power series domains we really work with finite approximatins > to true infinite value. If column of matrix is zero up to > given order (this is computable condition) then determinant > is zero up to corresponding order. OTOH if we have nonzero > element we can use it as pivot and reduce problem to smaller > matices. So the catch is that we can not use generic method, > but must use method which makes good use of specific context. It is actually not so much that determinant doesn't work what bothers me, but rather that it is advertised to work and doesn't. (Actually, what I'd like best is if FriCAS would throw a NotImplementedError, just as Sage does in many cases.) That's why I suggested to remove = from Ring (I really think we want to consider powerseries domains as rings), and introduce a new category ComputableEquality that exports only that. > Releated, I would prefer clearly specified "precision", > so for example instead of "additive?" which uses some global > variable I would prefer version which takes explict precision > parameter. I think that a global variable is practical enough, but it is important to separate "approximative" answers from exact answers. Moreover, I'd say that Float and TaylorSeries are somewhat similar, but Expression is again different. I certainly want that Expression is a Ring, but I do not want it pretending to have computable equality. 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.
