BST floating point issue?

mhm21

I recently switched to using BST as I needed the unused code removal function. This is possibly be inane, but I ran into an issue using a floating point constant. In the prop tool, I can make an inline definition or declare a constant such as

CON
A = 1.23456789123e-6

PUB
A := 1.23456789123e-6

When I compile using BST, and attempt to print the number using floattostring, I get 1.23457e-9. I realize that I am exceeding the capacity of a floating point single in my declaration, but is this a known issue?
I won't say how many hours I spent tracking this down. It was buried deep in an ongoing project and led to an eventual (hours) divergence issue. Also, this value was a cut/paste from Matlab and I do not need anywhere close to the precision I have listed. However, it is an annoying behavior to the uninitiated.

Aside from this oddity, are there any other quirks to expect when using BST? I searched through the forums but did not come up with anything major.

Duane Degn

mhm21 wrote: »

Aside from this oddity, are there any other quirks to expect when using BST?

I wasn't aware of that glitch in BST. I generally use the Propeller Tool.

Some issues when dealing with values close to pi were discussed here:

http://forums.parallax.com/showthread.php/125498-Any-ways-to-speed-up-Float32?p=1298631&viewfull=1#post1298631

Make sure you're using the latest version of F32. As discussed in the above thread, an earlier version had a bug in the ATAN2 method.

If you're running low on RAM, there are a few tricks which can be done with loading PASM images from SD cards or EEPROM. I modified F32 a bit to allow it to be loaded from EEPROM.

http://forums.parallax.com/showthread.php/160005-F32-as-a-quot-Cogject-quot-(Sort-Of)

The same modified code could also be loaded to/from a SD card.

Most objects which have a PASM section can be separated into Spin and PASM parts and the PASM sections can be stored in external memory. The program will need a buffer (about 2K or at least as long as the largest PASM block) to temporarily hold the PASM images (one at a time) but this 2K buffer can then be reused for other purposes such as an UART buffer.

Dave Hein

mhm21 wrote: »

When I compile using BST, and attempt to print the number using floattostring, I get 1.23457e-9.

What do you get if you compile using the Prop tool? 1.23457e-9 is correct to 6 digits. Anything beyond 7 digits is meaningless in 32-bit floating point. I'm pretty sure that the minor issue with floating point numbers is known in BST. It's just due to the difference in how BST computes floating point numbers versus the Prop tool, but I don't think the difference is significant unless you need the results to be bit-exact with the Prop Tool.

Heater.

Wait a minute Dave,

Th input numbers seems to be:

A := 1.23456789123e-6

But the printed output is given as:

1.23457e-9

That's out by a factor of one thousand! Never mind the loss of least significant digits. Assuming no typos in the first post.

Dave Hein

Oh, I missed that. Yes, you are right, it is off by a factor of one-thousand. I tried a few experiments and if the final 3 is removed the exponent is correct. It gets even worse if you add more digits. I also tested with the number 9.999999...e-6, and found that it failed at 10 digits. I suspect it will work if the mantissa will fit in 32 bits. So the work-around is to use less than 10 digits.

mhm21

Thank you all for your replies. I did the same experiments as Dave and can verify the observations. Again, this likely will not come up all that often (if ever), but it can be a significant gotcha if not documented. I am using this in a sigma-point Kalman filter and it lead to an eventual divergence. Albeit over the course of many minutes. Very annoying and took way too long to track down. But now that I know about it, the benefits of BST in overall code size should pay off.

Duane,
I have been following your eeprom tricks for some time. I have instituted a couple of them for the F-32 objects etc. Works like a champ. 32k means I have to replace brute force with being clever. Unfortunately, clever is very rarely my thing!