Possible bug in Lite-C 7.80 - duplicating 'double's.

Try this code...

In stage1, array is created, but not initialised cause everything will get filled manually.

In stage 2, values [0] and [1] get set, then 0,1,2,3 are all displayed. Cool.

In stage 3, values [2] and [3] get set, then 0,1,2,3 are all displayed again. WTF??.
look at the values of [0] and [1]... They now equal the values of [2] and [3]... WHY?

Am I doing something dumb?
Its not just the diag_var because if I subtract [2] and [3] from [0] and [1] I get EXACTLY zero on both subtractions.
Am I pushing the limits of the 'double' type too far? Im wondering cause the diag_var values are a little different
to what I set them to. But I put that down to double->var conversion (which is not important at this time).

I dont have a sample, but the EXACT same thing happens if I remove the array and use individually declared doubles.

Any ideas please? (and sorry if this is no bug)

PS: this code ATM lives alone inside the main function with nothing else running, so theres NO chance of anything else interfering.
Running on 7.80 commercial

Var precision is limited to 3 digits behind the decimal, and those 3 digits are identical in your doubles.

http://manual.3dgamestudio.net/aarray.htm

When you want to display the full content of a double, you can not use a var function. For printing variables of any kind, look here:

http://manual.3dgamestudio.net/printf.htm

But I thought by specifying the type like so
"values[0] = (double)2.862738448796;"
over-rode that limitation, and left it with that type's limitations.(in this case double)

Or are ALL 3DGS variable types limited to 3 decimal places? Even floats?
(Note: Ive never had to deal with numbers this "precice" in this ot any other language before)
So if 3DGS cant handle this precision of number (apparently being returned by a DLL)
Any suggestions on work-arounds? Precision data CANNOT be lost...

Thanks and sorry for not being a bug.

A workaround for what? Your code is defining doubles, copying floats into them, and printing them as vars. That's exactly what you're getting.

Vars have only 3 digits after the decimal, no matter if they were converted from double. Look here:

http://manual.3dgamestudio.net/diag_var.htm

When you want to see the content of a variable, use printf, which accepts double variables.

BTW when you write a constant like "2.862738448796", it is a float number with 6 digits precision. lite-C has double variables, but no double constants. A cast operator like (double) can not add more digits to a number.

EvilSOB thanks for your feedback too about this.

printing this doesnot works on my pc..

float am=2.86270802130925;
printf("value is %f ",(double)am);

or

double am=2.86270802130925;
printf("value is %f ",am); goes with 8 decimals i guess only

or even this..

double am=2.86270802130925;
printf("value is %.20f ",am); // Forcing 20 decimals but the output when reach 7 decimals are wrong..


and of course this wont work.. because its just 6 decimals.

float value=2.862738448796;
str_for_float(test,value);
error(test);

how do you compile that piece of code?? my SED is returning sintax errors of cant convert at values[0]=double...
error: CONV:DOUBLE::DOUBLE

This for me is a limitation.. not a bug of function... this happened once when on space game.. but not this precise, like GPS are.

MMike: floats have a maximum precision of about 6 digits, vars 9 digits, and doubles 14 digits. There is no variable with 20 digits precision. Constants in the script are either floats or integers. When you get syntax errors, something's wrong with your version or your code.

EvilSOB and MMike are right. There seems to be no double type precision in Lite-C.

From Microsoft MSDN:





Output:

Borland C++Builder: 0.12345678901234 (correct!)
Atari Lite-C: "equal" + 0.12345679104328 (wrong! last 6 digits are random)

When you want to post something into a discussion, it might be a good idea to read the thread carefully and try to understand the issue. The reasons why your code can't work were already explained above.

You're just confusing constants and variables here. A constant is a number that you type in the script, like "0.12345667789". A variable is a placeholder for numbers. Lite-C knows double variables, but not double constants. Constants are either float or integer, dependent on whether they contain a decimal or not. Thus, they can have only a precision of 6 digits, which is the precision of a float. Please look here:

http://manual.3dgamestudio.net/aarray.htm

Hope this helps and settles this discussion.

Sorry, I was not aware of this limitation.

JCL : Thanks again for help and explainations. The reasons I was going wrong was several-fold.

1> Like bunsen, I was not aware that literal constants get "truncated" to ONLY 'float' or 'int' types.

2> I was (also?) under the MISTAKEN belief that by putting a re-cast operator, like (double), at the
start of the expression would then 'crowbar' any contstants, or intermediate values/results,
into that type, and therefore that level of precision. I WAS WRONG..!! !! See, it can happen

3> Thanks for your reply to MMike giving us the list of precisions IN DIGITS of the different types.
I could never "decrypt" the manual for that information. Any chance that info could be added/clarified
to the manual as one simple sentence in the "Variables" page? And maybe mention constants are only float or int?

4> As for 'diag_var' truncation down to 9 digits, I WAS already aware.

Again, many thanks for your patience and knowledge.


MMike : I think your "CONV:DOUBLE::DOUBLE" problem is that you are using the (double) like this,
double xyz = 12345;
double abc = (double)xyz;
You cant convert a double TO a double, cause it already is.
Whereas I was going from a constant to a double, which is OK.

JCL, i don't know if the problem is or not with the code? i just used the EvilSob code.. But does it work on your side??
im using Version 7.73 13-Mar-2009 (did not updated to 7.80 because in my case, the known bugs are not a problem at the moment, and i went to check and there are no bugs related to this this). Well i can update anyway, But first tell me if its a version problem or not.

Well,I tried to check the origin of the error..

This is EvilSob code:



And Sed complains here:

double values[6];
values[0] = (double)2.862738448796;
saying cant convert Double::Double

after testing that .. i ended up that the error is because of this:

function whatever()
{double val=0; val = (double)350.9898789;}

function whatever() // removing the point ...
{double val=0; val = (double)3509898789;}

(see the number is huge now 35098(...) , not 350.98.. and because of that point.. it returns that error of double..

(Is this normal?)

If i change this to...

function whatever() //changing double to float
{double val=0; val = (float)350.9898789;}

it compiled just fine..
__________________________________________

Second thing is:

Ok one reason i never got aware of this limitation is because that table is confusing, at least for me.. because this is what i learn on school:

as the manual it says : range minimum
float 4 bytes -3.4e38 to 3.4e38 1.2e-38

I though this means 3.4 x 10 ^38 which means.. in scientific notations.
and typing on my university calculator.. 0.0000000(...38 zeros)34 , which is around 35 decimals.