Альтернатива классу Math для поплавков

В использовании оберток не должно быть проблем с производительностью.

Производительность может быть немного меньше из-за вызова этих функций (они статически отправляются, как и любые утилиты).

Если вы используете обертки в горячем коде, вы можете их встроить:

 inline fun sqrt(x: Float) = Math.sqrt(x.toDouble()).toFloat() 

Для встроенных функций байтовый код не отличается от того, который генерирует Java.

Я думаю, что нет проблемы с использованием класса Math . В более ранних версиях Android существовал класс android.util.FloatMath, который обрабатывает арифметику float, но общий класс Math выполняется быстрее, и класс устарел.

Исторически эти методы были быстрее, чем эквивалентные двойные математические методы. В версиях Android с JIT они стали медленнее и с тех пор были повторно реализованы для переноса вызовов в Math. Математика должна использоваться в предпочтении. Все методы были удалены из общедоступного API в версии 23.

http://developer.android.com/reference/android/util/FloatMath.html

Насколько я понимаю, производительность измеряется сложностью алгоритма.
Алгоритм над массивом из n элементов, выполняющий по 1 операции на каждом, называется сложностью O (n).
Такая же сложность алгоритма, выполняющая 3 операции для каждого элемента, по-прежнему равна O (n)
Фиксированная операция, например .toFloat или .toDouble() , не повлияет на производительность, поскольку это сложность O (1).

На самом деле, пытаясь:

 var iniTemp = System.currentTimeMillis() for (i in 1..10000000) sqrt(755.369f) d((System.currentTimeMillis() - iniTemp).toString()) 

407 milisecs

а также:

 var iniTemp = System.currentTimeMillis() for (i in 1..10000000) Math.sqrt(755.369f.toDouble()).toFloat() d((System.currentTimeMillis() - iniTemp).toString()) 

317 милисек

как в более раннем Nexus 7

благодаря