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 11:50:13 -0300
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

