Skip to main content

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

  • From: Leonardo Lima < >
  • To: " " < >
  • Subject: [jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)
  • Date: Mon, 20 Apr 2015 10:37:02 -0500

Hello!

I posted on the JIRA issue; I +1 what Jean-Marie said.

Regards,
Leonardo.

On Wed, Apr 8, 2015 at 1:20 PM, Werner Keil 
< >
 wrote:

> Thanks.
>
> Different sources have different names, but most CLDR-provided quantities
>  acceleration  angle  area  digital  consumption  electric  electric
> electric  energy  frequency  light  length  mass  power  pressure
> proportion  temperature  duration  speed  volume
> match
> (proportion and byte/information are not in NIST/SI scope, but we may
> include especially Information for IT purposes)
>
> I'll attach an Excel sheet nist_units to the JIRA ticket. It contains the
> units in "Table 1" and "Table 2" for clarity.
> We'll consider all 20 including the 12 derived ones, unless somebody has
> serious objections. Given Unicode offers a treasure chest of translations
> for free, it may be a good idea to take its 2 or 3 extra quantities beyond
> the 2 NIST tables also, but feel free to suggest alternatives.
>
> The RI will likely not offer a large number of translations, that's more
> for uom-se, since CLDR can get up to several kB or even MB (just look at
> ICU4J)
>
> Cheers,
> Werner
>
> On Wed, Apr 8, 2015 at 7:31 PM, Chris Senior 
> <
> > wrote:
>
>> If we are talking 10 KB or less of overhead in terms of declared classes
>> in the VM - then I vote option 3 too.
>>
>> Can we be explicit (in JIRA?) about the final list of Quantities that
>> would be in the API - I don't understand the references to the links
>> provided?
>>
>> On Wed, 8 Apr 2015 at 15:21 Werner Keil 
>> < >
>>  wrote:
>>
>>> You mean in terms of memory?
>>>
>>> So far the 50 quantities have a footprint of roughly 20kb. So splitting
>>> them in half (option 3) would mean around 10kb instead.
>>> Option 2 more or less 1/4, so say 5k, and option 1 would mean almost no
>>> footprint except the Dimensionless type.
>>>
>>> About the TCK, judging from e.g. what 354 did, we should test, that an
>>> implementation of SystemOfUnits supports a given number of quantity types
>>> via
>>> getUnit(Class<Q> quantityType)
>>>
>>> I am not sure, if we'd force any 3rd party implementation to include
>>> particular quantities, maybe we also just assess, whether or not
>>> getUnits() returns a non-null, non-empty result, or not. That's a good
>>> point for the TCK, but unless we narrow it down to e.g. the 7 SI base
>>> units, I don't think a custom unit system for e.g. Health, Smart Home, 
>>> etc.
>>> should be forced to support a certain number of quantities to pass the 
>>> TCK,
>>> thus there seems less overhead. If we declare say 8 or 20 quantity types,
>>> there could be tests to verify they are used, but e.g. the Quantities
>>> factory class is not part of the API, so a TCK may not have to consider
>>> that one present either.
>>>
>>> Does that help?
>>>
>>> On Wed, Apr 8, 2015 at 3:51 PM, Chris Senior <
>>>  >
>>>  wrote:
>>>
>>>> What is the relative overhead or cost of option 2 vs. option 1; and
>>>> option 3 vs. option 2?
>>>>
>>>>
>>>> On Tue, 7 Apr 2015 at 17:14 Werner Keil 
>>>> < >
>>>>  wrote:
>>>>
>>>>> Jean-Marie/all,
>>>>>
>>>>> Thanks for the quick reply.
>>>>> *si.uom* is not the RI: https://github.com/unitsofmeasurement/si-units
>>>>> On the contrary. It allows to hold everything that won't remain in the 
>>>>> API
>>>>> but is used or "accepted by SI" in an implementation neutral form. 
>>>>> Unless
>>>>> there are concrete classes like "SI" or others these reusable type
>>>>> libraries contain nothing but additional interfaces to be compatible 
>>>>> across
>>>>> all implementations.
>>>>>
>>>>> Cheers,
>>>>> Werner
>>>>>
>>>>>
>>>>> On Tue, Apr 7, 2015 at 5:45 PM, DAUTELLE, Jean-Marie <
>>>>>  >
>>>>>  wrote:
>>>>>
>>>>>>  Hi Werner and All,
>>>>>>
>>>>>> 3.      SI derived quantities (in javax.measure.quantity) +
>>>>>> Dimensionless s. Table 2 (and mostly CLDR, too)
>>>>>>
>>>>>> We should stick with NIST Reference as much as we can. We have the
>>>>>> chance to have an internationally recognized body to work with; let’s 
>>>>>> not
>>>>>> reinvent the wheel.
>>>>>>
>>>>>> Also, these are typically the classes/interfaces which are the most
>>>>>> important in the API (none of them should be in the RI).
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Jean-Marie.
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* Werner Keil 
>>>>>> [mailto: ]
>>>>>> *Sent:* mardi 7 avril 2015 15:27
>>>>>> *To:* 
>>>>>> 
>>>>>> *Subject:* [jsr363-experts] [VOTE] Define quantities to remain in
>>>>>> API (see UOM-100)
>>>>>>
>>>>>>
>>>>>>
>>>>>  Dear Experts,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I hope you had a nice Easter holiday. Aside from brushing JSR 354
>>>>>> (which is heading towards Final pretty soon) I worked on the tools for
>>>>>> analysis and comparison of different unit data sources which also lead 
>>>>>> to
>>>>>> decision making of
>>>>>> https://java.net/jira/browse/UNITSOFMEASUREMENT-100
>>>>>>
>>>>>>
>>>>>>
>>>>>> To get the core API even slimmer and a common understanding of
>>>>>> quantities we would like there if any, I spawned-off a true SI module 
>>>>>> with
>>>>>> a draft of all quantities currently in javax.measure:
>>>>>> https://github.com/unitsofmeasurement/si-units/tree/master/quantity/src/main/java/si/uom/quantity
>>>>>>
>>>>>>
>>>>>>
>>>>>> uom.si is among the domains registered and while many folks and
>>>>>> projects now rush towards their "io" domain (it's also a territorial 
>>>>>> domain
>>>>>> btw. and exists for nearly 20 years http://en.wikipedia.org/wiki/.io)
>>>>>> I got us "uom.si" (http://en.wikipedia.org/wiki/.si for Slovenia,
>>>>>> other than Pepsi, there is nearly no company or project outside that
>>>>>> country, which makes the domain a lot cheaper than "io" ;-) as a fairly
>>>>>> unique place dedicated to SI units.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Based on the NIST overview
>>>>>> http://physics.nist.gov/cuu/Units/units.html please reply with your
>>>>>> (+1) preference of having:
>>>>>>
>>>>>
>>>>>>    1. Nothing except Dimensionless (probably best in the SPI package)
>>>>>>
>>>>>>  2.      Only the 7 SI Base quantities plus Dimensionless (in
>>>>>> javax.measure.quantity) s. Table 1
>>>>>>
>>>>>> 3.      SI derived quantities (in javax.measure.quantity) +
>>>>>> Dimensionless s. Table 2 (and mostly CLDR, too)
>>>>>>
>>>>> in the API?
>>>>>>
>>>>>>
>>>>>>
>>>>>> The delta from currently around 50 quantities should move to the SI
>>>>>> module as long as they're commonly accepted for use with the SI system,
>>>>>> e.g. http://physics.nist.gov/cuu/Units/outside.html
>>>>>>
>>>>>> This quantity catalogue is as platform-independent as the API itself,
>>>>>> so RI, SE Port and other implementations may use it where appropriate. 
>>>>>> The
>>>>>> RI will however probably stick to those few quantities we decide to 
>>>>>> keep in
>>>>>> the API. While uom-se or other projects and implementations can use the
>>>>>> extended SI catalog or additional quantities (to be defined elsewhere,
>>>>>> likely under the non-SI UOM umbrella)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>        Werner
>>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>
>


[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Werner Keil 04/07/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Chris Senior 04/08/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Werner Keil 04/08/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Chris Senior 04/08/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Werner Keil 04/08/2015

[jsr363-experts] Re: [VOTE] Define quantities to remain in API (see UOM-100)

Leonardo Lima 04/20/2015
 
 
Close
loading
Please Confirm
Close