Bad compilation bug about sublimeksp HOT 1 CLOSED

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!

from sublimeksp.