Ralf Hemmecke wrote: > > On 06/30/2014 04:05 AM, Waldek Hebisch wrote: > > The following look very fishy: > > > > (13) -> i1 := interval(1,2)$Interval(Float) + interval(1,2)$Interval(Float) > > > > (13) [2.0,4.0000000000_000000001] > > Type: > > Interval(Float) > > (14) -> i1 - interval(1,2)$Interval(Float) - interval(1,2)$Interval(Float) > > > > (14) [- 2.0000000000_000000001,2.0000000000_000000001] > > Type: > > Interval(Float) > > (15) -> i1 - (interval(1,2)$Interval(Float) + interval(1,2)$Interval(Float)) > > > > (15) [0.0,0.0] > > Type: > > Interval(Float) > > Why? Float is not holding exact values, so how would the system know > whether (when it sees) 2.0000 is not actually coming from 2.00004? (For > simplicity I've reduced the precision to precision(18).)
The point is that difference between (14) and (15) is way beyond rounding error. In any ring 'a - (b + b)' and 'a - b -b' should give the same result. > > Also: > > > > (16) -> interval(1,2)$Interval(Float) - interval(1,2)$Interval(Float) > > > > (16) [0.0,0.0] > > Type: > > Interval(Float) > > > > is problematic. > > > > Comments says that getting [0.0, 0.0] as a difference of equal intervals > > is a a hack to make sure that ring axioms hold, however: > > Yep, and that's the wrong thing. And it's not only here but already > Float is claiming that it is a Ring. That's totally wrong and everyone > knows this. It's in the library in this way, to allow matrices of > floats, since Matrix requires it's argument to be at least an > AbelianMonoid. And that would be problematic if Float were not a Ring. Well, Float is red herring here: the same problem would be present if we allowed intervals with exact ends. In exact arithmetic operations on intervals are associative and commutative. But the distributive law fails: [1/2,3/2] = [1] + [-1/2,1/2] [1/2,3/2]*[1/2,3/2] = [1/4. 9/4] [1]*[1] + [1]*[-1/2,1/2] + [-1/2,1/2]*[1] + [-1/2,1/2]*[-1/2,1/2] = [-1/4, 9/4] In general we have a*(b+c) \subset a*b + a*c. Also, addition of intervals has cancellation property, so we can embed intervals into a group (even module over base ring). Coming back to Float: operation there are associative up to rounding error. So, if you are prepared to ignore rounding error (which typically is small), then usual ring idetities work OK. But for intervals error are not small... > The algebra library in Aldor solves that problem in a way that I find > much more mathematically correct. It introduces and AdditiveType. > > https://github.com/pippijn/aldor/blob/master/aldor/lib/aldor/src/arith/sal_arith.as > > That and all similar categories export all the semigroup/group/ring etc. > operations without any claim about their axioms. > > So floats in Aldor do not inherit from Ring, but just the operations > > https://github.com/pippijn/aldor/blob/master/aldor/lib/aldor/src/arith/sal_fltcat.as > > https://github.com/pippijn/aldor/blob/master/aldor/lib/aldor/src/arith/sal_sfloat.as#L29 > > Since such a change would be very deep, I don't think we can easily > switch to that idea without breaking a lot of things. But eventually, > I'd like to see all such wrong claims removed from the inheritance > hierarchy. Yes, that is possible direction. Concerning implementation, I think it is quite doable. For me main problem is potential loss of expressivness. Namely, currently various opertions are applied only to types that have apropriate mathematical properties. Decoupling math properties and signatures we would be forced to perform operations in cases where only signatures are available. In other words alternatives are: - have strict applicability conditions, but lie from time to time - tell truth always, but have loose applicability conditions In case of Float, I feel that it is acceptable to have just "approximate" identities (and beeing of Approximate category makes this approximate nature explicit). But in case of intervals errors are much larger. -- Waldek Hebisch [email protected] -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
