Often I find myself having a expression where a division by int is a part of a large formula. I will give you a simple example that illustrate this problem:

int a = 2;
int b = 4;
int c = 5;
int d = a * (b / c);

In this case, d equals 0 as expected, but I would like this to be 1 since 4/5 multiplied by 2 is 1 3/5 and when converted to int get's "rounded" to 1. So I find myself having to cast c to double, and then since that makes the expression a double also, casting the entire expression to int. This code looks like this:

int a = 2;
int b = 4;
int c = 5;
int d = (int)(a * (b / (double)c));

In this small example it's not that bad, but in a big formula this get's quite messy.

Also, I guess that casting will take a (small) hit on performance.

So my question is basically if there is any better approach to this than casting both divisor and result.

I know that in this example, changing a*(b/c) to (a*b)/c would solve the problem, but in larger real-life scenarios, making this change will not be possible.

EDIT (added a case from an existing program):

In this case I'm caclulating the position of a scrollbar according to the size of the scrollbar, and the size of it's container. So if there is double the elements to fit on the page, the scrollbar will be half the height of the container, and if we have scrolled through half of the elements possible, that means that the scroller position should be moved 1/4 down so it will reside in the middle of the container. The calculations work as they should, and it displays fine. I just don't like how the expression looks in my code.

The important parts of the code is put and appended here:

int scrollerheight = (menusize.Height * menusize.Height) / originalheight;
int maxofset = originalheight - menusize.Height;
int scrollerposition = (int)((menusize.Height - scrollerheight) * (_overlayofset / (double)maxofse开发者_JAVA技巧t));

originalheight here is the height of all elements, so in the case described above, this will be the double of menusize.Height.

Disclaimer: I typed all this out, and then I thought, Should I even post this? I mean, it's a pretty bad idea and therefore doesn't really help the OP... In the end I figured, hey, I already typed it all out; I might as well go ahead and click "Post Your Answer." Even though it's a "bad" idea, it's kind of interesting (to me, anyway). So maybe you'll benefit in some strange way by reading it.

For some reason I have a suspicion the above disclaimer's not going to protect me from downvotes, though...

Here's a totally crazy idea.

I would actually not recommend putting this into any sort of production environment, at all, because I literally thought of it just now, which means I haven't really thought it through completely, and I'm sure there are about a billion problems with it. It's just an idea.

But the basic concept is to create a type that can be used for arithmetic expressions, internally using a double for every term in the expression, only to be evaluated as the desired type (in this case: int) at the end.

You'd start with a type like this:

// Probably you'd make this implement IEquatable<Term>, IEquatable<double>, etc.
// Probably you'd also give it a more descriptive, less ambiguous name.
// Probably you also just flat-out wouldn't use it at all.
struct Term
{
    readonly double _value;

    internal Term(double value)
    {
        _value = value;
    }

    public override bool Equals(object obj)
    {
        // You would want to override this, of course...
    }

    public override int GetHashCode()
    {
        // ...as well as this...
        return _value.GetHashCode();
    }

    public override string ToString()
    {
        // ...as well as this.
        return _value.ToString();
    }
}

Then you'd define implicit conversions to/from double and the type(s) you want to support (again: int). Like this:

public static implicit operator Term(int x)
{
    return new Term((double)x);
}

public static implicit operator int(Term x)
{
    return (int)x._value;
}

// ...and so on.

Next, define the operations themselves: Plus, Minus, etc. In the case of your example code, we'd need Times (for *) and DividedBy (for /):

public Term Times(Term multiplier)
{
    // This would work because you would've defined an implicit conversion
    // from double to Term.
    return _value * multiplier._value;
}

public Term DividedBy(Term divisor)
{
    // Same as above.
    return _value / divisor._value;
}

Lastly, write a static helper class to enable you to perform Term-based operations on whatever types you want to work with (probably just int for starters):

public static class TermHelper
{
    public static Term Times(this int number, Term multiplier)
    {
        return ((Term)number).Times(multiplier);
    }

    public static Term DividedBy(this int number, Term divisor)
    {
        return ((Term)number).DividedBy(divisor);
    }
}

What would all of this buy you? Practically nothing! But it would clean up your expressions, hiding away all those unsightly explicit casts, making your code significantly more attractive and considerably more impossible to debug. (Once again, this is not an endorsement, just a crazy-ass idea.)

So instead of this:

int d = (int)(a * (b / (double)c)); // Output: 2

You'd have this:

int d = a.Times(b.DividedBy(c)); // Output: 2

Is it worth it?

Well, if having to write casting operations were the worst thing in the world, like, even worse than relying on code that's too clever for its own good, then maybe a solution like this would be worth pursuing.

Since the above is clearly not true... the answer is a pretty emphatic NO. But I just thought I'd share this idea anyway, to show that such a thing is (maybe) possible.

First of all, C# truncates the result of int division, and when casting to int. There's no rounding.

There's no way to do b / c first without any conversions.

Multiply b times 100. Then divide by 100 at the end.

In this case, I would suggest Using double instead, because you don't need 'exact' precision.

However, if you really feel you want to do it all without floating-point operation, I would suggest creating some kind of fraction class, which is far more complex and less efficient but you can keep track of all dividend and divisor and then calculate it all at once.