MathContext.DECIMAL32 vs MathContext.DECIMAL64, какой из них использовать и почему?

Должен ли я использовать MathContext.DECIMAL32 или MathContext.DECIMAL64? Я посмотрел на documentation, но я не мог понять, когда использовать.MathContext.DECIMAL32 vs MathContext.DECIMAL64, какой из них использовать и почему?

Я использую BigDecimal для представления процента, который я хочу применить к сумме денег. Что-то вроде этого:

... 
final MathContext mc = MathContext.DECIMAL32; 
BigDecimal amount = getAmount(args); 
float percent = getPercent().floatValue(); 
BigDecimal percentAsBd = new BigDecimal(percent/100.f, mc).setScale(4, RoundingMode.HALF_UP); 
BigDecimal threshold = amount.multiply(percentAsBd); 
...

Я использую оракул Java 1.8, Ubuntu 14.04, ядро i7 Intel (64bit)

источник

2016-08-31 has981

Любая конкретная причина, вы чувствуете, что вы должны использовать один из них, а не построения MathContext который соответствует вашим требованиям, например округление? –

@PatriciaShanahan Я предполагаю, что меня беспокоит его совместимость с встроенным float java, который, как я полагаю, 32 бит. – has981

Собственный поплавок Java является двоичным, а не десятичным, и гораздо менее подходит, чем BigDecimal для представления процентов. Я не думаю, что его размер имеет значение. –

В зависимости от архитектуры вашей системы, набор инструкций для любой операции типа 64 бита будет разделены через два процессора, если вы не на чипсете x64. С вашим ядром Intel i7 (x64) любые проблемы вокруг этого отрицаются.

Обновлено: 01/09/2016

В соответствии с назначением JVM спецификации для любого 64-разрядного присвоения значений требуется два 32-битных назначения.

public class IdGenerator { 
    private long id; 
    public IdGenerator() { 
    id = 0; 
    } 
    public int getNextId() { 
    ++value; 
    } 
}

Исходя из этого предположения, вышеуказанный вызов getNextId не является атомарным. Если этот класс используется в контексте с несколькими потоками, результат getNextId() может быть не совсем точным, например. эти вызовы могут приводить к следующим идентификаторам 0,1,3,5,6,7,8,10. Вы не получите такого поведения с 32-разрядным типом на платформе x86.

Update 5/9/2016

Надеюсь, следующая ссылка поможет с моим ответом

http://preshing.com/20130618/atomic-vs-non-atomic-operations/

источник

2016-08-31 11:44:59

А? Честно говоря, я думаю, что сейчас понял, но что вы имеете в виду? Не могли бы вы привести пример? Какой «набор инструкций будет разделен на два процессора»? Вы имеете в виду, что, скажем, в 32-битных системах есть два процессора, у которых разные, но дополнительные наборы инструкций? –

Я тоже смущен. Существует реальная проблема 64-разрядных нагрузок, реализуемых как две 32-разрядные нагрузки для процессоров, не имеющих 64-разрядных операций с памятью. Насколько я знаю, это не имеет никакого отношения к разделению набора команд между процессорами. –

@PatriciaShanahan: ISTM, что с «набором инструкций» Джим означает нечто совершенно иное, чем то, что обычно подразумевается с ним. –

MathContext.DECIMAL32 vs MathContext.DECIMAL64, какой из них использовать и почему?

ответ

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