Timeline for Why is Math.Sqrt() a static function?
Current License: CC BY-SA 3.0
29 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 13, 2016 at 4:12 | comment | added | user40980 | There are design decisions made. Some of them had consequences that are less than ideal. This works in a consistent and reasonable way (not that its a good reason - but knowing how it works isn't hard and reasoning from that is possible. | |
| Feb 13, 2016 at 4:08 | comment | added | supercat | @MichaelT: For every mathematical real number, there is either a unique float which best represents it, or else there are two which are equally good; there exists no double x, for which there would not be a sensible value y for float y = (float)x;. Nonetheless, implicit conversions from double to float were disallowed because they're "lossy". If lossy conversions aren't acceptable, there's no reason a compiler should favor a lossier conversion to a less lossy one. | |
| Feb 13, 2016 at 3:54 | comment | added | user40980 | @supercat Long.MAX_VALUE is 2^63. The float can represent up to 2^127. There is no reason to widen it further when there are two methods that both match that signature - it choses the one that requires the least amount of widening. The thing is that int->float is a perfectly acceptable conversion and doesn't make sense as a compilation error. And Math.Round() just sees a float come in - it doesn't know that it was originally an int. You are making arguments for Math.round(int) which... doesn't make sense as a call. | |
| Feb 13, 2016 at 3:50 | comment | added | supercat | @MichaelT: If one has something like Math.round(woozle() * 1.001); and the because of changing requirements the scaling factor is no longer necessary, would it be visually obvious that omitting the * 1.001 may totally corrupt the results? IMHO, attempting to round a non-floating-point type should either return the original value unmodified or else yield a compilation error. Further, the rule that considers long->float to be a better promotion than long->double is IMHO poorly considered. | |
| Feb 13, 2016 at 3:38 | comment | added | user40980 | (key point: a float can hold a Long.MAX_VALUE - so you don't need to widen the long to a double - it can fit in a float) - this is covered in section 5.1.2 of the JLS) | |
| Feb 13, 2016 at 3:34 | comment | added | user40980 | @supercat in Java, each is converted to a float and then rounded back to a int. This particular one has some.... lets say nonsensical values returned (as both were changed to float, the second one was the int round(float f) which returned max_int), however I would contend that you asked it a non-sensical question there. You might want instead to look at abs which has four signatures - one for each primitive type. | |
| Feb 13, 2016 at 3:22 | comment | added | supercat | @MichaelT: What should be the effect of int foo = Math.round(123456789);? How about long foo=Math.round(12345678901234L);? | |
| Nov 4, 2015 at 20:41 | comment | added | Pierre Arlaud | For the record there are languages in which the Int class extends the Double class, and that also makes this answer complete nonesense! | |
| Nov 4, 2015 at 14:48 | comment | added | Ben Aaronson | @MichaelT I'm not proposing anything. As I said in my first comment, there are reasons to have these methods static, including the third bullet point in this answer. What I'm questioning is whether the argument in the second paragraph of this answer makes sense as one of those reasons. | |
| Nov 4, 2015 at 14:43 | comment | added | user40980 | @BenAaronson what would you do for 1.abs()? Math has abs(int i) and abs(double d). Are you proposing putting all of the methods that are in Math into the corresponding wrapper classes? If not, then why not leave it with this simpler approach? | |
| Nov 4, 2015 at 8:27 | comment | added | Ben Aaronson | @DStanley So why not have the int cast to a double then call the double's instance method? There's no difference under the hood between implicitly and explicitly casting | |
| Nov 4, 2015 at 3:37 | comment | added | R.. GitHub STOP HELPING ICE | "The implementation is the same regardless of the underlying numeric type" is utter nonsense. Implementations of the square root function need to differ significantly based on the type they're working with in order not to be horribly inefficient. | |
| Nov 3, 2015 at 21:52 | comment | added | BlueRaja - Danny Pflughoeft | -1 this answer is absurd, what does any of this have to do with being static? You're going going to have decide answers to those same questions either way (and "[with a static function] the implementation is the same" is false, or at least no more true than it would be for instance methods..) | |
| Nov 3, 2015 at 21:36 | comment | added | Giorgio | @DStanley: Are you referring to a particular programming language? Java? C#? Some languages are full of pure methods (methods that do not change the instance they are invoked on) that do not follow this convention. Take e.g. Scala. Often these methods are not getters that access a property, but build some new value without mutating their object. As an example, consider the method List.map in Scala. | |
| Nov 3, 2015 at 21:25 | comment | added | D Stanley | @Giorgio It's not required, but such methods typically include Get in their name to indicate that the result is returned rather than mutating the instance. It's a guideline, not a hard rule, and I grant you that there are exceptions (Count(), Substring(), etc.). | |
| Nov 3, 2015 at 21:20 | comment | added | Giorgio | "Because it does not affect a particular instance (it takes in one value and returns a result)": A method need not affect an instance: it can also compute a value based on the object it is invoked on and return a new value as the result. | |
| Nov 3, 2015 at 21:03 | comment | added | Robert Harvey | Very nice explanation. | |
| Nov 3, 2015 at 19:10 | comment | added | D Stanley | @BenAaronson In C# at least, there is only one static method, and inputs are implicitly converted to double (if possible). So you can have one implementation that is applicable to all compatible types. If it were an instance method (and there was no common base type to all numeric types), you'd have to have multiple implementations (or farm it out to a common method outside of the numeric type(s)). | |
| Nov 3, 2015 at 17:03 | comment | added | Ben Aaronson | I'm not really clear from this answer how the static class helps with your main reason. If you have double Sqrt(int) and double Sqrt(double) on your Math class, you have two options: convert the int to a double, then call into the double version, or copy and paste the method with appropriate changes (if any). But those are exactly the same options you described for the instance version. Your other reasoning (particularly your third bullet point) I agree with more. | |
| Nov 3, 2015 at 15:00 | comment | added | user40980 | @DStanley I'm very much a proponent of the static approach. Just noting that Ruby (an accessible language for many that has a significant smalltalk influence) goes the way of everything is an object. If you really want to have fun, start playing with the open class nature of ruby and redefine the methods on specific instances of the Fixnum class and see how much you can break. | |
| Nov 3, 2015 at 14:58 | comment | added | D Stanley | @MichaelT I get that it can be an instance method. But in my opinion it makes more sense to be a shared library ("static" in the OP's context) method. The int class is not dependent on it, and it would have to be replicated to all numeric types (or routed back to a shared method, which get us back where we started). | |
| Nov 3, 2015 at 14:55 | comment | added | user40980 | @DStanley Ruby is one such language where the numeric type (including the literal) is an object that can be invoked. 1.div(1) is valid in Ruby (returns 1) and 1.to_s is also valid (returns "1"). It gets more fun with floating point though. 1.fdiv(1.1) returns 0.9090... and 1.1.fdiv(1) returns 1.1... however, 1.1.to_s is a parse error. Joys. | |
| Nov 3, 2015 at 14:55 | comment | added | Residuum | @DStanley 1.1.ToString() is legal in C#. | |
| Nov 3, 2015 at 14:50 | comment | added | D Stanley | @MichaelT Nice example. It took me four reads to understand what 1.1.Sqrt represented. Clever. | |
| Nov 3, 2015 at 14:48 | history | edited | D Stanley | CC BY-SA 3.0 | added 338 characters in body |
| Nov 3, 2015 at 14:47 | comment | added | user40980 | Not to mention the joys of 1.sqrt() vs 1.1.sqrt() (ghads, that looks ugly) do they have a common base class? What is the contract for its sqrt() method? | |
| Nov 3, 2015 at 14:44 | comment | added | D Stanley | @risingDarkness Sure, that's one possibility. | |
| Nov 3, 2015 at 14:43 | comment | added | risingDarkness | en.wikipedia.org/wiki/Integer_square_root how about this for int? | |
| Nov 3, 2015 at 14:41 | history | answered | D Stanley | CC BY-SA 3.0 |