Control increment is faulty

[Ryzhawk]

Hi there, i was having value problems in my program and couldn't figure out what was going wrong..

Eventually i made up a small test VI to make sure my values were coming out right and look what i found..

Attached is a very simple VI, takes in a value and then displays it. The thing is, i have the precision of the control set to 10 digits,

and the increment set to 0.0500 and if you run it, you will see that when you press the incredment/decrement buttons, it does not go in 0.05 increments but in 0.050000001 increments which is completely throwing off my values!

What is wrong here? Is this just a LabVIEW error?

[Darin.K]

This is just the beauty of floating point math, nothing special with LabVIEW.  0.05 has no exact binary represenation, therefore small errors are inevitable.

Perhaps if we had evolved without opposable thumbs our ancestors would not have developed base 10 math, but I happen to like having thumbs and have learned to live with the floating point issues.

[Ryzhawk]

I'm not sure how the opposable part determins the base 10.. i would have thought just having 10 fingers in general would be enough for that?

So how do i get around this problem?

Is there anything in labVIEW to help it? Or am i going to have to sort the problem manually?

[smercurio_fc]

---

@Ryzhawk wrote:

I'm not sure how the opposable part determins the base 10.. i would have thought just having 10 fingers in general would be enough for that?

---

Well, one could argue that perhaps we really should have developed math to use base 20 since you sometimes get kids to use their toes to count...

---

So how do i get around this problem?

---

Don't use a computer. Instead, do everything by hand on a piece of paper the old-fashioned way.

---

Is there anything in labVIEW to help it? Or am i going to have to sort the problem manually?

---

There is nothing in LabVIEW to help or hurt it. This is not a LabVIEW issue. It's the way numbers are stored in computers. You haven't described what you're actually doing in your program so it's hard to tell you what to do. Are you perhaps doing some sort of division? Are you're doing a subtraction? Are you trying to compare floating points? Perhaps using the Machine Epsilon constant is what you want to look at.

P.S. You owe me another nickel in my retirement fund.

[Darin.K]

If they weren't opposable, I might sacrifice my thumbs for base 8 math. 

My usual "fix" is to use an increment of 0.015625 (1/64) or 0.03125 (1/32).

Do you really need 10 digits? 

[Ryzhawk]

hahaha a nickel in the retirement fund it is.. i'm very, VERY new to programming i will admit  sorry for being such an incredible noob..

I don't need 10 digits,  i need about 5... and it seems the problem is even worse for single precision numbers (which is what i am using)

All i'm wanting to do is quite literally send in a number that isn't off by 0.000001 (EDIT: by sending in a number i mean im sending the number to a device, so i just want to be able to change the number by the increment and have that sent in, i have it as an event so that when that value changes, it is sent to the device) or what ever it may turn out to be depending on how many times the increment button is pressed.. I'm going to try a few different things.

Thanks for your time anyways

[Ryzhawk]

The main problem with it is that i have the maximum value set to 10, but it will only reach 9.95 due to this increment problem... if i keep the precision to only a few digits i dont see those extra numbers tacked onto the end, but this inability to reach the maximum value is frustrating.. I'm really stuck for answers here

[altenbach]

I still think this should be solved directly by NI and I am sure it would be easily possible and cheap.

Have a look at my comment here. I wonder if it ever got written up as an idea?

[Ryzhawk]

Yes! I 100% agree with that comment! So it is a problem other people have.. I searched through the ideas exchange but not sure what it would have been posted as so didn't find anything.. but it definitely should be? It seems such a simple thing..

i did notice in your comment this though,

---

Still, there are several trivial workarounds available, so the absence of this feature should not really stall your project.  Good luck!

---

trivial workarounds? where where where

[falkpl]

one work around- make the max slightly larger than 10 (the actual value will be 10+epsilon)

Just thinking about the 10 finger counting, one could easily count in binary on our fingers but there is a problem with that as well, I just tried it and the numbers 4 and 132 pose problems in some cultures.