Im trying to make multiplicative percentage calculator, for some odd reason the result is awalys the number i want to multiply or so called baseNumber. I can’t find a problem that causes this.
Here is the code:
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.UI;
public class manager : MonoBehaviour {
// Determine objects
public InputField number;
public InputField percent;
public Button calculate;
public Button calculateTheResult;
public Text result;
public void calcuation()
{
// Temporary string to get parsed into integer
string tempString = number.text;
int baseNumber = int.Parse(tempString);
string tempString2 = percent.text;
int multPercent = int.Parse(tempString2);
// Round percent int getting turned into decimal then multiply it by a number
double calculationResult = Mathf.Round(multPercent / 100 * baseNumber);
Debug.Log(baseNumber);
Debug.Log(multPercent);
Debug.Log(calculationResult);
result.text = calculationResult.ToString();
}
}
Since multPercent is an int, “multPercent / 100” is an integer division that will round down to an integer. For example, 150 / 100 == 1, or 99 / 100 == 0. I’m guessing that’s your problem.
Instead of dividing by “100”, try dividing by “100.0” (adding point-zero forces the compiler to treat it as a double instead of an int, and when you do arithmetic with a double and an int the int will automatically be “promoted” to a double).
By the way, if this was the problem, notice that you could have gotten some helpful clues if you’d tried percentages in a wider range, like 478% or -127% or 9999999%. Choosing good test cases is sometimes very helpful in diagnosing problems.
If that doesn’t solve the problem, please post a couple examples of problems that you tried and what appears in your console when you calculate them.
By the way, you might find it helpful in general if your Debug.Log calls included some text labels to say what they’re outputting, instead of only a number. e.g. Debug.Log("baseNumber is " + baseNumber); This makes it less likely that you (or another programmer trying to help you) will misunderstand the message when they look at the log–especially if the log has output from several consecutive attempts.
The forum doesn’t have an “answered” feature. People typically scroll down to the bottom and read the last few comments though, so figure it out from that You could change the title if you really want it clear it is answered if you want.
Um, you could’ve declared the fields as float or double right from the beginning.
You don’t need InputField in a MonoBehaviour script, then parse that string into a number.
Hand-parsing is slow and also doesn’t prevent you from entering wrong characters, but in this case, Unity will do it for you anyway, and also handle any errors along the way.
Just do
public float number;
public float percent;
And be wary of integer arithmetics. Don’t just assume they behave the same. Sometimes you want to make sure that the operands are compatible with the floating point representation, and cast your types beforehand. It also makes the code’s intent easier to read, if not the code itself.
For example
int crates = 15;
int spacingBetweenCratesInCrateDimensions = 3;
float crateWidth = 15.23;
float totalWidth = (float)(crates * spacingBetweenCratesInCrateDimensions) * crateWidth;
Make it a habit to denote single-precision floating point literals like this instead
ah ok, makes sense, I was framing this in my mind, as some sort of an in-editor test. you’re right.
if this is a production code, don’t do float.Parse, do float.TryParse instead. check out the documentation for it
Parse may be preferable to TryParse if the input field is configured in such a way that it’s impossible to enter a string that won’t parse (e.g. if it is limited to characters 0-9 and has a length limit less than the max value you can store in a variable).
But if it’s possible for a user to give you invalid data, then yes, TryParse would generally be the better choice. As a rule-of-thumb, user input cannot be assumed to conform to any rule that you haven’t actually enforced.