Bizarre division behavior [closed] - c#

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Closed 6 years ago.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Improve this question
I know at a first glance, this will get a duplicate mention. And it very well might be, but I imagine most people are going to think that the answer is similar to this question: Division returns zero
That is not my case. That case, is dividing a smaller number by a larger number integers and getting 0. That makes sense. What's happening for me does not make sense.
Here's my code:
decimal correctedImageWidth = screenWidth / maxColumnsWithMaxSizeImages;
The value for screenwidth, which is an int, is 1024. The value for maxColumnsWithMaxSizeImages, also an int, is 3.
Somehow, correctedImageWidth becomes 0. Which is odd, because 1024/3 does not equal 0, nor would the rounded off number be 0, like the other SO questions had. You'd think I'd get something like 341. Here's proof that the numbers are what I say they are:
As you can see in my watch. screenWidth is 1024, maxColumnsWithMaxSizeImages is 3. However, dividing these 2 into correctedImageWidth is 0? Is there any reason why I would get 0 from this? I have shown this to colleagues, who are equally as confused. Here's my entire code, perhaps there's something I'm doing? Unlikely, seeing as they're both ints and they both have valid integer values. But obviously there must be something I'm doing? Here's the code:
int maxColumnsWithMaxSizeImages = (int)System.Math.Ceiling(decimal.Divide(1024, 480));
if (maxColumnsWithMaxSizeImages < _minimumImagesPerRow)
{
.....
} else if (maxColumnsWithMaxSizeImages > _maximumImagesPerRow)
{
....
} else
{
//between 2 and 4 columns
var screenWidth = App.ScreenWidth;
decimal correctedImageWidth = (decimal)((decimal)screenWidth / (decimal)maxColumnsWithMaxSizeImages);
decimal test2 = 1024 / 3;
decimal test3 = (decimal)1024 / (decimal)3;
var test = correctedImageWidth;
}
UPDATE
For some reason, it appears that there was a conflict in my variable declarations. Even though I declared them both in different scopes, for whatever reason it was stirring a conflict. After renaming the variable, I get the corrected value.

You've defined the field correctedImageWidth twice, once as int (in the if block) and once as decimal (in the else block).
The screenshot of your Watch window shows the int typed field value, which shows 0 at this point (wasn't assigned since your in the else block). Try watching the decimal typed field, or just hovering your mouse over the other decimal typed field while debugging, it should show you the correct value.

Related

Why does Math.Round give me two different values? [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 5 months ago.
Improve this question
class Program {
static void Main(string[] args) {
double d = 120.5;
Console.WriteLine(Math.Round(120.5)); //121
Console.WriteLine(Math.Round(d)); // 120
}
}
When a variable is passed as an argument into Math.Round it produces an answer similar to Convert.ToInt32 where floating numbers are rounded off to the nearest even number if the trailing tenth number is 0.5.
Anyone can kindly explain? Thanks in advance.
Thanks for the answers! I use Replit most of the time, that's the output I got. But seeing the replies, I tested it again in VS and I got both 120.
I guess there's a bug in replit?
Kindly refer to attachments.
enter image description here
enter image description here
I tested your code and returns 120 in two modes. It is good to know that the Math.Round() has features that you can use.
For example, you can say to always round to a number that is further from zero:
double d = 120.5;
Console.WriteLine(Math.Round(d,MidpointRounding.AwayFromZero)); //always 121
or final digit is even:
Console.WriteLine(Math.Round(d,MidpointRounding.ToEven)); //always 120
and other features like MidpointRounding.ToNegativeInfinity, MidpointRounding.ToPositiveInfinity ....

IndexOf does not return any value in c# [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 4 years ago.
Improve this question
It may seem a duplicate question, but it is not.
I have a simple code. There is a string named book with the value of "mybook".
I want to find the index of 'y' character in "mybook" string. So I used this code but it did not return the index of the 'y' character.
string book = "mybook";
char y = 'y';
int yPosition = book.IndexOf(y);
Console.WriteLine("y position is: ", yPosition);
When I run this code, the answer is this and nothing more:
y position is:
You forgot the include where the formatted element will be included in your format string.
If you change
Console.WriteLine("y position is: ",yPosition);
to
Console.WriteLine("y position is: {0}",yPosition);
you should get the desired behavior. If you were to place a breakpoint on your Console.WriteLine call, you could verify in debug mode that yPosition has a value, and that the value it has is 1.
You forgot to print the value of yPosition:
Console.WriteLine($"y position is: {yPosition}");
The IndexOf method returns -1 if the character or string is not found in this instance. That is why, your variable yPosition should always have some int value. You can check it if you set a breakpoint on the line:
int yPosition = book.IndexOf(y);
In the Console.WriteLine, you forgot to provide the format position for the yPosition. Change the line to following:
Console.WriteLine("y position is: {0}",yPosition);

Redundant Casting in Visual studio [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Im working out a compression ratio and I noticed that I have a "Redundant Cast" in this line:
double ratio = (double)data.Length / (double)comp.Length;
Obviously dividing both array lengths without casting to double will return only the integer component of the number.
But why is this cast redundant?
Having just one cast on one Length removes the warning.
To my understanding if we had:
double ratio = (double)data.Length / comp.Length;
or
double ratio = data.Length / (double)comp.Length;
wouldnt that then potentially cause another developer to get confused about what value is being calculated here.
It seams to me that having an implicit cast can cause code readability issues. Especially in more complex one line calculations (which really is another readability question).
I also thought casting values to different forms produce different outputs depending on where the cast is made in the equation.
As a developer, I can say that
double ratio = (double)data.Length / comp.Length;
or
double ratio = data.Length / (double)comp.Length;
Will never confuse me. I recoginze this "pattern":
Division operation
One operand is casted to double
So, I understand, that second operand and result are double. And I (as developer) don't need second cast operator.

How Math.Round is working? [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 7 years ago.
Improve this question
Recently I found an issue with C# Math.Round that makes me confused:
Math.Round(1.125, 2) == 1.12
However:
Math.Round(1.115, 2) == 1.12
Also
Math.Round(1.225, 2) == 1.23
And
Math.Round(1.215, 2) == 1.22
The last three samples are make sense just want to know how does it work for the first one?
Regarding to the document, if round to nearest even number then why in third sample round to Odd number?
Is anyone has any idea how is rounding the digits?
Updating
As I put the link, I know try to round to nearest even number, I want to know how implementing it (Using shift bytes)?
In the last three examples, it's working as documented. In the first case though, it appears to go wrong:
Math.Round(1.125, 2) == 1.12 // Would expect 1.13
The reason is simple: floats are stored as binary values; not decimal. So it's rounding the binary value that 1.125 has been converted to. In this case it is slightly below 1.125 and thus rounds "the wrong way".

How does the computer convert between types [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
So a common question you see on SO is how to convert between type x and type z but I want to know how does the computer do this?
For example, how does it take an int out of a string?
My theory is that a string is a char array at its core so its going index by index and checking it against the ascii table. If it falls within the range of ints then its added to the integer. Does it happen at an even lower level than this? Is there bitmasking taking place? How does this happen?
Disclaimer: not for school, just curious.
This question can only be answered when restricting the types to a somewhat managable subset. To do so, let us consider the three interesting types: Strings, integers and floats.
The only other truly different basic type is a pointer, which is not usually converted in any meaningful manner (even the NULL check is not actually a conversion, but a special built in semantic for the 0 literal).
int to float and vice versa
Converting integers to floats and vice versa is simple, since modern CPUs provide an instruction to deal with that case directly.
string to integer type
Conversion from string to integer is fairly simple, because no numeric errors will happen. Indeed, any string is just a sequence of code points (which may or may not be represented by char or wchar_t), and the common method to work through this goes along the lines of the following:
unsigned result = 0;
for(size_t i = 0; i < str.size(); ++i) {
unsigned c = str[i] - static_cast<unsigned>('0');
if(c > '9') {
if(i) return result; // ok: integer over
else throw "no integer found";
}
if((MAX_SIZE_T - c) / 10 < result) throw "integer overflow";
result = result * 10 + c;
}
If you wish to consider things like additional bases (e.g. strings like 0x123 as a hexadecimal representation) or negative values, it obivously requires a few more tests, but the basic algorithm stays the same.
int to string
As expected, this basically works in reverse: An implementation will always take the remainder of a division by 10 and then divide by 10. Since this will give the number in reverse, one can either print into a buffer from the back or reverse the result again.
string to floating point type
Parsing strings to a double (or float) is significantly more complex, since the conversion is supposed to happen with the highest possible accuracy. The basic idea here is to read the number as a string of digits while only remembering where the dot was and what the exponent is. Then, you would assemble the mantissa from this information (which basically is a 53 bit integer) and the exponent and assemble the actual bit pattern for the resulting number. This would then be copied into your target value.
While this approach works perfectly fine, there are literally dozens of different approaches in use, all varying in performance, correctness and robustness.
Actual implementations
Note that actual implementations may have to do one more important (and horribly ugly) thing, which is locale. For example, in the German locale the "," is the decimal point and not the thousands seperator, so pi is roughly "3,1415926535".
Perl string to double
TCL string to double
David M. Gay AT&T Paper string to double, double to string and source code
Boost Spirit

Categories