question : floating point precision.

[Tim Rentsch]

Ah, so you are not discussion the actual qfloat that was being discussed.
Yes, I know that if you do not conform to the C model (which is losely
based on Brown's model), all bets are off. I know that on the Cray-1,
17.0/17.0 != 1.0
so what?

If you'll recall, what started off this subthread was a question (my
question) about whether qfloat /does not/ guarantee something or
/could not/ guarantee something. A qfloat that conforms to the C
Standard /could/ guarantee a*a/a==a for all 30 digit decimal numbers
that it represents, and in fact qfloat could guarantee that and also
still conform to the C model for floating-point given in 5.2.4.4.2.
The original statement about qfloat, namely,

Even your qfloat can not guarantee that with a 30 digit decimal
number that has been read in, (a * a) / a == a.

sounded like it was making a claim about how qfloat is allowed to be
implemented, rather than how it is implemented, and I wanted to
clarify that. In fact qfloat /can/ guarantee the above equality
while still conforming to the Standard and the C floating-point
model, even for a binary base. Perhaps it doesn't, but it can.

Of course you could calculate expressions in arbitrary precision, and
under such circumstances a*a/a==a would certainly be true. But in that
case you are no longer working within a single floating-point type.

In other languages perhaps not, but in C it is. Intermediate
results may be calculated to greater range and/or precision than the
(common) operand type requires, but it's still the same type as far
as C is concerned. More importantly, it's the same expression -- a
conforming C implementation can guarantee a*a/a==a for any or all of
the floating-point types it provides (assuming a represents a number
and a != 0), even those with a binary base and conforming to the C
model given in 5.2.4.4.2.

 

[jacob navia]

If you'll recall, what started off this subthread was a question (my
question) about whether qfloat /does not/ guarantee something or
/could not/ guarantee something. A qfloat that conforms to the C
Standard /could/ guarantee a*a/a==a for all 30 digit decimal numbers
that it represents, and in fact qfloat could guarantee that and also
still conform to the C model for floating-point given in 5.2.4.4.2.
The original statement about qfloat, namely,

Even your qfloat can not guarantee that with a 30 digit decimal
number that has been read in, (a * a) / a == a.

sounded like it was making a claim about how qfloat is allowed to be
implemented, rather than how it is implemented, and I wanted to
clarify that. In fact qfloat /can/ guarantee the above equality
while still conforming to the Standard and the C floating-point
model, even for a binary base. Perhaps it doesn't, but it can.



In other languages perhaps not, but in C it is. Intermediate
results may be calculated to greater range and/or precision than the
(common) operand type requires, but it's still the same type as far
as C is concerned. More importantly, it's the same expression -- a
conforming C implementation can guarantee a*a/a==a for any or all of
the floating-point types it provides (assuming a represents a number
and a != 0), even those with a binary base and conforming to the C
model given in 5.2.4.4.2.

Obviously I put 32 bits extra precision at each operation with qfloats.
Then, I round the result to nearest.
d:\lcc\lccdist>qcalc


Steve Moshier's command interpreter V1.3
Adapted to lcc-win32 by Jacob Navia.

Functions:
h help hex acos asin atan atantwo cbrt cos cot exp expten log logten
floor acosh asinh atanh cosh sinh tanh fac gamma lgamma psi jv yv jypn
jyqn ndtr ndtri erf erfc pdtr pdtri incbet incbetinv incgam incgaminv
ellie ellik ellpe ellpk in gausshyp confhyp frexp ldexp polylog zeta
pow sin sqrt tan cmp bits hexbits digits intcvts float double
longdouble hexinput remainder dm tm em take save system rem lambertw
exit
Variables:
a b c d e f g h i j k l m n o p q r s t u v w x y z pi
Operators:
- , = + - * / % ( )
Maximum decimal digits: 104, with 352 bits
* (17.0/17.0)
1.
* a=0.1
0.1
* sqrt(a)
0.3162277660168379331998893544432718533719555139325216826857504852792594438639238221344248
10837930029518735
* sqrt(a)*sqrt(a)
0.1
* cos(sqrt(a)*sqrt(a))-cos(0.1)
0.
* log(a)
-2.302585092994045684017991454684364207601101488628772976033327900967572609677352480235997
20508959829834197
* exp(log(a))
0.1
* exp(log(exp(log(a))))
0.1
*

It looks good to me