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

