issue-#124 Range-check for SHORT(ENTIER(real))

The features that we decide to not apply in the current time
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#124 Range-check for SHORT(ENTIER(real))

Post by Josef Templ »

Some wording improvements, see
http://redmine.blackboxframework.org/pr ... 43fa9c5350.

- Josef
luowy
Posts: 234
Joined: Mon Oct 20, 2014 12:52 pm

Re: issue-#124 Range-check for SHORT(ENTIER(real))

Post 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.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#124 Range-check for SHORT(ENTIER(real))

Post 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  *)
Last edited by Robert on Wed Aug 24, 2016 9:11 am, edited 2 times in total.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#124 Range-check for SHORT(ENTIER(real))

Post 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.)
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#124 Range-check for SHORT(ENTIER(real))

Post 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.)
Last edited by Robert on Wed Aug 24, 2016 11:16 am, edited 1 time in total.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#124 Range-check for SHORT(ENTIER(real))

Post 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.
Attachments
Floats.pdf
(37.74 KiB) Downloaded 224 times
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue-#124 Range-check for SHORT(ENTIER(real))

Post 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
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#124 Range-check for SHORT(ENTIER(real))

Post 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.
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue-#124 Range-check for SHORT(ENTIER(real))

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