Conversion of 'h'

[lfoppiano]

HI all, I'm having a weird behaviour, when I try to convert hours / h in their base unit seconds.

If I use the UCUM converter, I get it correcty, but with the other conversers

• Unicode service provider
• SI service provider
• DEfault service provider

I get the unit parsed correctly but having the system Unit J·s, which is the Planck constant (http://ckw.phys.ncku.edu.tw/public/pub/Notes/PhysicalConstants/Fundamental%20Physical%20Constants.htm) ... let's say I know this is hours is there a way to help/customise the normalisation?

Maybe I'm missing also how I should be implementing this part, thanks in advance for your advices. Luca

[keilw]

Hi, Thanks for bringing this up. Would it be possible to also:

1. Test it with Indriya, the RI of JSR 385 and
2. Raise a similar ticket in https://github.com/unitsofmeasurement/indriya/issues

The 0.9 version of both https://github.com/unitsofmeasurement/si-units and https://github.com/unitsofmeasurement/uom-systems is based on Indriya 1.0 already which should present a very similar behavior. Since the Planck constant is part of the foundations for theproposed redefinition of SI base units it is vital to JSR 385, but we cannot guarantee this will also be addressed in 1.0 (JSR 363) retroactively.

Thanks, Werner

[keilw]

We also discussed defining the Planck Constant (h) somewhere after the SI redefinition, so far in https://github.com/unitsofmeasurement/indriya/issues/43 we concluded to do it in the SI Units module, also see https://github.com/unitsofmeasurement/si-units/issues/45.

@lfoppiano Would it be possible to give some examples here?

I understand, it works with the UCUM system and UnitFormat implementations there, or is there another problem? Since UCUM is the only place defining the Planck Constant right now, it is also the only module fully supporting it.

If the question (sorry it is not 100% clear, if you face a problem with conversion or formatting) was how the Planck Constant may be rendered J·s instead of h, there is currently an easy way to do this using SimpleUnitFormat: SimpleUnitFormat.getInstance().label(UCUM.PLANCK, "J·s");

[lfoppiano]

@lfoppiano Would it be possible to give some examples here?

@keilw I'm trying to answer you, though we might need a couple more iteration on this subject.

I'm giving you first an idea of how the workflow is constructed.

The example text is the following: These specimens underwent heat treatment by simulating the conditions for the large size rotor shaft centre of a large capacity generator. First, it was heated to 840°C to form austenite structure and cooled at the speed of 100°C/hour to harden.

We recognise various quantities (840°C, 100°C/hour).

The quantity "100°C/hour" is composed by value 100 and unit "°C/hour".

At this point using a CRF based machine learning model we decompose the unit in particular we rewrite it as product of elements:°C/hour ==> °C * hour^-1 (this model also try to recognise for SI if there is a prefix..).

Before normalising, we try to transform each element to their notation (e.g hours -> h) in order to have a kind of normalised version of the input unit, in particular for composed units. As consequence °C * hour^-1 become °C * h^-1 and we use the string version °C/h as input for the unit of measurement parsers.

We first try to infer the type of system, in this case this is a composed unit without a specific name (e.g. Velocity) so we do not know whether it's a SI / DERIVED / NON_SI unit.

From this point we've implemented the parsing in a way to try one parser if the previous has failed.

I understand, it works with the UCUM system and UnitFormat implementations there, or is there another problem? Since UCUM is the only place defining the Planck Constant right now, it is also the only module fully supporting it.

Actually I was wrong before, with UCUM I get an error: Method threw 'systems.uom.ucum.internal.format.TokenMgrError' exception. Lexical error at line 1, column 1. Encountered: "\u2103" (8451), after : "" while with the other converters (default, si, unicode) I don't get an error but the wrong unit/ constant. This is a bit surprising, or I'm missing something again here :)

If the question (sorry it is not 100% clear, if you face a problem with conversion or formatting) was how the Planck Constant may be rendered J·s instead of h, there is currently an easy way to do this using SimpleUnitFormat: SimpleUnitFormat.getInstance().label(UCUM.PLANCK, "J·s");

Actually the problem is that I would like h to be recognised as hours and not plank constant

[lfoppiano]

FYI I've just checked and I would have the same issue when I try to convert km/h using the SI format service.. Here there is an ambiguity I think, because h can be both the plank constant or hours. I guess that the SI format service supports also derived units (time measurement are part of it https://physics.nist.gov/cuu/Units/outside.html)?

If not, there is no issue... but if yes then we should find a way to disambiguate the two cases. Use a parameter to disable the constants could be a quick and dirty solution but the problem would not be solved - or the decision taken.

Feel free to let me know if you have more questions.

[keilw]

Do you mean the UCUMFormat? Because there is no dedicated SI Format.

[lfoppiano]

@keilw I use si.uom.impl.SIServiceProvider as a SI formatter/parser

[keilw]

To provide you the formatter, but that would likely be the SimpleUnitFormator EBNFUnitFormatand LocalUnitFormat.

[lfoppiano]

You are right it's the SimpleUnitFormat... what should I do? should I use the UCUMFormat?

[desruisseaux]

I may have missed a point, but why a UnitFormat is recognizing the Planck constant at all? Physical constants are quantities, not unit symbols. If a UnitFormat is parsing "h" as a the dimension of the Planck constant, then I think it is plain wrong. It would be okay to recognize the Planck constant in a QuantityFormat however.

[keilw]

Except G and the Boltzman constant they all represent quantity in UCUM: http://unitsofmeasure.org/ucum.html#const Not just for QuantityFormat, they are also defined as actual unit constants by UCUM.

[desruisseaux]

UCUM puts those constants in bracket for differentiating them from standard unit symbols (see §30.2: the "c/s" and "c/i" columns are normative, not the "Print" column). So UCUM defines [h] for the Planck constant, not h.

I have not seen many physical quantities used as units except the ones listed in §31 (electron-Volt, unified atomic mass unit, astronomic unit, parsec). The physical constants h, G ,etc. indeed appear often in equations, but they are used as abbreviations for quantities expressed in SI units.

[keilw]

Thanks, good point. Actually in Print it does not, but unlike C/S or C/I this mode is unidirectional, so Print has no parsing feature enabled. I think for SI it's good to further discuss how we want to support them under https://github.com/unitsofmeasurement/si-units/issues/45. The earlier discussion hinted to use primitive numbers only like private static final double AVOGADRO_CONSTANT = 6.02214199e23; // (1/mol), but that would somehow contradict how UCUM does it where the ones that are not Dimensionless also have a Quantity attached, so they are type-safe like most of the other framework. After the SI redefinition all or at least those used by the SI base types should be in the SI module, too. Whether formatting and parsing is supported also depends a bit on how we model them. If similar to UCUM then at least the formatters should support them, too. Any ideas, but please unless they directly relate to this particular case (e.g. if UCUMFormat could not parse operations with [h] or [H]) please do in https://github.com/unitsofmeasurement/si-units/issues/45. If the UCUM module does work, I assume this could be seen as resolved because only UCUM supports these constants for now (some may be internal primitive values but most are not exposed by SI or NonSI) If it creates a confusion I'd be inclined to either remove SimpleUnitFormat label hints or we could also use a UCUM compliant representation like [h]. I know SimpleUnitFormat is closer to the Print format, but it also allows to parse and there are no restrictions on what can be parsed and what can't as long as the expression is valid.

[lfoppiano]

HI all, again me. I'm back to this issue again, since after updating to 2.0-SNAPSHOT it seems that every default unit format, converts h to the PLANCK_CONSTANT.

I've tried to debug and trying to understand where the problem is, I notice that

@Override
    public void label(Unit<?> unit, String label) {
      if (!isValidIdentifier(label))
        throw new IllegalArgumentException("Label: " + label + " is not a valid identifier.");
      synchronized (this) {
        nameToUnit.put(label, unit);
        unitToName.put(unit, label);
      }
    }

inside SimpleUnitFormat.java (indriya) is called twice, and the h (time) is overriden by the plank constant.

Line 239 of UCUM.java: public static final Unit<Time> HOUR = addUnit(Units.HOUR); Line 282 of UCUM.java: public static final Unit<Action> PLANCK = addUnit(SI.JOULE_SECOND.multiply(6.6260755E-34));

could that be the case that the definition of h is overwritten?

[keilw]

Actually it's not "h", it's "ℎ" for the Planck constant. It's already addressed in the 2.0-SNAPSHOT of SI Units, guess a few errata will also go into the 1.x branch soon after.

[lfoppiano]

Actually it's not "h", it's "ℎ" for the Planck constant. It's already addressed in the 2.0-SNAPSHOT of SI Units, guess a few errata will also go into the 1.x branch soon after.

OK, but I was talking about 2.0-SNAPSHOT. I will have a look closely...

[keilw]

@lfoppiano is this still an issue or could it be closed?

[lfoppiano]

@keilw give me some time to check and I will either close or reply here.