DivisionMethod
is a pretty vague/poor name for your method; any method with the word "method" in it should raise a "bad name" flag!
Also, hard-coding the threshold into the function takes away flexibility. Perhaps I'd consider an optional parameter, like this:
public static double RoundedDivision(double a, double b, double threshold = 0.6)
Okay, not sure RoundedDivision
is a much better name... naming is hard!. This is where XML comments can help:
/// <summary>
/// Divides <c>a</c> by <c>b</c> and round up if quotient is
/// greater than <c>threshold</c>, round down if it's less.
/// </summary>
public static double RoundedDivision(double a, double b, double threshold = 0.6)
It's probably best to call a cat, a cat: a
is the dividend
and b
is the divisor
, so the method would be clearer with a signature like this:
/// <summary>
/// Divides <c>dividend</c> by <c>divisor</c> and round up if quotient is
/// greater than <c>threshold</c>, round down if it's less.
/// </summary>
public static double RoundedDivision(double dividend, double divisor, double threshold = 0.6)
As was mentioned in the comments, there's an ambiguity issue with the threshold: what happens if the quotient is exactly equal to the threshold?
0.6
isn't 0.6 in the mathematical sense anymore. That your equation evaluates totrue
is merely luck. There are similar looking equations (such asdouble d = 1.2d/3d; d == 0.4
that won't do so. I'm not even sure if it your example will work reproducibly across different implementations an hardware. \$\endgroup\$MiscUtil.Conversion.DoubleConverter.ToExactString
,0.6d
is represented as0.59999999999999997779553950749686919152736663818359375
(as is1.2d/2d
). Mentally replace all instances of 0.6 with that horrifying number. During output, C# often prints out0.6
(because it chops of the last few digits for display). \$\endgroup\$