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