On Wed, Oct 29, 2008 at 2:32 PM, Gabriel Dos Reis wrote:
>
> Bill Page writes:
>
> | Well in the context of this thread a specific example might be -0. As
> | I understand it, the reason that this value is not included in the
> | domain Float is because the representation used there has no room for
> | it. Instead, the values in Float are *exactly* the numbers
> |
> | (1) mantissa*base^exponent
> |
> | where base=2 and mantissa and exponent are values from domain Integer.
Actually what I wrote above is entirely incorrect. If (1) were true
than the result would be exactly Fraction Integer, not Float. It is
true that the mantissa and exponent are values from domain Integer,
but there is a lot more than (1) going on!
Here is the relevant code extracted from float.spad.pamphlet:
x = y ==
order x = order y and sign x = sign y and zero? (x - y)
sign x == if x.mantissa < 0 then -1 else 1
order(a) == LENGTH a.mantissa + a.exponent - 1
x - y == normalize plus(x,negate y)
negate x == [-x.mantissa,x.exponent]
plus(x,y) ==
mx := x.mantissa; my := y.mantissa
mx = 0 => y
my = 0 => x
ex := x.exponent; ey := y.exponent
ex = ey => [mx+my,ex]
de := ex + LENGTH mx - ey - LENGTH my
de > bits()+1 => x
de < -(bits()+1) => y
if ex < ey then (mx,my,ex,ey) := (my,mx,ey,ex)
mw := my + shift2(mx,ex-ey)
[mw,ey]
normalize x ==
m := x.mantissa
m = 0 => 0
e : I := LENGTH m - bits()
if e > 0 then
y := shift2(m,1-e)
if odd? y then
y := (if y>0 then y+1 else y-1) quo 2
if LENGTH y > bits() then
y := y quo 2
e := e+1
else y := y quo 2
x := [y,x.exponent+e]
x
shift2(x,y) == sign(x)*shift(sign(x)*x,y)
shift(x:%,n:I) == [x.mantissa,x.exponent+n]
zero? a == zero?(a.mantissa)
>
> One of the differences between that representation and the one in
> IEEE is that in IEEE's system, you always get a sign component
> in {-1,+1}. In the Float's representation, you also get a sign component,
> but in {-1,0,+1}, and when the sign projection goes to -1 or +1, the
> mantissa is required to be non-zero (whereas it can be zero in the
> IEEE system). It is not accurate that there is "no room" to represent
> -0. There is plenty room -- it is just required to be ignored, therefore
> the implementation takes advantages of that. Notices that I'm trying
> to make a distinction between a specification and an implementation --
> I don't take implementations as `God given'.
>
Thanks Gaby. You are right.
sign x == if x.mantissa < 0 then -1 else 1
have no dependence on the value of the exponent but sign could without
affecting the concept of zero.
zero? a == zero?(a.mantissa)
> | These rational values always have an exact representation in the
> | domain Fraction Integer and form a specific subset of the real
> | numbers. Among other things, this makes equality in Float fully
> | transitive, where as in some other floating point systems this might
> | not be the case.
>
> I do not understand what you mean by that. In the IEEE's system,
> -0 compare equal to +0. The only way you get the sign is when you
> ask for it.
>
You are right and I was wrong.
As one can see from the above code, Axiom works with an arbitrarily
set fixed precision represented by 'bits()' and equality is defined in
terms of 'zero? (x - y)'. The result of - depends on the value of
'bits()' and is therefore ultimately non-transitive
a = b and b = c does not imply a = c
for some values of a, b and c.
> | Simiarly, %plusInfinity and %minusInfinity are not
> | values in Float.
> |
> | IEEE floats however are something different - wouldn't you agree?
>
> It is as different as short integer is different from long long
> interger :-) Note that floating point systems are parameterized, and
> not all of them are algebraically closed. The IEEE system, as an
> algebra, is closed.
>
But as an algebra what axioms does it obey?
> | What I was supposing is the maybe the domain DoubleFloat (which
> | currently looks more or less just like a fixed precision version of
> Float) should be given semantics that more closely resembles
> IEEE 754.
>
> In OpenAxiom, DoubleFloat is supposed to reflect a (64-bit) double
> precision IEEE-754 floating point datatype. Only Lisp mis abstractions
> get in the way; but thankfully SBCL and ECL provides some (limited)
> ways to get around thise over abstractions.
>
So, would it be a good idea to make Axiom domain Float also conform to IEEE 754?
> Which reminds me that I need to get Bemol up and running, so that I
> can dump the Lisp stuff.
>
In case someone else forgot, on April 22, 2008 Gaby wrote:
> OpenAxiom has much less Lisp codes for the interper and compiler
> than the others from the Axiom family. The goal is to remove any
> reference to Lisp.To succeed, there must be a Boot translator, and
> one that can translate to something other than Lisp -- either C++ or
> Java (anything with better support than Lisp). Fortunately, Boot is
> not complicated and the translator (called Bemol) written in C++ is
> progressing quite well. I hope that by OpenAxiom-2.0, the Bemol
> translator would be a viable alternative.
Regards,
Bill Page.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
open-axiom-devel mailing list
open-axiom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open-axiom-devel
