Skip to main content

[JScience-Dev] Re: unitsofmeasurement/jscience/uomo

  • From: Kajetan Fuchsberger <Kajetan.Fuchsberger@...>
  • To: "DAUTELLE, Jean-Marie" <jean-marie.dautelle@...>, "werner.keil@..." <werner.keil@...>, "jean-marie@..." <jean-marie@...>
  • Cc: Jean-Christophe Garnier <Jean-Christophe.Garnier@...>, "Arkadiusz Gorzawski" <Arkadiusz.Gorzawski@...>, "dev@..." <dev@...>, "users@..." <users@...>
  • Subject: [JScience-Dev] Re: unitsofmeasurement/jscience/uomo
  • Date: Mon, 6 Jan 2014 16:38:10 +0000
  • Accept-language: en-GB, en-US

Hi Jean-Marie,

Thanks a lot for this very quick response! Indeed, everything you write is 
very encouraging! Yes, definitely we will wait for the next jscience release. 
We put an abstraction in place for the moment, to not be too much dependent 
on either of the implementations.

Currently, we are working on a more generic framework, which deals with 
tensor structures of arbitrary dimensions together with some other features, 
with the focus on ease of use. Nevertheless, we definitely do not want to 
re-invent the unit/amount part  ;-)

We also hope to have a first version out in a few weeks, which then also will 
be open source. Any comments and synergies will be also very welcome then.

Thanks again and looking forward for the new jscience release ;-)

Have a nice evening

Kajetan

________________________________________
From: DAUTELLE, Jean-Marie [jean-marie.dautelle@...]
Sent: 06 January 2014 17:24
To: Kajetan Fuchsberger; werner.keil@...; jean-marie@...
Cc: Jean-Christophe Garnier; Arkadiusz Gorzawski; dev@...; users@...
Subject: RE: unitsofmeasurement/jscience/uomo

Hi Kajetan,

1) I realized that jscience does not yet implement the unitsofmeasurement API 
in the current version and I did not find a jar of the 5.0 version anywhere. 
Are there any plans to continue this development?

Yes we are currently working on JScience 5.0. It will fully support 
org.unitsofmeasurement and extra bonuses such as Amount, Vector/Matrices, GPU 
acceleration (from Javolution 6.1) etc.
Expect a draft release in 2 weeks.

2) I also tried uomo, and got a bit stuck: Why is uomo an eclipse plugin? 
What is the advantage compared to use it just as a library? I tried to use it 
just as a library but got into some problems (I can detail them, if you want)

Werner should be able to help you with this.

3) To summarize: What is in your opinion the most active/promising project 
into this direction? We are also willing to contribute, if necessary, but 
before doing so, I would like to get a better understanding...

JScience is a more general purpose library (with math, physics, and economics 
modules). As soon as the 5.0 draft is out, we will be looking for serious 
contributions and support from users :)

4) I also have two design concerns:

a) I really like the compile time checking of the quantities, and we 
successfully use it e.g. in our embedded DSL. Nevertheless, it gives a lot of 
problems and might be an overkill in certain cases. Two of the reasons are:
* It is never possible to generalize this (e.g. arbitrary derivatives of 
functions of nth order...)
* It is a bit contradicting e.g. to a Mathematical Field: If you consider a 
quantity as a Field element, then the type of the elements change e.g. during 
multiplication... which is confusing (as far as I see it) To solve this, one 
proposal could be to have an interface Unit, which it not generically typed. 
An Amount using this unit, would not provide the compile time checking, but 
could still consistently handle the tracking of units during mathematical 
operations. Runtime exceptions would have to take over the role of the 
current compile time checks.

This question is more related to JScience. The Amount class is indeed a field 
but a field of type: Field<Amount<?>>. Indeed the amount product is still an 
amount even if the quantity type is different. It should be noted that 
JScience 5.0 keeps that idea but for performance purpose, AmountVector may 
hold a single unit for all vector elements (e.g. velocity vector) to reduce 
the number of runtime check to perform.
See (from current SVN 5.0): 
https://java.net/projects/jscience/sources/svn/content/trunk/jscience/mathematics/src/main/java/org/jscience/mathematics/linear/Vector.java?rev=695
https://java.net/projects/jscience/sources/svn/content/trunk/jscience/mathematics/src/main/java/org/jscience/mathematics/linear/Matrix.java?rev=695


b) In uomo I saw that there is a parallel hierarchy of quantities and 
Amounts... this looks a bit tedious to extend. I gave it a quick try to 
accomplish the same compile time and runtime behaviour, by using a factory 
class in combination with dynamic proxies for the amounts ...
I believe, this looks promising... So if you want, I could refine this and 
contribute ...

In JScience 5.0, Amount is the interface: Amount<F extends Field, Q extends 
Quantity>
In other words you can have Amount<Float64, Meter>, Amount<Complex, Current>, 
Amount<Decimal, Mass>, etc.
Factory methods (in Amounts class) are used to return the proper 
implementation (see Vector.java source code above).

I hope all of this will encourage you to wait for the next JScience release, 
very soon now...

Best regards,
Jean-Marie Dautelle (JScience Project Owner)

-----Message d'origine-----
De : Kajetan Fuchsberger [mailto:kajetan.fuchsberger@...]
Envoyé : lundi 6 janvier 2014 14:35
À : werner.keil@...; jean-marie@...
Cc : Jean-Christophe Garnier; Arkadiusz Gorzawski
Objet : unitsofmeasurement/jscience/uomo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Werner, Jean-Marie,

We were searching for a way to consistently handle units quantities in some 
of our projects (internally and open source). First we came across jscience 
and basically it was doing what we wanted and so we were giving it a try. 
Very nice library! Thanks a lot!

Nevertheles, now that I was a little bit more investigating in the topic I 
got a bit confused in the end, therefore, I wanted to ask you some questions:

1) I realized that jscience does not yet implement the unitsofmeasurement API 
in the current version and I did not find a jar of the 5.0 version anywhere. 
Are there any plans to continue this development?

2) I also tried uomo, and got a bit stuck: Why is uomo an eclipse plugin? 
What is the advantage compared to use it just as a library? I tried to use it 
just as a library but got into some problems (I can detail them, if you want)

3) To summarize: What is in your opinion the most active/promising project 
into this direction? We are also willing to contribute, if necessary, but 
before doing so, I would like to get a better understanding...

4) I also have two design concerns:

a) I really like the compile time checking of the quantities, and we 
successfully use it e.g. in our embedded DSL. Nevertheless, it gives a lot of 
problems and might be an overkill in certain cases. Two of the reasons are:
* It is never possible to generalize this (e.g. arbitrary derivatives of 
functions of nth order...)
* It is a bit contradicting e.g. to a Mathematical Field: If you consider a 
quantity as a Field element, then the type of the elements change e.g. during 
multiplication... which is confusing (as far as I see it) To solve this, one 
proposal could be to have an interface Unit, which it not generically typed. 
An Amount using this unit, would not provide the compile time checking, but 
could still consistently handle the tracking of units during mathematical 
operations. Runtime exceptions would have to take over the role of the 
current compile time checks.

b) In uomo I saw that there is a parallel hierarchy of quantities and 
Amounts... this looks a bit tedious to extend. I gave it a quick try to 
accomplish the same compile time and runtime behaviour, by using a factory 
class in combination with dynamic proxies for the amounts ...
I believe, this looks promising... So if you want, I could refine this and 
contribute ...

Many thanks in advance for all your help

Kajetan Fuchsberger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSyrDyAAoJECN/qH7pU3M2pdcIAK3jOSsISwrX0Q7W1xKJ3Wfz
QJm1d3kau+bafcHrbsS6hZJZJ28OrwsVF18uzBe+w6iBErUBMC3GztKoozje+zdn
Q5l+Up9/9v5HjglNIthpGGc7wRiVRPKBsAub/aAE/hfwV+cXx2+nuvOZv2yTS5O9
Wccp4412lhcX3F8o/CQgLyePVB1lMJIWAUgUSl9tYMId5NwSR0/irVmii8n7ddsU
PTGGtQxeGopesrTP0xXSOjEjBpENvtNsydmo3Er81eYeRxEukWp9CZK3mlOMj3mi
u7IfgwIyFbFN8WI0aLY+DsizfTj7CZZgAhhYSiQ8dVIWSv+LQ6HacAzgDzpxnFE=
=0ekz
-----END PGP SIGNATURE-----

This mail has originated outside your organization, either from an external 
partner or the Global Internet.
Keep this in mind if you answer this message.



The information in this e-mail is confidential. The contents may not be 
disclosed or used by anyone other than the addressee. Access to this e-mail 
by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and 
delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of 
this e-mail as it has been sent over public networks. If you have any 
concerns over the content of this message or its Accuracy or Integrity, 
please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus 
scanning software but you should take whatever measures you deem to be 
appropriate to ensure that this message and any attachments are virus free.



[JScience-Dev] Re: unitsofmeasurement/jscience/uomo

Kajetan Fuchsberger 01/06/2014
 
 
Close
loading
Please Confirm
Close