Skip to main content

Re: Just two kind to Quantity in SE-impl

  • From: Werner Keil < >
  • To: " " < >
  • Subject: Re: Just two kind to Quantity in SE-impl
  • Date: Sun, 21 Sep 2014 22:14:42 +0200

While there is a strange behavior by at least the ME 8 SDK and emulator to
newly built JARs (with not obvious reason, except maybe ME 8 should not run
on a Java SE 8 JVM at all?[?]) the RI is still meant to be platform neutral
and portable across ME 8 and SE 7 at the very least.

We might add a Long/long quantity to SE beside BD and Double/double ones.
That if  you leave BigInteger aside would cover most floating  point and
integer numbers.
The RI won't use BigDecimal as of now. There is no need to demonstrate
something with BigDecimal that you cannot show with Double or Long, too.

And see JSRs like 107 it got a "green field" RI after more commercial tools
had already implemented the spec (e.g. EHCache) so the RI does not need to
cover all possible aspects other than implementing the spec/API for a
reasonable set of cases.

Regards,
Werner

On Sun, Sep 21, 2014 at 10:04 PM, Martin Desruisseaux <
>
 wrote:

>  I'm fine with a "reference implementation" using BigDecimal, Long or
> Double. However on my side, an implementation in production environment
> would use the 'double' primitive type. But I think it is good to use
> BigDecimal in the reference implementation (RI) since the purpose of RI is
> to demonstrate what the results should be.
>
> The "Effective Java" book recommendation about 'double' versus 'long'
> accuracy is relevant only when base 10 has a particular meaning. The
> 'double' type is accurate in base 2 but not in base 10; the BigDecimal type
> is accurate in base 10 but not in base 2; the 'long' type is accurate in
> whatever base we choose for the divisor.
>
> Money are usually expressed in base 10, which make BigDecimal a good
> choice for such quantities. But natural quantities have no preferred base;
> the mass of a person is not expressed more accurately in base 10 than in
> base 2, consequently BigDecimal is not a better choice than 'double' for
> natural quantities. AFAIK there is no "natural" integer base.
>
> Nevertheless, many unit conversion factors are defined in base 10. For
> example the conversion factor from inches to centimeters is exactly 2.54 by
> definition. For this reason, BigDecimal make sense for a JSR-363 reference
> implementation, but not necessarily for use in production (especially for
> applications in natural sciences).
>
>     Martin
>
>
> Le 15/09/14 03:57, Otávio Gonçalves de Santana a écrit :
>
>  Werner with Number in parameter in the factory, so:
> AbstractyQuantity.of(Number number, Unit<Q> unit)
>
>  We will suport all kinds in of types used in Java, this way:
>
>    - AtomicInteger
>     - AtomicLong
>     - BigDecimal
>     - BigInteger
>     - Byte
>     - Double
>     - DoubleAccumulator
>     - DoubleAdder
>     - Float
>     - Integer
>     - Long
>     - LongAccumulator
>     - LongAdder
>     - Short
>
>
>  But internally, I would work with just two kinds:
>
>
>    1. BigDecimal
>     2. Long as Fastmoney or Double
>
>
>

Attachment: 35F.gif
Description: GIF image



Re: Just two kind to Quantity in SE-impl

(continued)

Re: Just two kind to Quantity in SE-impl

Werner Keil 09/14/2014

Re: Just two kind to Quantity in SE-impl

Otávio Gonçalves de Santana 09/14/2014

Re: Just two kind to Quantity in SE-impl

Werner Keil 09/14/2014

Re: Just two kind to Quantity in SE-impl

Werner Keil 09/14/2014

Re: Just two kind to Quantity in SE-impl

Otávio Gonçalves de Santana 09/15/2014

Re: Just two kind to Quantity in SE-impl

Otávio Gonçalves de Santana 09/15/2014

Re: Just two kind to Quantity in SE-impl

Werner Keil 09/15/2014

Re: Just two kind to Quantity in SE-impl

Otávio Gonçalves de Santana 09/15/2014

Re: Just two kind to Quantity in SE-impl

Werner Keil 09/16/2014

Re: Just two kind to Quantity in SE-impl

Martin Desruisseaux 09/21/2014

Re: Just two kind to Quantity in SE-impl

Werner Keil 09/21/2014
 
 
Close
loading
Please Confirm
Close