0

I have been working with kotlin for little over 2 years now.

Looking over what I learned in these 2 years, I noticed that I have been using(num.toDouble()).toLong() for kotlin.math functions a bit too much. For example, Math.sqrt(num.toDouble()).toLong(). Two of my projects have extension function sumByLong() inside util created by team, because kotlin libs only have sumBy:Int and sumByDouble:Double and a lot of work in the project, uses Long.

In short, Mathematical operations using Long is more common than using Double or Float, yet Long has a very small footprint in kotlin standard library. And since kotlin.math is different than java.lang.Math, mixed usage is not a recommended practice.

Going over docs of kotlin.math, all functions except for abs, min, max, only have implementation for Float and Double only.

Can someone Explain like I am 5 the possible reasoning behind this. Something real, not silly stuff like devs were lazy, or more code means more work, which is all I could find in search engine results.

--

Update: Some Clarification

1. I can understand that in most cases, return types will contain floating point numbers. I am also talking about parameters lacking long counterpart. Maybe using Math.sqrt wasn't the best example, something like math.log, math.cos, etc would be better example, where floating return type us expected, but parameters doesn't even support Int

2. When I said "Long is more common than using Double", I was not talking about public at large, but was looking over my past two years working with kotlin. I am sorry if my phrasing wasn't clear.

Abhinav Kulshreshtha
  • 2,147
  • 1
  • 23
  • 38
  • 1
    `sumBy` is deprecated. The newer `sumOf` has more overloads available. As for the math functions, many of those produce results that cannot be accurately represented using integer types. – Michael Jul 05 '22 at 14:44
  • 2
    The first example — `Math.sqrt()` — doesn't seem a very good one, since in most cases the result won't be an integer even if the input is. (Only for perfect squares, of course. The caller has the choice of discarding the fractional part, as you do — but you wouldn't want the library to enforce that.) – gidds Jul 05 '22 at 14:44
  • For which functions listed on https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.math/ would you expect an integer version (regarding the argument, not the return value)? – lukas.j Jul 05 '22 at 14:58
  • 2
    *"Mathematical operations using Long is more common than using Double or Float"* -- absolutely untrue. It is exceptionally rare to need an integer result for square roots, sines, logarithms, etc, so it doesn't make sense to include overloads with integer results for those functions in the standard library and bloat it. Perhaps in your specific project type, it makes sense, but then that project is an outlier, and you can create your own overloads. – Tenfour04 Jul 05 '22 at 16:28
  • 1
    @Tenfour04 I would think a common use of integer sqrt is when checking if a number is prime (you only need to check up to sqrt(n)) and a common use for integer trig functions is in games and simulators, where the result needs to be a screen coordinate. But I agree these use cases are nowhere near as common as those requiring Double. – k314159 Jul 05 '22 at 16:45
  • @gidds Maybe I should have used [Math.ceil](https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.math/ceil.html) as example. Also I am not just talking about return types, in most these functions, even arguments are only double or float. I can understand return types may need floating points for accuracy. – Abhinav Kulshreshtha Jul 06 '22 at 07:36
  • @Tenfour04, I was not talking about general public, I am sorry if it read in any different way. I was talking about my own usage in past 2 years working in kotlin. The number of times I have to use toDouble.toLong combo is surprisingly high. – Abhinav Kulshreshtha Jul 06 '22 at 07:40
  • @Michael Our team has started using sumOf for newer code, but older code will take time to phase out. I am not just talking about result, but mostly about parameters or arguments of the functions. – Abhinav Kulshreshtha Jul 06 '22 at 07:55

2 Answers2

3

Disclaimer: this answer may be a little opinionated, but I believe it is according to general consensus and best practices of using maths in computer science.

Mathematics for integers and for real numbers (floats) are really two much different math "sub-worlds". They're pretty separate, they have different uses and we usually don't mix them.

If we work on some physics, we do real-world simulations, we operate on units like temperature or speed, we use doubles. If we have identifiers (bank account number), we count something (number of bank accounts) or we operate on a discrete values with 100% precision (bank account value) we always use integers and never doubles.

Operations like sinus, square root or logarithm make perfect sense for physics, but not really for bank account values. They very often produce either very small or very large numbers that can't be safely represented as integers. They operate on approximations and don't really provide 100% precise results. They are continuous by nature while integers are discrete.

What is the point of using integers with sqrt() or log() if they almost always return a floating point result? What is the point of passing an integer to sin() if e.g. there are only 2 distinct angles smaller than square angle that can be represented as an integer: 0 and 1? Using integers with these functions is unnatural and impractical.

I can't think of a case where we have to often convert between longs and doubles. Usually, we operate either on longs or on doubles top to bottom and we don't convert between them too often. By converting we lose advantages of these specific "math sub-worlds", we sum their disadvantages. Maybe you should just keep using doubles in your application and don't convert to/from longs? Why do you use longs?

BTW, you mentioned that you can't/shouldn't use java.lang.Math in the Kotlin application. Well, if you look into java.lang.Math you will notice that... it supports only doubles :-)

broot
  • 21,588
  • 3
  • 30
  • 35
2

In the case of ceil, it returns a Double because a Double has a bigger range of values than Long. Consider, for example:

ceil(Long.MAX_VALUE.toDouble() * 1000)

What would you expect it to return if it returned a Long? For further discussion, see Why does Math.ceil return a double?

In the case of log and trigonometric functions, the use cases requiring Long parameters are rare and the requirements varied. For example, should it round up, down, or to the nearest integral value? These are decisions that should be made for your particular project, and therefore can't be made in the stdlib.

In your project, you can simply define your required functions in a single, small source file, making your project's choice of rounding method, and then use it everywhere instead of converting at each call site, e.g.:

fun cos(n: Long): Long = cos(x.toDouble()).roundToLong()
k314159
  • 5,051
  • 10
  • 32