2015-12-22 2 views
7

Я узнал, что читатель Clojure интерпретирует десятичный литерал с суффиксом «M», как 1.23M, как BigDecimal. И я также знаю, что десятичные числа без «М» становятся Java-двойными.
Но я думаю, что было бы лучше, чтобы нормальное десятичное число было BigDecimal, а зависящее от узла десятичное число имеет суффикс, например 1.23H. Поэтому, когда число повреждено или усечено из-за предел точности IEEE double, мы можем легко заметить, что число ограничено точностью. Кроме того, я думаю, что простое выражение должно быть независимым от хоста.

Есть ли причина, по которой Clojure интерпретирует буквальную десятичную дробь как Java double, отличную от времени? Кроме того, я не думаю, что производительность по времени - это ответ, потому что это не C/C++, а другой способ объявить зависящую от узла десятичную дробь можно реализовать так же, как «1.23H».Есть ли причина, по которой десятичный литерал по умолчанию не является BigDecimal в Clojure?

ответ

10

Когда-нибудь, для целых чисел, Clojure автоматически увеличит размеры при необходимости. Это было изменено так, что исключаются исключения переполнения. Мой смысл, издалека, состоял в том, что:

  1. Власти, которые предназначены для Clojure, являются практическим языком, занимающимся практическими делами в практическом количестве времени. Они не хотели, чтобы производительность взорвалась, потому что числовые операции неожиданно использовали произвольные библиотеки точности вместо целых операций ЦП. Контраст к схеме, которая, по-видимому, определяет приоритетность математической чистоты по сравнению с практичностью.
  2. Людям не нравилось быть удивленным во время выполнения, когда вызовы между операторами не удались, потому что в библиотеке Java ожидалось 32-битное целое, а не произвольное целое число.

Таким образом, был решен, что по умолчанию, чтобы использовать обычные целые числа (я думаю, что Java лонги?) И использовать только произвольно большие целые числа, когда программист назвал его, когда программист сознательно решил, что они были готовы принять производительность и межоперационный удар.

My guess - это аналогичные решения, касающиеся чисел с десятичной точкой.

4

Производительность может быть одной вещью. Возможно, clojure.core разработчики могли прослушивать причины.

Я лично считаю, что это не так много крупной сделки не иметь BigDecimal по умолчанию, так как:

  • есть буквальный для того, как вы отмечаете: M
  • есть такие операции, как +' , *', -' ... (обратите внимание на цитату), которые «поддерживают произвольную точность».
+0

Я заметил, что clojure автоматически продвигает BigInt с '* ''. Однако, когда я набрал '(* '1e200 1e200)' и '(*' 1e-200 1e-200)', repl просто говорит 'Infinity' и' 0.0'. Почему эти функции автоматического продвижения не поддерживают двойной тип? – burrownn

Смежные вопросы