Use Advanced Search to search the entire archive.
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

