Fixing this one had a lot of fun, there was two problems in the compiler.
The first one (specially visible by the 2nd and 3rd case that you present) involved the reporting that the compiler gives to the IDE about which stubs are being used (this is due I had to rewrite the main.c code of the Artem's 009 exe compiler when adapting it for the BETA 3 version, and introduced that bug with it since I forgot to check the "mathType" when it "usesFloat").
The second one (mainly responsible for the 1st and 4th case that you present, since they involve non zero decimals) was a little mistake in the new lexer that Artem coded. When comparing your code compiled with MP 2.02 with a MP 3.0b4 generated class in the hexadecimal editor I saw the real values were wrong in the class's constant pool… that was just the start heh, I ran to the compiler's code and started the reading and debugging process. Few minutes later i saw the problem: when calculating the decimal value of the "real_constant", it was multiplying instead of empowering 10 by the number of decimals the real number had.
The fixes will be included in the next BETA release, hopefully coming in the next days.
Thanks for the report!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems that the floating point arithmetic still needs some work.
Probably the Real type has some ad-hoc implementation (not the IEEE).
I am curious about the solution you have chosen;
it seems that the absolute value of a MIDletPascal real is about
500000 ( < 2^19 ? ) which is clearly not enough.
Anyway, if present, the FP should be more robust.
So, my remarks concerning the beta 5 release:
1. trunc(x) actually gives the rounded value of x
trunc(1.6) = 2 instead of 1.
2. trunc(1.0/300.0*100000.0) is still 317 instead of 333
trunc(1.0/300.0*10000.0) is still 32 instead of 33
3. trunc(exp(1.0)-2.718)*100000.0) is 49 instead of 28
trunc(exp(1.0)-2.718)*10000.0) is 5 instead of 2
4. I wrote a Pascal function RealToString needed to work with reals.
It is of course based on Exp, Log and Trunc.
Unfortunately it cannot be used because Exp(x) returns 0 for x>14.
So for the moment, is is hard even to test the floating point arithmetic.
I wish you success with this remarkable project.
M.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When using the Real type in your code, and due to the inherited stub-based design (I agree there are many things to enhance or change for the 4.0 version in many many areas of the project), please remember to switch the Real Numbers field (in the Project Manager, under your selected build configuration) to Floating-point value (so, amongst other things, Real.class and Real$NumberFormat.class are inserted into the JAR file instead of the F.class), otherwise MP 3.0 will not have an enhanced precision when operating with reals. This variation in the Real type precision may sound weird for the new MP programmer, but this has a very important reason: JAR file size. May be you were using the now deactivated {$R+} 009 compiler directive (I removed it from the compiler in the last release to avoid confusion on how to set this feature on), or just never switched from the Fixed-point value in the Real Numbers field. That may explain why you are getting the same wrong values than before.
Here in my tests, now MP 3.0 has exactly the same behaviour than MP 2.02, which is the goal for this stage of the project.
And just to clarify to everyone new to MP reading this I will remember everyone that this all means that there are not planned any new features or enhancements for the current C compiler (the one that Niksa released, Artem enhanced, and I bugfixed and adjusted, and will release its source code as soon as the project reaches the FINAL stage) in this field (or any other aspect), I'm just bugfixing it to behave exactly the same than the MP 2 one, so existing projects can be safely migrated to abandon forever the old commercial application. Instead of adding more things to the old compiler, the project is focusing in developing a new compiler in FreePascal (so the whole community can collaborate to enhance it), where new features may be expected. This new compiler for the 4.0 is being developed by Wes.
Btw, I forgot to mention in my last post, but the RealToString function it is not included in the current implementation since it is not present in MP 2.0 (same reason as before). What people uses to easily convert a real to string is the "smart" conversion that MP does, that consists in just preceding an empty string before a real variable concatenation (''+r). For the 4.0 I imagine we should avoid the ton of magic compiler functions we have currently, and start using a more realistic model just like FPC or Delphi has (that means code in RTL units you have to define in the uses list, even if it seems more work for the programmer it's just cleaner, clearer and easily configurable), but that is just my desire, let's see how all this evolves in the future.
Thanks for your post!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There seem to be bugs in the floating point arithmetic.
x := 12345.678;
i:=trunc(x); // = 12362
x := 1.0/300.0*100000;
i:=trunc(x);// = 317 instead of 333
x := 1.0/300.0*10000.0;
i:=trunc(x); // = 32 instead of 33
x := (exp(1.0)-2.718)*10000.0;
i:=trunc(x); // = -172318 instead of 28
Also, a RealToString function is missing.
Mate
Fixing this one had a lot of fun, there was two problems in the compiler.
The first one (specially visible by the 2nd and 3rd case that you present) involved the reporting that the compiler gives to the IDE about which stubs are being used (this is due I had to rewrite the main.c code of the Artem's 009 exe compiler when adapting it for the BETA 3 version, and introduced that bug with it since I forgot to check the "mathType" when it "usesFloat").
The second one (mainly responsible for the 1st and 4th case that you present, since they involve non zero decimals) was a little mistake in the new lexer that Artem coded. When comparing your code compiled with MP 2.02 with a MP 3.0b4 generated class in the hexadecimal editor I saw the real values were wrong in the class's constant pool… that was just the start heh, I ran to the compiler's code and started the reading and debugging process. Few minutes later i saw the problem: when calculating the decimal value of the "real_constant", it was multiplying instead of empowering 10 by the number of decimals the real number had.
The fixes will be included in the next BETA release, hopefully coming in the next days.
Thanks for the report!
It seems that the floating point arithmetic still needs some work.
Probably the Real type has some ad-hoc implementation (not the IEEE).
I am curious about the solution you have chosen;
it seems that the absolute value of a MIDletPascal real is about
500000 ( < 2^19 ? ) which is clearly not enough.
Anyway, if present, the FP should be more robust.
So, my remarks concerning the beta 5 release:
1. trunc(x) actually gives the rounded value of x
trunc(1.6) = 2 instead of 1.
2. trunc(1.0/300.0*100000.0) is still 317 instead of 333
trunc(1.0/300.0*10000.0) is still 32 instead of 33
3. trunc(exp(1.0)-2.718)*100000.0) is 49 instead of 28
trunc(exp(1.0)-2.718)*10000.0) is 5 instead of 2
4. I wrote a Pascal function RealToString needed to work with reals.
It is of course based on Exp, Log and Trunc.
Unfortunately it cannot be used because Exp(x) returns 0 for x>14.
So for the moment, is is hard even to test the floating point arithmetic.
I wish you success with this remarkable project.
M.
When using the Real type in your code, and due to the inherited stub-based design (I agree there are many things to enhance or change for the 4.0 version in many many areas of the project), please remember to switch the Real Numbers field (in the Project Manager, under your selected build configuration) to Floating-point value (so, amongst other things, Real.class and Real$NumberFormat.class are inserted into the JAR file instead of the F.class), otherwise MP 3.0 will not have an enhanced precision when operating with reals. This variation in the Real type precision may sound weird for the new MP programmer, but this has a very important reason: JAR file size. May be you were using the now deactivated {$R+} 009 compiler directive (I removed it from the compiler in the last release to avoid confusion on how to set this feature on), or just never switched from the Fixed-point value in the Real Numbers field. That may explain why you are getting the same wrong values than before.
Here in my tests, now MP 3.0 has exactly the same behaviour than MP 2.02, which is the goal for this stage of the project.
And just to clarify to everyone new to MP reading this I will remember everyone that this all means that there are not planned any new features or enhancements for the current C compiler (the one that Niksa released, Artem enhanced, and I bugfixed and adjusted, and will release its source code as soon as the project reaches the FINAL stage) in this field (or any other aspect), I'm just bugfixing it to behave exactly the same than the MP 2 one, so existing projects can be safely migrated to abandon forever the old commercial application. Instead of adding more things to the old compiler, the project is focusing in developing a new compiler in FreePascal (so the whole community can collaborate to enhance it), where new features may be expected. This new compiler for the 4.0 is being developed by Wes.
Btw, I forgot to mention in my last post, but the RealToString function it is not included in the current implementation since it is not present in MP 2.0 (same reason as before). What people uses to easily convert a real to string is the "smart" conversion that MP does, that consists in just preceding an empty string before a real variable concatenation (''+r). For the 4.0 I imagine we should avoid the ton of magic compiler functions we have currently, and start using a more realistic model just like FPC or Delphi has (that means code in RTL units you have to define in the uses list, even if it seems more work for the programmer it's just cleaner, clearer and easily configurable), but that is just my desire, let's see how all this evolves in the future.
Thanks for your post!