Small math bug found

[Ionic Wind Support Team]

A small math bug crept into my code when subtracting a double from a float.  This bug will be fixed in the next update.

The compiler will generate the wrong assembly code for the subtraction of a double from a float.  The follwing code illustrates the problem:

Code Select Expand


global sub main()
{
double b;
float c;
b = 5.0;
c = 1.0f;
writeln(str$(c-b)+"\n");
while GetKey() = "";
return 0;
}


Changing c to a double or b to a float type is a workaround. 

Paul.

[Jan Vooijs]

Now thats one of the problems which will arise in mixing C with C++ in one language!!

Nothing against the hard work Paul is making, i am amazed what he has done allready!! Progress is very fast, tried this mixing of C with C++ myself but that was not easy!

If I remember correctly the "implied" conversion is standard for C++ but in C you will get (if it is a sane compiler) a warning the least, very sane compliers give an error!!
Oke i admit used C some odd 25 years ago till about 1995, proffesionally and have the bible from Kernighan & Ritchie (or K&R for short) on my bookshelf (worn to pieces almost). page 184 $6.2  of K&R states that mixing FLOAT with DOUBLE converts the FLOAT to DOUBLE with padding zero its fraction (of the FLOAT).
So better to convert a FLOAT to a DOUBLE in the abover code of Paul!! The otherway CAN (and will) introduce a round off error in next calculations the so called "compounding roundoff error". Try THAT in a spreadsheet and you are broke in 3 months!!

Still like the language C, but some pointer cast-ing can drive someone stirr crazy (pointer tot a pointer to a pointer to a structure inside a structure, yeah right and that is normal practise? Not! it is bad coding!! But you can do that especially more in C++ than any other language, most laguages do it wrong after two pointers  )

Nothing likes me more than a mix of C (it's simple robustness) with some C++ (its simple classes). So yes i will buy Autora soon, when it is a tad more mature.

Keep up the good work Paul!!

Jan V.

[Ionic Wind Support Team]

Actually it was just a logic problem.  A typo in my subtraction generating code.

In C you can get unwanted results if you don't force precedence

if(loc1.type & 0xFF == TYPE_FLOAT)
{
}

if( (loc1.type & 0xFF) == TYPE_FLOAT)
{
}

== has higher precedence int C than the & operator.  So what was happening is the C compiler was comparing 0xFF to TYPE_FLOAT and 'anding' it with loc1.type.  When I wanted it to 'and' it first, then compare.  Correcting the typo was all that was needed.

Paul.