Closed keilw closed 5 years ago
Just to clarify: Any implementation of our NumberSystem
interface can by design only support a closed set of concrete Number types. If users intend to use different or additional Number types, they also need to provide their own implementation of NumberSystem
and configure Indryia to use it (by setting the static Calculus.NUMBER_SYSTEM
field).
... this might be inconvenient for some use-cases, but still I'd rather have a reference implementation that does the arithmetic right (and fails early), than using a fallback which might involve precision loss, only to play nice with other libraries.
However, we could provide a second NumberSystem
implementation, that does not throw these Exceptions, just to give users the option. But I would not recommend it, because I have a feeling it jeopardizes the purpose of this RI.
Can they do that without further extending e.g. NumberQuantity
?
Yes, at least that's the intent.
It seems to do this only via a static member variable in Calculus, I probably would move this to the Indriya SPI similar to DimensionalModel Most people won't have to replace the DimensionalModel
, but they could, and at the very least they should also be able to extend the NumberSystem
.
Fine with me!
DefaultNumberSystem currently throws an IllegalArgumentException outside a small selection of Number subtypes, primarily those inside the JDK.
That is not a reasonable behavior, because there are other Number types defined by libraries like Apache Commons Numbers, GNU Math although that even defines
Quantity
andUnit
in a rather weird way (Unit
extendsQuantity
and both extendNumeric
which is aNumber
), but other numeric types likeRealNum
often go beyond what we define here, so it should not be prevented to use another kind ofNumber
.