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).)

(1) -> precision(18)

   (1)  68
                                                        Type:
PositiveInteger
(2) -> i0 := interval(1,2)$Interval(Float)

   (2)  [1.0,2.0]
                                                        Type:
Interval(Float)
(3) -> i1 := i0+i0

   (3)  [2.0,4.0001]
                                                        Type:
Interval(Float)

So even if the numbers look strange, I find 4.0001 more correct than
4.0000, since the actual value would be 4.00008 and otherwise fall
outside the interval.


> 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.

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.

Ralf

-- 
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.

Reply via email to