I’m starting out in Blueprint, just trying to get to grips with things and figured a calculator might be a nice introductory project to make to get me used to variables/some basic math etc.
I’m simply focusing on addition, but have found that even calculations of low value often lead to unexpected results. I suspect floating point errors, but can find no suitable answer on how to resolve it. Integers are no good, as I need people to use decimal values.
Do you have any suggestions on how to resolve this?
I’ve attached an image of what I have so far.
If I’ve approached the whole thing in entirely the wrong way, please say so, but my main interest is knowing how to avoid such errors in future. I come from using GameMaker Studio (don’t laugh!), and using real numbers as opposed to integers was very straight forward and you only hit floating point trouble when dealing with HUGE values, something I’m not intending to do here.
I just randomly noticed it was wrong once, and assumed something terrible was afoot - but now can see it’s simply rounding the value. How do I go about setting the number of decimal places to be greater (or lower) on a text box or variable? Also, would you say the way I approached this was OK?
Cheers, and sorry if I’ve gone slightly off topic.
chulk, unfortunately there isn’t a built-in blueprint function that will let you convert a float to a string with a specific precision, but at least now you know better how to search for an alternative. I’d recommend doing some searching for plugins or blueprint nodes from the community that solve this rather than trying to build your own solution from lower-level blueprint notes. A search phrase like “float to string with precision” should get you started.
Here’s a C++ utility function from the community Wiki that might help (you’d still have to figure out how to turn it into a blueprint node, though):
That same author has also created a library of blueprint nodes that install as a plug-in (although I’ve never used these and it looks like it includes tons of other functionality that you may not need and may make it tricky to install):
Finally, if you’d rather build your own solution from lower-level nodes, you might want to check out this AnswerHub answer:
If my post helps you, consider marking it as a correct answer. Thanks!
Ah, perhaps I was hasty in thinking it was me being silly.
It looks like some oddness is still occurring besides any simple rounding issues. According to this:
0 + 94564.33 = 94564.328
Which definitely has me on track for a D in Mathematics.
Any work around for this kind of deal, or is it related to the things you mentioned? I’ve since found a way to limit the number of decimal places if I needed to when displaying output text, but as for calculating I’d have thought lt it should have enough decimal spaces to figure out that the above calc should be 94564.33 (unless there is some crazy binary madness going on in the background).
Is this kind of inaccuracy just something I have to get used to in unreal or have I taken a wrong turn somewhere?
That is definitely weird, but I can confirm the same thing happens for me. I’ve even eliminated the string → float conversion from the equation by just using an empty blueprint with nothing but an “Add” node and a “Print String” node. When I use the values you provided I get the exact same result. Beyond that, even if I just add a float variable to my blueprint and try to paste the 94564.33 value into it’s “Default Value” it gets immediately changed to 94564.328. From what documentation I’ve been able to find it doesn’t seam like this should be happening. The float type in Unreal Engine follows the IEEE floating-point standard which in my understanding should mean it’s usually accurate to about 6 or 7 decimal digits in most cases. https://wiki.beyondunreal.com/Types
This is all very concerning. I’m planning on making a game which deals in calculations for the most part (a sort of sport management game).
Now I’m worried that my calculations will only ever be “fairly accurate”. That’s not how engineers build bridges! I wouldn’t mind if it was inaccurate after a large number of decimals, but to have 2 decimal points seems highly worrying.
Surely this has cropped up. I don’t understand how this has been allowed to even get out of a very early version, let alone roll on for years! How do people cope with such inaccuracy?! I can’t have 0.33 become 0.328 frankly!
My guess is that you won’t have an issue if you do your calculations at the C++ level. Even if you don’t know C++ it’s fairly easy to create a custom function in C++ that you can use as a node in your blueprints. I don’t quite remember how to do it, but I’ve done it before (and I don’t consider myself very knowledgeable about C++). Here are some Wiki posts that may help guide you through the process:
This one even has an example of a float addition node: