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, 14 Sep 2014 20:24:23 +0200

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

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