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: Mon, 15 Sep 2014 17:18:00 -0300

everyone agree?

On Sun, Sep 14, 2014 at 10:57 PM, Otávio Gonçalves de Santana <
>
 wrote:

> 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
>
>


-- 
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