Float incrementation
xrmichael
Posts: 79
I normally ask stupid questions so this will probably be no exception, but could someone explain why
I cannot do this
push:
{
float=float+0.5
}
but I can do this
push:
{
stack_var float f
f=0.5
float=float+f
}
Michael.
I cannot do this
push:
{
float=float+0.5
}
but I can do this
push:
{
stack_var float f
f=0.5
float=float+f
}
Michael.
0
Comments
PROGRAM_NAME='FloatInc'
DEFINE_DEVICE
dvTP=128:1:0
DEFINE_VARIABLE
FLOAT myFloat = 0.0
DEFINE_EVENT
button_event [dvTP,1]
{
push:
{
myFloat = myFloat + 0.5
}
}
Yes 0.5 increment.
This will not compile
define variable
volatile float myFloat
define_device
dvtp = 10000:1:0
button_event [dvTP,1]
{
push:
{
myFloat = myFloat + 0.5
}
}
This will
define_variable
volatile float myFloat
define_device
dvtp = 10000:1:0
button_event [dvTP,1]
{
push:
{
stack_var float f
f=0.5
myFloat = myFloat + f
}
}
I wondered why.
"define variable" should be "define_variable"
and there needs to be a "define_event" prior to "button_event"
If you do that it compiles fine...
ex.
PROGRAM_NAME='FloatInc'
define_variable
volatile float myFloat
define_device
dvtp = 10000:1:0
define_event
button_event [dvTP,1]
{
push:
{
myFloat = myFloat + 0.5
}
}
I know i need this
"define variable" should be "define_variable"
and there needs to be a "define_event" prior to "button_event"
--
But the problem was to this bit
float=float+1 will compile
float=float+0.5 wont compile
float=float+ 0.5 will compile
for some reason it needs a space after the + for a floating addition and not for a whole number the original code i wrote did not have the space after the + and hence did not compile
I will add though, that incrementing floats can lead to unexpected results (other than this one).
Paul
If you're using it in some sort of comparison, well, I don't think you should use floats for that, for obvious reasons. I suppose there are some times when it's appropriate, but I can't think of any. If you're using it to increment a value that you're going to convert to a string using FTOA, I can't see much of a danger but I suppose that depends, too.
The end user, has altered the heating controls and wants .5 degree adjustment, seems over the top, butin these lean times it has given me a bit more work.
Thanks for the feedback.
That said, yes, it does look like a compiler bug.
I just never put a space there for some reason, so after altering the code from 1 to 0.5 along came the error, at least its sorted.
Just because you are incrementing by a half degree doesn't mean you have to use floats. Avoid floats unless you can't. Just double the range of the temperature and use integers. So if the temp range is 50-90 degrees or 40 degrees total, then make your range 80 and increment it by 1. You will have to do some basic math to display it correctly (70.5 instead of 41) but that is left as an exercise for the reader
Paul
True, and with an other alteration to the math i could give them 0.25 degree control and still use an integer. At some point there must be a trade off between the overhead/hassle of conversion vs use of a float.
Could someone actually give me the other examples of when a float can be flawed or not work as intended, and then I may make an more informed decision on the plan of attack next time. Should there be a thread dedicated (or is there one) to this and other things to avoid/quirks when programming, i am sure this would help people who are a little green like me, at programming.
Also thanks for pointing out the alternate approach,as i am the only programmer at our company, and have to build the rack fit the rack etc, i never get chance to bounce programming ideas off anyone other than the forum, and I don't like to ask unless in a corner, as I dont want to become a pain.
Michael
Don't do:
if(aFloat = bFloat)
because it is quite possible that the two numbers will never be equal.
also, don't do:
if(!aFloat)
If you store the value 75.0 in a float, then increment it up and down a couple of times by 0.5, you may wind up with a value of 72.001 or 71.99998 That's unlikely to happen in this particular case because 0.5 has an exact representation in floating point notation, but you just need to be aware that floats don't stay as precise as an integer, especially after multiple operations. You can take an integer 5, multiply it by 3000, then divide it by 3000 and get 5, but do the same thing with a float and you may have 4.999999. As long as you're aware of the limitations it's not a problem.
Another approach to decimals is to use "fixed point" integers, which is a fancy way to say "scale by 10", so 74.5 becomes the integer 745. I'd rather use that approach than scaling by 2, personally.
What Every Computer Scientist Should Know About Floating-Point Arithmetic