INC bug or not

[LWgreys]

Was toying around with the INC instruction with a real variable and found that INC can only increment the value up to 16,777,216 and NOT one digit higher. No overflow ST133, no errors or indicators at all.

[b_carlton]

Not a 'bug'. That's just the nature of 32 bit real (floating point) number storage. If you want a high number of integers use the 'D' storage.

This is kind of like noting that, using just integers, you can't add .1 and get a higher number

Google 'IEEE 754' and start reading.

Reals have 24 bits in the mantissa. Two raised to the 24th power is - you've probably guessed - 16,777,216. Above that it can only rise in jumps of 2 then - still higher - 4 then 8 etc.

[BobO]

It could be argued that I should not have supported floating point in INC, as with a couple other integer-centric instructions, but I like having them do something, even if it isn't optimal.

As for overflows and out of range errors, I have mixed emotions. The normal integer behavior is to wrap without error. I could have done a check for float I guess, but all such checks come with a performance penalty, and I tend to avoid those where possible.

[Controls Guy]

Agree on the philosophy, BobO.  Like the MOD case, where it's not strictly the same as the remainder with floats, it's still useful to have it do what it does.

Which leads to a feature suggestion -- a REMAIN function that returns floats when the remainder is a float.  Is there already a function that returns R0 - INT(R0)?  If so, you could use that with a division to get float remainders instead of having to create a new function.

[MikeS]

the MATH functions FRAC() and TRUNC() will give you the two pieces of the real number

[Controls Guy]

Thank you, Mike.

[LWgreys]

This has been some what informative topic.
How about an INC, DEC instructions that has an added parameter for incrementing, decrementing by X amount.
Does anyone have a need for such an option or would the MATH box do?
Would it be viable for such instructions as for CPU speed?

[BobO]

The INC and DEC instructions are not accelerated, so the MATH box would actually be faster, at least as long as you are working with integers.

[plcnut]

I hardly ever use INC or even MOVE anymore, because whenever I want yo come back and add functionality, having a MATH box already in place allows almost anything to be done by simply rewriting one expression. 

[Mike Nash]

I don't remember the value offhand, but it was very small and exponential, and I was finding a lot of R registers had that number rather than zero by default. Others had zero.

When using MATH to add or subtract 0.1 - like an INC or DEC, I could start with zero in an R register, add 0.1, subtract 0.1 and find that tiny but non-zero number back again. Cmore EA9 then wants to display -0.0 which pretty much stinks. I had to add a MATH IF to zero it out if it was very small. Yes, I had exponential display turned off in the EA9.

So while I realize floating point is not integer, I sure didn't understand the non-zero initial values.

As an aside, the EA9 shifts the digits rightward a noticeable amount when the minus sign is turned on. It shouldn't, but it does. Font is Arial 9, which is not usually a monospaced font but tries to be in the EA9 for a numeric display except for that quirk.

[b_carlton]

I use http://www.h-schmidt.net/FloatConverter/IEEE754.html to help visualize floating point numbers. Even .1 is an approximation of that value and not exact. This is similar to expressing the fraction 1/3 EXACTLY in a limited number of decimal digits.

Unless the fractional part of the number can be expressed EXACTLY as a sum of sub-multiples of two (1/2, 1/4, 1/8, 1/16 etc) then it will be an approximation. The number of sub-multiples decrease as the integer portion of s number gets larger. (And, as you found out, even going up by '1' goes away as the number gets larger.) This is why you use 'greater than' and 'less than' in real number comparisons rather than 'equals'

Every finite method of storing numbers will have limitations. Integers are more obvious, they don't have fractional parts and they have upper and lower limits. Thee are fairly well understood. The limitations of floating point storage are not as obvious. it looks like 'these are really magic! They can store all these numbers from very small to very large!' But, in 32 bit floats, they use the same number of bits as double integers which have obvious limits. How do they do that? They leave out a whole lot of numbers! The more you know the better you can use this great tool, within its limits.

[Controls Guy]

Exactly, floating point numbers are only approximate.  When you write something in exponential engineering notation (342.5 * 10^6) or regular ex notation (3.425 * 10^8) there's obviously only four significant figures there, and many numbers take more than that to represent (and as you note, some numbers never can be with any number of digits).

[ADC Product Engineer]

Infinite series of numbers, finite number of bits; something has to give.

[BobO]

Infinite series of numbers, finite number of bits; something has to give.

Well stated.