Page 5 of 8
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Wed Aug 24, 2016 5:39 am
by Josef Templ
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Wed Aug 24, 2016 7:53 am
by luowy
to Robert
the link
https://people.eecs.berkeley.edu/~wkahan/Triangle.pdf
is too professional for me , so I check your code with a c compiler.
the c has different result:
Code: Select all
#include <stdio.h>
// #include <math.h>
int main(int argc, char** argv){
double a,b,c,x,y;
a = 1000000000000.0;
b = 3.0;
x = a / b - 333333333333.0; //(* Correct to 7 digits *)
c = a / b;
y = c - 333333333333.; // (* Correct to 4 digits *)
printf("%d \n", x==y);
return 0;
}
the BB compiler emit code for X486 for historical reasons, far away from optmization.
but it is base of the BB framework,keep it ASIS is a good choice instead of changing it.
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Wed Aug 24, 2016 8:28 am
by Robert
Josef Templ wrote:Among numerical programmers it is generally agreed that floating point values should normally not
be compared for equality but some epsilon should used as a tolerance.
I agree, but the risk with repeating this too frequently is that people with little numerical analysis experience will interpret
normally as
always. A simple example; our LONGINTs are implemented on the FPU, but it is perfectly reasonable to compare two for equality!
There is no need to change anything in the language or compiler.
As far as I know this is very much the same as in C.
As I said, I think there are / have been more than 1 C standards (I am
not a C expert!). I have just asked a couple of colleagues to run the example above in MATLAB and C#.
With 64-bit floats all the results are correct to 4 digits. With 32-bit floats all the results (C#, no MATLAB test) are correct to 0 digits. These results are what I expected.
So BlackBox is not the same, it is much better (7 digits).
(The numbers in comments are the number of correct digits using REAL or SHORTREALs.)
Code: Select all
PROCEDURE FloatTest*;
CONST
r = 1000000000000. / 3. - 333333333333.;
VAR
a, b, c, x, y, z : REAL; (* SHORTREAL *)
BEGIN
a := 1000000000000.;
b := 3.;
x := a / b - 333333333333.; (* Correct to 7 / 0 digits *)
c := a / b;
y := c - 333333333333.; (* Correct to 4 / 0 digits *)
z := r; (* Correct to 4 / 4 digits *)
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Wed Aug 24, 2016 8:43 am
by Robert
Josef Templ wrote:Some wording ...
A trivial comment; I think you have picked up some unnecessary linefeeds from the .pdf. (I was going to post the .odc also, but phpBB wouldn't take it.)
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Wed Aug 24, 2016 8:49 am
by Robert
luowy wrote:the c has different result
But you did not say how many correct digits (they should all be 3's) the results have!
(I would be interested to know what c returns for the example in my post below.)
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Wed Aug 24, 2016 10:38 am
by Robert
A better example. In the previous example I did not notice that the question was approximated with SHORTREALs, so one should expect the answer to be approximate!
The in-line BlackBox results are much better than the C# results.
What seems to be happening is that BlackBox is carrying all intermediate results to 80 bits, whereas C# is carrying them to 64.
I think that some c compilers, and Java, do (or did) carry them to 64 for REALs (doubles), but only 32 for SHORTREALs (floats), in which case all their results would be as bad as the 'y' results below.
Conclusion: We should not use c as a model for our arithmetic, what we have is much better.
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Thu Aug 25, 2016 5:28 am
by Josef Templ
Robert wrote:Josef Templ wrote:Some wording ...
A trivial comment; I think you have picked up some unnecessary linefeeds from the .pdf. (I was going to post the .odc also, but phpBB wouldn't take it.)
Thanks, fixed.
I also added INC/DEC behavior.
See
http://redmine.blackboxframework.org/pr ... 517dd12989.
- Josef
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Thu Aug 25, 2016 7:55 am
by Robert
Josef Templ wrote:Thanks, fixed.
I also added INC/DEC behavior.
For LONGINTs I think we have used '/' where it should be 'DIV'.
For LONGINTs INC & DEC is it better to say "low order 64 bits"?
"MOD 2^64" might be read as meaning 0 <= n < 2^64.
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Thu Aug 25, 2016 8:34 am
by Robert
Range checking MOD for INTEGERs & LONGINTs.
I think that what you say is correct, but confusing - it confused me! I think it is better to say the same thing for both: "MOD does not require range checking", or not to mention MOD at all.
With the current wording I was wondering why MOD is mentioned in one case, but not the other, as I could not see why the cases should be different.
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Posted: Thu Aug 25, 2016 8:40 am
by Josef Templ