issue-#124 Range-check for SHORT(ENTIER(real))
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#124 Range-check for SHORT(ENTIER(real))
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:
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.
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;
}
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))
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!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.
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#.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.
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 *)
Last edited by Robert on Wed Aug 24, 2016 9:11 am, edited 2 times in total.
Re: issue-#124 Range-check for SHORT(ENTIER(real))
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.)Josef Templ wrote:Some wording ...
Re: issue-#124 Range-check for SHORT(ENTIER(real))
But you did not say how many correct digits (they should all be 3's) the results have!luowy wrote:the c has different result
(I would be interested to know what c returns for the example in my post below.)
Last edited by Robert on Wed Aug 24, 2016 11:16 am, edited 1 time in total.
Re: issue-#124 Range-check for SHORT(ENTIER(real))
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.
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.
- Attachments
-
- Floats.pdf
- (37.74 KiB) Downloaded 5925 times
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: issue-#124 Range-check for SHORT(ENTIER(real))
Thanks, fixed.Robert wrote: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.)Josef Templ wrote:Some wording ...
I also added INC/DEC behavior.
See http://redmine.blackboxframework.org/pr ... 517dd12989.
- Josef
Re: issue-#124 Range-check for SHORT(ENTIER(real))
For LONGINTs I think we have used '/' where it should be 'DIV'.Josef Templ wrote:Thanks, fixed.
I also added INC/DEC behavior.
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))
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.
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.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am