BigInteger сравнить с вычитать + signnum ()

Question

BigInteger сравнить с вычитать + signnum ()

1

проблема

Пробовал в моем коде следующую возможную оптимизацию. (Обновление: вычитание происходит медленнее, что имеет смысл, поскольку это более сложная процедура).

Код:

   if (bigK.compareTo(prevLevelChildrenCount) > 0)

в

 if (bigK.subtract(prevLevelChildrenCount).signum() == 1)

Speed (Subtract vs compareTo) при использовании 100 000 000 раз итерационно для случайных чисел.

Вопрос:

Является ли поведение biginteger одинаковым при использовании вычитания как целого в терминах переполнения?

Я нашел следующий вопрос, но считаю, что это не дубликат, потому что biginteger не имеет таких же ограничений, как целое. Но имеет ли он проблему переполнения?

Menelaos Bakopoulos 07 июль 2014, в 06:31

Источник

1

@ Джаррод Роберсон Это для biginteger. Это не совсем дубликат, так как те же ограничения / условия не применяются. Одинаково ли поведение с точки зрения переполнения?
Menelaos Bakopoulos 07 июль 2014, в 04:23
0

Возможно, было бы полезно, если бы вы bigK что bigK и prevLevelChildrenCount - это BigInteger . Когда вы говорите, I am comparing two positive big integers , становится немного сомнительно, говорите ли вы о BigInteger или больших значениях int .
awksp 07 июль 2014, в 04:28
0

Both title , и tag содержат слово BigInteger . Также добавлю в код.
Menelaos Bakopoulos 07 июль 2014, в 04:30
0

Правда ... Просто показывает, насколько слепыми могут быть люди: P Извините.
awksp 07 июль 2014, в 04:34
0

Важно: compareTo не должно возвращать 1, когда левая сторона превышает правую. Нужно только вернуть положительное значение. Поэтому использование == 1 после compareTo - плохая идея.
Dawood ibn Kareem 07 июль 2014, в 05:03
0

@ Дэвид Уоллес, пожалуйста, смотрите мое обновление. В настоящее время у меня есть JDK1.6 Src на этой машине. Если я не устал .. Я вижу -1, 0, 1
Menelaos Bakopoulos 07 июль 2014, в 05:06
0

Вы не должны полагаться на это. Что произойдет, если вам придется перейти на более позднюю версию Java, а поведение будет другим? При использовании любого API вы должны полагаться только на его документированное поведение - и документированное поведение compareTo заключается в том, что он возвращает положительное, 0 или отрицательное в трех случаях, а не то, что он возвращает 1, 0 или -1.
Dawood ibn Kareem 07 июль 2014, в 05:10
0

@David Wallace Javadoc-Official Documentation: Возвращает -1, 0 или 1, так как этот BigInteger численно меньше, равен или больше, чем val. SRC: docs.oracle.com/javase/7/docs/api/java/math/…
Menelaos Bakopoulos 07 июль 2014, в 05:11
0

@ maythesource.com Это неплохая практика для использования > 0 .
Elliott Frisch 07 июль 2014, в 05:12
0

Правда ... они могли бы просто изменить его в другой версии, так как сравнимое значение равно <0 или> 0.
Menelaos Bakopoulos 07 июль 2014, в 05:12
2

Я приношу извинения. Я забираю все это обратно. Поскольку документ для BigInteger делает это заявление, его можно использовать. Я искал документ для Comparable , который отличается. Обратите внимание, что в документе есть абзац для BigInteger который предлагает использовать > 0 или < 0 в любом случае. Независимо от того, что вы сделали, прекрасно.
Dawood ibn Kareem 07 июль 2014, в 05:16
1

«Вычитание работает быстрее» - как вы это проверили? Если у вас нет подходящего ориентира и вы не можете правильно объяснить его результаты, вы делаете преждевременную оптимизацию на основе субъективных наблюдений или предположений.
Oleg Estekhin 07 июль 2014, в 05:58
0

@ Олег Эстехин Спасибо за напоминание. Я профилировал тест, который итеративно вызывал каждый из двух и нашел, что вычитание на самом деле медленнее. Также Эллиот сказал: «Остерегайтесь таких микрооптимизаций, они могут варьироваться в зависимости от платформы, архитектуры и реализации».
Menelaos Bakopoulos 07 июль 2014, в 11:37

Показать ещё 11 комментариев

Теги:

java

biginteger

1 ответ

Ещё вопросы

@ Джаррод Роберсон Это для biginteger. Это не совсем дубликат, так как те же ограничения / условия не применяются. Одинаково ли поведение с точки зрения переполнения?
Возможно, было бы полезно, если бы вы bigK что bigK и prevLevelChildrenCount - это BigInteger . Когда вы говорите, I am comparing two positive big integers , становится немного сомнительно, говорите ли вы о BigInteger или больших значениях int .
Both title , и tag содержат слово BigInteger . Также добавлю в код.
Правда ... Просто показывает, насколько слепыми могут быть люди: P Извините.
Важно: compareTo не должно возвращать 1, когда левая сторона превышает правую. Нужно только вернуть положительное значение. Поэтому использование == 1 после compareTo - плохая идея.
@ Дэвид Уоллес, пожалуйста, смотрите мое обновление. В настоящее время у меня есть JDK1.6 Src на этой машине. Если я не устал .. Я вижу -1, 0, 1
Вы не должны полагаться на это. Что произойдет, если вам придется перейти на более позднюю версию Java, а поведение будет другим? При использовании любого API вы должны полагаться только на его документированное поведение - и документированное поведение compareTo заключается в том, что он возвращает положительное, 0 или отрицательное в трех случаях, а не то, что он возвращает 1, 0 или -1.
@David Wallace Javadoc-Official Documentation: Возвращает -1, 0 или 1, так как этот BigInteger численно меньше, равен или больше, чем val. SRC: docs.oracle.com/javase/7/docs/api/java/math/…
@ maythesource.com Это неплохая практика для использования > 0 .
Правда ... они могли бы просто изменить его в другой версии, так как сравнимое значение равно <0 или> 0.
Я приношу извинения. Я забираю все это обратно. Поскольку документ для BigInteger делает это заявление, его можно использовать. Я искал документ для Comparable , который отличается. Обратите внимание, что в документе есть абзац для BigInteger который предлагает использовать > 0 или < 0 в любом случае. Независимо от того, что вы сделали, прекрасно.
«Вычитание работает быстрее» - как вы это проверили? Если у вас нет подходящего ориентира и вы не можете правильно объяснить его результаты, вы делаете преждевременную оптимизацию на основе субъективных наблюдений или предположений.
@ Олег Эстехин Спасибо за напоминание. Я профилировал тест, который итеративно вызывал каждый из двух и нашел, что вычитание на самом деле медленнее. Также Эллиот сказал: «Остерегайтесь таких микрооптимизаций, они могут варьироваться в зависимости от платформы, архитектуры и реализации».

Elliott Frisch · Accepted Answer · 2014-07-07T03-06-00.000Z

Почему я не должен этого делать? Я сравниваю два положительных больших целых числа?

Я не понимаю, почему вы не должны, убедитесь, что это работает в первую очередь.

Какой из них должен быть быстрее? В моих собственных тестах вычитание работает быстрее.

Я не буду верить, что один быстрее, чем другой. Помните, что микро-оптимизация редко бывает продуктивной.

Является ли поведение biginteger одинаковым при использовании вычитания как целого в терминах переполнения.
Но имеет ли он проблему переполнения?

Нет, BigInteger не будет переполняться. За связанный Javadoc,

Все подробности в Spec относительно переполнения игнорируются, поскольку BigIntegers выполнены в виде больших по мере необходимости для размещения результатов операции.

Так это более эффективно, чем использовать CompareTo? Или это зависит от используемых чисел и какие биты установлены на что?
@ maythesource.com Отредактировано. Остерегайтесь таких микрооптимизаций, они могут варьироваться в зависимости от платформы, архитектуры и реализации. Кроме того, микро-тесты обычно не надежны.
Спасибо за ответ и комментарий. Я вернусь к работе над большими алгоритмическими узкими местами - увлекся.