Interesting - could someone try this with VS2010?
-
This isn't a programming question, it's a "I don't know where else to put it" question. I was answering a Q&A question http://www.codeproject.com/Questions/133921/float-number-loosing-percision.aspx[^] So, I gave it a try in C#:
string s = "30.15";
float f = float.Parse(s);
int i = (int) (f * 100);
float g = f * 100;
int j = (int) (g);
MessageBox.Show(i.ToString() + ":" + j.ToString());Gives the message box
3014:3015
Which means that creating a local variable gives a different result... Could someone try this in VS2010 and see if it still occurs? Because I wouldn't expect that...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
This isn't a programming question, it's a "I don't know where else to put it" question. I was answering a Q&A question http://www.codeproject.com/Questions/133921/float-number-loosing-percision.aspx[^] So, I gave it a try in C#:
string s = "30.15";
float f = float.Parse(s);
int i = (int) (f * 100);
float g = f * 100;
int j = (int) (g);
MessageBox.Show(i.ToString() + ":" + j.ToString());Gives the message box
3014:3015
Which means that creating a local variable gives a different result... Could someone try this in VS2010 and see if it still occurs? Because I wouldn't expect that...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
The same for me too.
Regards, Sathesh. The best way to express one's gratitude to the Divine is to feel simply Happy..
-
This isn't a programming question, it's a "I don't know where else to put it" question. I was answering a Q&A question http://www.codeproject.com/Questions/133921/float-number-loosing-percision.aspx[^] So, I gave it a try in C#:
string s = "30.15";
float f = float.Parse(s);
int i = (int) (f * 100);
float g = f * 100;
int j = (int) (g);
MessageBox.Show(i.ToString() + ":" + j.ToString());Gives the message box
3014:3015
Which means that creating a local variable gives a different result... Could someone try this in VS2010 and see if it still occurs? Because I wouldn't expect that...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
This isn't a programming question, it's a "I don't know where else to put it" question. I was answering a Q&A question http://www.codeproject.com/Questions/133921/float-number-loosing-percision.aspx[^] So, I gave it a try in C#:
string s = "30.15";
float f = float.Parse(s);
int i = (int) (f * 100);
float g = f * 100;
int j = (int) (g);
MessageBox.Show(i.ToString() + ":" + j.ToString());Gives the message box
3014:3015
Which means that creating a local variable gives a different result... Could someone try this in VS2010 and see if it still occurs? Because I wouldn't expect that...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
This isn't a programming question, it's a "I don't know where else to put it" question. I was answering a Q&A question http://www.codeproject.com/Questions/133921/float-number-loosing-percision.aspx[^] So, I gave it a try in C#:
string s = "30.15";
float f = float.Parse(s);
int i = (int) (f * 100);
float g = f * 100;
int j = (int) (g);
MessageBox.Show(i.ToString() + ":" + j.ToString());Gives the message box
3014:3015
Which means that creating a local variable gives a different result... Could someone try this in VS2010 and see if it still occurs? Because I wouldn't expect that...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
It's not that surprising - the actual value returned by
float.Parse(s)is 30.149999(...). The problem occurs when you do the cast tointas this drops the fractional part of the number resulting in 3014. Floats are inherently an approximation of an actual number; I guess the correct process here would be to round the float before the cast to ensure that the whole value is accounted for. If better accuracy is required then you should be usingdoublerather thanfloat. Nice discussion about FPA here[^].Sarchasm : The gulf between the author of sarcastic wit and the person who doesn't get it.
-
It's not that surprising - the actual value returned by
float.Parse(s)is 30.149999(...). The problem occurs when you do the cast tointas this drops the fractional part of the number resulting in 3014. Floats are inherently an approximation of an actual number; I guess the correct process here would be to round the float before the cast to ensure that the whole value is accounted for. If better accuracy is required then you should be usingdoublerather thanfloat. Nice discussion about FPA here[^].Sarchasm : The gulf between the author of sarcastic wit and the person who doesn't get it.
Yes - that was what I was expecting. The surprise was that the addition of a local variable to store the intermediate value changed the results...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
Yes - that was what I was expecting. The surprise was that the addition of a local variable to store the intermediate value changed the results...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
Yes - that was what I was expecting. The surprise was that the addition of a local variable to store the intermediate value changed the results...
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
If you change your third line to:
int i = (int)(float)(f * 100);then you get the correct result. I agree it seems like unusual behaviour but I think the processes between building i and j aren't quite syntactically equivalent...??Sarchasm : The gulf between the author of sarcastic wit and the person who doesn't get it.
-
Not in 64bit mode edit: and not with optimizations enabled. Ok, looking at the disassembly. Likely cause: the FPU uses 80bit floats, saving as anything other than that throws bits away.
