Well this is an interesting glitch. AL I think you're right about the problem. It looks to me like the interpreter is simply treating the floating points as ints for the increment operation and then returning a float. For example:
displays as 170141183460469230000000000000000000000.000000
1.0(Dec) as a 32 bit floating point = 3F800000(Hex) = 00111111 10000000 00000000 00000000(Bin)
3F800000(Hex) as a 32 bit signed integer = 1065353216(Dec)
1065353216(Dec) + 1065353216(Dec) = 2130706432(Dec)
2130706432(Dec) = 7F000000(Hex) = 01111111 00000000 00000000 00000000(Bin)
7F000000(Hex) interpreted as a 32 bit floating point = 170141183460469231731687303716000000000(Dec)
and we're back to where we started (albeit with greater precision).
Quote: "Will be fixed as part of version 2"
I wonder why not in V1.. After all, surely the solution as other people have said is just to implement it in C++ as
float inc(float val1, float val2)
{
val1 += val2;
return val1;
}
Anyhow whatever is decided, clearly it is not acceptable as is. If floats are not to be supported, the compiler should throw an error in the same way as it would for
str$ = "Hello"
inc str$, 1
Quote: "I bet that very few programmers with yearly experience with ASM, C, C++, etc, will use INC or DEC with floats.
... these are only recommendations by a guy with 30 years experience in ICT."
I'm sure you're right, but I'm afraid the predicted behaviour of an experienced ASM/C/C++ programmer with 30 years experience is largely irrelevant in a language aimed at helping beginners to produce the games they always wanted. Beginners are sure to blunder into this mistake, especially given that it is supposed to be supported in the documentation (which beginners may actually read) and given that it apparently works in DBP. TGC do need to fix this, one way or the other, and in my opinion floats should be supported. A high level BASIC dialect shouldn't be making us worry about data types more than we really have to. Leave that for veteran C++ programmers!
