Bad compilation bug

[magneto538]

Let's take some operations involving real and integers:

int_to_real(100) / 2.0
int_to_real(80) / 2.0
int_to_real(60) / 2.0
int_to_real(40) / 2.0
int_to_real(20) / 2.0
int_to_real(800) / 20.0

All these operations return a compilation error. It appears that any operation involving int_to_real(), when applied to constant values, is compiled in exponential notation. Let's take the first operation:

int_to_real(100) / 2.0

This operation should return 50.0, or, in exponential notation, 5.0e1.
SublimeKSP compiles this as 5e1, not 5.0e1, so the script won't apply. The compilation happens successfully, but the script won't be applied. I tried to manually add the missing ".0" and everything works just fine. This happens with any value that can be represented as ne1, where n is a number smaller than 10. This happens ONLY when using int_to_real, so 100.0 / 2.0 will work fine.

[eitherys]

The problem was that Nils used the python Decimal class to perform the expression evaluation (probably for concern of robustness?) He then wrote a custom Real() number class, which contains a str method that is what dictates how it shows up in the compiled output. He seemed to have attempted to convert the scientific notation value back to a floating point representation in this str method, but currently the code written to do that seems incomplete/doesn't make sense.

Furthermore, in Python, the very easy way to turn a scientific notation Decimal class value is simply to cast it to a float(), which I have now done as a replacement to his implementation of the str method. Instead of showing 5e3, it now correctly compiles to 5000.0.

on init
	declare ~a := int_to_real(10000)/2.0
end on

{ Compiled on Wed Sep 27 13:39:45 2017 }
on init
  declare ~a
  ~a := 5000.0
end on

Will be in the next release!