Skip to main content

Re: Just two kind to Quantity in SE-impl

  • From: Otávio Gonçalves de Santana < >
  • To:
  • Subject: Re: Just two kind to Quantity in SE-impl
  • Date: Sun, 14 Sep 2014 22:57:26 -0300

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



On Sun, Sep 14, 2014 at 6:12 PM, Werner Keil 
< >
 wrote:

> Actually I would support all types, that Java SE 8 got *Supplier and all
> sorts of other functional interfaces for.
>
>    - Double
>    - Int
>    - Long
>
> Aside from a general "Object" which in case of SE only would be BigDecimal
> (and if required for large integer numbers BigInteger?)
>
> If Float is not highly regarded there, we could also leave it, but the
> others should be supported.
>
> On Sun, Sep 14, 2014 at 8:24 PM, Werner Keil 
> < >
> wrote:
>
>> Well speed is also a reason why FastMoney was created in the first place.
>> BigDecimal is very slow and bulky (like some other "newer" addditions to
>> Java SE[?]) why else would Moneta even bother with a second one?
>>
>> Like I said, lost precision and a "+/-0.5" or similar ratio is what you
>> got in JScience. If we left that to implementations, it would still be
>> possible to do it e.g. by a more sophisticated one like JScience.next,
>> otherwise it is also something for the RI/SE port.
>>
>> The Measurement type points to this:
>http://en.wikipedia.org/wiki/Measurement
>>
>> "uncertainty" is something we have not yet modeled in the API, guess we
>> have to take that into consideration, this is not Money or some other API
>> but a Measurement one.
>>
>> In fact, even some countries like in Scandinavia (Denmark, Norway, etc.)
>> have an uncertainty when you pay. They "drop" some Öre in cash, let's say a
>> price was 19.99 Kr. you may not get any change if you give them a 20 Kr.
>> the 1 ör is dropped and uncertainty, too[?]
>>
>> On Sun, Sep 14, 2014 at 4:50 PM, Otávio Gonçalves de Santana <
>>
>>  wrote:
>>
>>> We need to consider the different focus between these platforms.
>>> For example, I am working to create some Stream functions in SE platform:
>>> This code below[1], will run an exception (the class cast exception). To
>>> no lost the precision I need use the number that has more precision,
>>> considering the SE plataform, that will almost always the Bigdecimal.
>>> In SE plataform in general this API will used to calculate bigger
>>> number, maybe with map reducer, and power computer is not the problem, 
>>> once
>>> there are server dedicated to run a process. The slightly possibility to
>>> lost a number will a problem.
>>>
>>> [1]
>>>    @Test
>>>     public void convertTest() {
>>>
>>>         List<Quantity<Length>>  lenghts = getMeasures();
>>>         Quantity<Length> quantity = lenghts.stream().map(m -> 
>>> m.to(US.FOOT)).reduce((m1,
>>> m2) -> m1.add(m2)).get();
>>>         System.out.println(quantity);
>>>     }
>>>
>>>     private List<Quantity<Length>> getMeasures() {
>>>         return Arrays.asList(AbstractQuantity.of(10, SI.METRE),
>>> AbstractQuantity.of(10, US.FOOT), AbstractQuantity.of(10, SI.METRE));
>>>     }
>>>
>>> On Sun, Sep 14, 2014 at 8:30 AM, Werner Keil 
>>> < >
>>> wrote:
>>>
>>>> A vast majority of real life measurement use cases use primitives like
>>>> "double" and while Money has some challenges about rounding, there is
>>>> always a sense of precision loss measurements may afford or not. Keep in
>>>> mind, JavaFX is based almost entirely on Float, too, whether this guy who
>>>> wrote the famous book or not was involved I can't say.
>>>>
>>>> He also recommended in his book to use only 2 types of static factory
>>>> methods, either
>>>>
>>>>    - valueOf() or
>>>>    - getInstance()
>>>>
>>>> Nevertheless, the EnumSet written by the same guy in Java 5 broke that
>>>> naming convention by introducing a shorter of() which many parts of Java 
>>>> 8
>>>> seem to prefer, despite what his book said[?]
>>>>
>>>> The RI must be able to handle primitives like *double*, *long *and
>>>> others. Whether or not float is redundant, that probably matters less, I
>>>> don't know too many actual systems like Strava, Fitbit or scientific
>>>> equivalents using it, but they all require double, some use int or long.
>>>>
>>>> Almost every wrapper is currently invisible to users anyway, so it
>>>> matters less how many there are. JSR 354 offers those 2 implementations
>>>> both compatible with each other (unlike e.g. JodaMoney[?]) in the JSR
>>>> 363 RI (and SE port) they help the QuantityFactory or whatever we end up
>>>> calling it on an API level. So except for a BaseQuantity for concrete
>>>> sub-classes which uses Double in the RI and BigDecimal in the SE impl all
>>>> other types are mererly helpers for the factory.
>>>>
>>>> Having concrete classes in some cases seems hard to avoid, e.g. someone
>>>> asked me in Trondheim, how a Length class would know that Length * Length
>>>> becomes Area?
>>>>
>>>> What JScience did here was an Amount class:
>>>> http://www.jscience.org/api/org/jscience/physics/amount/Amount.html
>>>> With an isExact() method, which we probably want to think about. Again,
>>>> sensor readings and measurements may have a certain treshold, just like 
>>>> we
>>>> were asked to keep a course on the JavaZone ship ride that is just about 
>>>> to
>>>> finish. As long as it's within a margin, that is still OK for measuring,
>>>> while Money often requires a larger precision.
>>>>
>>>> Regards,
>>>> Werner
>>>>
>>>> On Sun, Sep 14, 2014 at 1:01 PM, Otávio Gonçalves de Santana <
>>>>  >
>>>>  wrote:
>>>>
>>>>> In Java SE world, there is a warning about calculates with floating
>>>>> numbers, following some approach and advices in books and blogs, was
>>>>> included the most famous book about Java in the world, the Java
>>>>> Effective
>>>>> <http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683>.
>>>>> When you want calculate something that you really need high precision, 
>>>>> such
>>>>> a money, you may use two ways:
>>>>>
>>>>>
>>>>>    - using BigDecimal
>>>>>    - using integer values
>>>>>
>>>>> It will facilitate the maintenance code, considering we have just two
>>>>> kinds, and get performance to do parse and less the error with parser, 
>>>>> when
>>>>> we are using stream:
>>>>>
>>>>>
>>>>> List<Quantity<Length>> lenghts = getMeasures();
>>>>>
>>>>> Quantity<Length> quantity = lenghts.stream().map(m -> 
>>>>> m.to(US.FOOT)).reduce((m1,
>>>>> m2) -> m1.add(m2)).get();
>>>>>
>>>>> System.out.println(quantity);
>>>>>
>>>>>
>>>>> In money we are doing following this concern:
>>>>>
>>>>>
>>>>> https://github.com/JavaMoney/jsr354-ri/blob/master/src/main/java/org/javamoney/moneta/FastMoney.java
>>>>>
>>>>>
>>>>> https://github.com/JavaMoney/jsr354-ri/blob/master/src/main/java/org/javamoney/moneta/Money.java
>>>>>
>>>>> I believe this case will be the same since both deal with important
>>>>> floating calculations
>>>>>
>>>>> obs: I am just talking about SE implementations
>>>>>
>>>>>
>>>>> --
>>>>> Otávio Gonçalves de Santana
>>>>>
>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>> twitter: http://twitter.com/otaviojava
>>>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>>>> 55 (11) 98255-3513
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Otávio Gonçalves de Santana
>>>
>>> blog:     http://otaviosantana.blogspot.com.br/
>>> twitter: http://twitter.com/otaviojava
>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>> 55 (11) 98255-3513
>>>
>>>
>>
>


-- 
Otávio Gonçalves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
55 (11) 98255-3513

GIF image

GIF image



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

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