Noob question, probably easy answer...
-
double tf = double.Parse(textBox1.Text);
double tc = 5 / 9 * (tf - 32);
label1.Text = tc.ToString();If that doesn't work, something's really wrong here. :rolleyes:
Kristian Sixhoej "You can't undo the past... but you can certainly not repeat it." - Bruce Willis
Kristian Sixhoej wrote:
If that doesn't work, something's really wrong here.
Untrue, I think it will still do integer devision on 5 / 9, you have to explicitly put .0 on either to do double devision. Weird, I know, I just noticed that behavior on a test.
-
No it isn't... I used same variable names...
double tf = double.Parse(textBox1.Text); double tc = (5.0 / 9.0) \* (tf - 32); label1.Text = tc.ToString(); -
Oh, I see the problem. We're not entering the values in the calculation as doubles. (5.0 rather than 5) Thanks, Eliott.
-
Kristian Sixhoej wrote:
If that doesn't work, something's really wrong here.
Untrue, I think it will still do integer devision on 5 / 9, you have to explicitly put .0 on either to do double devision. Weird, I know, I just noticed that behavior on a test.
EliottA wrote:
you have to explicitly put .0 on either to do double devision.
Didn't knew that.
EliottA wrote:
Weird, I know, I just noticed that behavior on a test.
IIRC I have never had that problem when doing double divisions. But I probably don't recall correct. ;P
Kristian Sixhoej "You can't undo the past... but you can certainly not repeat it." - Bruce Willis
-
Oh, I see the problem. We're not entering the values in the calculation as doubles. (5.0 rather than 5) Thanks, Eliott.
Remember to change your int.Parse and datatype to double and double.Parse otherwise entering 10.0 in that textbox and parsing it to an int might either through an exception or truncate the double value (I don't know which one) in either case, duplicating the original error!!
-
EliottA wrote:
you have to explicitly put .0 on either to do double devision.
Didn't knew that.
EliottA wrote:
Weird, I know, I just noticed that behavior on a test.
IIRC I have never had that problem when doing double divisions. But I probably don't recall correct. ;P
Kristian Sixhoej "You can't undo the past... but you can certainly not repeat it." - Bruce Willis
I didn't know it either, and I never ran into a problem like that before, I never had to implicitly add a .0 unless it was in java.. even then I vaguely recall something about automatic upgrading datatype or something, I don't know. I completely forget, just remember seeing integer devision smack me in the face a few times in my first programming course.
-
EliottA wrote:
you have to explicitly put .0 on either to do double devision.
Didn't knew that.
EliottA wrote:
Weird, I know, I just noticed that behavior on a test.
IIRC I have never had that problem when doing double divisions. But I probably don't recall correct. ;P
Kristian Sixhoej "You can't undo the past... but you can certainly not repeat it." - Bruce Willis
Being a bit anal about this, I'd do this:
double tf = double.Parse(textBox1.Text);
double tc = 5d / 9d * (tf - 32d);
label1.Text = tc.ToString();Regards, Rob Philpott.
-
Being a bit anal about this, I'd do this:
double tf = double.Parse(textBox1.Text);
double tc = 5d / 9d * (tf - 32d);
label1.Text = tc.ToString();Regards, Rob Philpott.
-
Yep, although I never really have ever used it. I'd rather put 5.0 or something of the sort.
-
will 5.0 def making it a double as opposed to float? Im not trying to correct, seroius question
My opinion is... If someone has already posted an answer, dont post the SAME answer
-
From my recollection yes it will, the default is always double unless explicitly indicated otherwise.
-
I didn't know it either, and I never ran into a problem like that before, I never had to implicitly add a .0 unless it was in java.. even then I vaguely recall something about automatic upgrading datatype or something, I don't know. I completely forget, just remember seeing integer devision smack me in the face a few times in my first programming course.
EliottA wrote:
I never ran into a problem like that before
That's probably because it's not that usual to divide two literal values. Usually one of the operands is a double variable, then the compiler will cast the other operand to double also.
Despite everything, the person most likely to be fooling you next is yourself.