#35 --enable-jit-fpu errors

v1.0_(example)
closed
nobody
None
5
2015-01-13
2012-05-08
Anonymous
No

I am trying to find out what's wrong with the '--enable-jit-fpu' option. Curiously, when I test with http://eureka.atari.org/eurkafpu.zip the
inequality images, it means "formula.fmu/image2d.fmu/inequal.fmu/*.fmu" 2D images, imported from Graphic Calculator, none of those are drawing.

It tells that when computing FPU expressions of the type "<", ">", "<=", ">=", "==", and "!=" with C language, these expressions aren't evaluated.

In the Eureka 2.12 sources, this corresponds to the following C code :
"
1 switch(pile->operateur[f]){
2 case EQUAL: / '=' /
3 reel[f-1]=(double)(reel[f-1]==reel[f]&&imag[f-1]==imag[f]);
4 imag[f-1]=0.0;
5 pull(pile,f);
6 f--;
7 break;
8 case SOEQU: / '>=' /
9 reel[f-1]=(double)(reel[f-1]>=reel[f]);
10 imag[f-1]=0.0;
11 pull(pile,f);
12 f--;
13 break;
14 case SUP: / '>' /
15 reel[f-1]=(double)(reel[f-1]>reel[f]);
16 imag[f-1]=0.0;
17 pull(pile,f);
18 f--;
19 break;
20 case NOTS: / '!>' /
21 if(reel[f-1]>reel[f])
22 reel[f-1]=reel[f];
23 imag[f-1]=0.0;
24 pull(pile,f);
25 f--;
26 break;
27 case IOEQU: / '<=' /
28 reel[f-1]=(double)(reel[f-1]<=reel[f]);
29 imag[f-1]=0.0;
30 pull(pile,f);
31 f--;
32 break;
33 case DIF: / '<>' ou '!=' /
34 reel[f-1]=(double)(reel[f-1]!=reel[f]||imag[f-1]!=imag[f]);
35 imag[f-1]=0.0;
36 pull(pile,f);
37 f--;
38 break;
39 case INF: / '<' /
40 reel[f-1]=(double)(reel[f-1]<reel[f]);
41 imag[f-1]=0.0;
42 pull(pile,f);
43 f--;
44 break;
45 case NOTI: / '!<' /
46 if(reel[f-1]<reel[f])
47 reel[f-1]=reel[f];
48 imag[f-1]=0.0;
49 pull(pile,f);
50 f--;
51 break;}
"
with lines (3), (9), (15), (21), (28), (34), (40), (46) the result is always "0.0".

Does someone already stated this problem with JIT-FPU computations ? You need to have an ARAnyM version compiled with '--enable-jit-fpu' option, and to test logical assumptions with double type numbers.

With the non-jit-fpu ARAnyM version, these conditional expressions are correctly evaluated, and the Eureka 2.12 2D inequality images are alright.

Does somebody can explain, why "(double)=(double)((double)(op)(double))" conditional operation, with "(op)" being a conditional operator are always false ? That means in the sources "reel[f-1]" is always reset to "0.0" ?

Discussion

  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-05-09

    In facts, there's a problem when rounding computed values. If you test the drawing of "formula.fmu/image2d.fmu/inequal.fmu/cgmac1.fmu" with http://eureka.atari.org/eurkafpu.zip you will obtain the "cgmac1ko.jpg" joined result image. The "cgmac1.fmu" formula is

                           "cos(r)<0"
    

    and this formula is wrongly computed, because the value is always "0.0". But if you modify a very little the formula, it will draw correctly.

    If you draw : "(cos(r)<0)+0.5"

    you will obtain the attached "cgmac1ok.jpg" image that is a correct one. The "cgmac1ko.jpg" image corresponds to a result that is always "0.0". The "cgmac1ok.jpg" image corresponds to a correct result when rounded.

    Because you know that round(x)=floor(x+0.5) when x>0, in the second formula we are rounding the result value. When we draw "cgmac1.fmu" with a non-jit-fpu version, it is of course "cgmac1ok.jpg" that is obtained.

    So, with ARAnyM-JIT-FPU, it seems that there's problems with rounding values.

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-05-09

    cgmac1ok.jpg the correct result

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-05-09

    cgmac1ko.jpg the wrong result

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-07-08

    The bug that is reported here has disappeared with a new compilation of the Eureka 2.12 software. The inequality images are now drawn correctly. This should probably be considered as an artefact in the building process of the Eureka 2.12 software. It is not reproducible anymore. The bug should be considered as closed. Thanks for the attention.

     
  • Petr Stehlik

    Petr Stehlik - 2012-10-10

    OP wants to close this.

     
  • Petr Stehlik

    Petr Stehlik - 2012-10-10
    • status: open --> closed
    • milestone: --> v1.0_(example)
     

Log in to post a comment.