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: Tue, 16 Sep 2014 02:06:51 +0200

We could need at least one backed by double or long and one using Number.
ICU4J works perfectly find with Number, no precision loss, it's used by
Google Finance and many other applications[?]

Another reason why common aspects are handled by an abstract base class,
see AbstractMap with so different concrete classes as HashMap or TreeMap.


On Tue, Sep 16, 2014 at 1:00 AM, Otávio Gonçalves de Santana <
>
 wrote:

>
> But how we can do the arithmetic operations? If I have a quantity with
> Long a cannot sum or divide with Double? Or lost precision to cast with
> Long? FastMoney was just an example, the focus is: we don't need to much
> quantities kinds. Just one or two, because the client api doesn't need know
> how the implementation manipulates the numbers.
>  Actually where you pass Number to of() it shall be stored as Number[?]
> It's not only about the example types you mentioned, especially scientific
> apps tend to use other specialized numeric types. And that works fine for
> ICU4J, too.
> Thus the question is, how about non-Number alternatives, similar to
> FastMoney.
>
> Keep in mind, it stores
>     /**
>      * The numeric part of this amount.
>      */
>     private final *long* number;
>
>  a long primitive, not the Long object.
>
> I see Amount if we ended up picking the name as replacement for
> BaseQuantity, but a more general AbstractQuantity see Collection API is
> quite logical. It may be relieved of factory methods like of() but I am not
> so sure, if we wanted to make now hidden concrete classes like LongQuantity
> (which is as efficient as FastMoney in JSR 354) visible?
>
> Werner
>
> On Mon, Sep 15, 2014 at 10:18 PM, Otávio Gonçalves de Santana <
>  >
>  wrote:
>
>> 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
>>
>>
>

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: 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