Операция должна попытаться сохранить ответ того же типа, что и исходные входные данные, поэтому, если держатель начал с двойного значения, результат также должен быть двойным.
Если входы содержат держатели разных типов чисел, они должны автоматически расширяться и т. д.
Должен быть один тип держателя с геттерами для возврата результата в виде целого числа, двойного числа, большого десятичного числа, большого целого числа и т. д. с исключениями, возникающими в случае сбоя преобразования.
Код должен выглядеть как Bigdecimal.
Идеально неизменный
Код не должен знать или заботиться о том, что находится внутри держателя, операции просто работают, пока не потребуется преобразование на более позднем этапе.
К сожалению, BigDecimal не совсем подходит для моих нужд, в нем отсутствуют многие ключевые функции, например: синус, журнал и большинство статических помощников по математике.
ApacheCommonsMath
Axelcb предложил использовать математическую библиотеку Apache Commons. Основным классом использования в моем случае, кажется, является DFP.
При изучении DFP нет простого способа передать BigDecimal/BigInteger и построить DFP. Было бы неплохо, если бы точность также была параметром и использовалась бы в процессе всасывания.
ни одна из функций (например, умножение) не принимает контекст с точностью и округлением, как BigDecimal. Я действительно не понимаю причины неуклюжего способа обработки точности и округления.
Что такое DfpField, что именно он делает и зачем нужны поля в DFP??? Пожалуйста, не говорите мне больше об этом календаре.
нет методов экспорта в BigDecimal или BigInteger
ДФП
это оригинальное вдохновение для математического класса DFP apache commons?
первое беспокойство по поводу импорта из BigDecimal или BigInteger отсутствует.
нет методов экспорта в BigDecimal или BigInteger
