Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update CO2CarDemo based on CLDR #97

Open
keilw opened this issue Sep 22, 2020 · 2 comments
Open

Update CO2CarDemo based on CLDR #97

keilw opened this issue Sep 22, 2020 · 2 comments
Labels
domain Domain-specific demos
Milestone

Comments

@keilw
Copy link
Member

keilw commented Sep 22, 2020

The CLDR system already defined LITER_PER_KILOMETER, LITER_PER_100KILOMETERS and MILE_PER_GALLON as Unit<Consumption<Volume>>. This overlaps with the declaration of the quantity FuelConsumption in the energy module. Update the CO2CarDemo accordingly by using the CLDR units if possible.
Should there be a problem with Consumption, we might have to reconsider it and move the FuelConsumption type to systems-quantity so it may be used by CLDR.

@keilw keilw added the domain Domain-specific demos label Sep 22, 2020
@andi-huber
Copy link
Member

regarding CLDR units:

Avoid use of double type factors when defining Units, instead use integers or rational numbers (in case the definition allows us to). eg:

regarding Consumption:

Defining consumption based on volume per length might be considered bad practice, because for any given substance consumed, it's volume is dependent on its temperature and pressure. So to improve on that one could define consumption as mass per length, but then this is not generic enough, because, one could also think of consumption as being of units mass per time.

@keilw
Copy link
Member Author

keilw commented Sep 22, 2020

@andi-huber Thanks for the update, so I guess you suggest to go with the FuelConsumption type then and add it to systems-quantities to allow using it for CLDR? Based on the discussion we also had in unitsofmeasurement/uom-systems#176, that sounds reasonable because it depends on multiple factors.
I would not remove Consumption, if we come back to it with other quantities like Electricity, not sure if that also has a similar side-effect, but I guess there should be some that are neutral. I imagine there are also other use cases like "Data consumption" in the cloud that justify its existence.

Please create a PR against CLDR with the precision changes.

Once we took the FuelConsumption into consideration, do you think that'll solve the problem in https://github.com/unitsofmeasurement/uom-systems/blob/master/unicode/src/test/java/systems/uom/unicode/FuelConsumptionTest.java (unitsofmeasurement/uom-systems#177), or could that also have something to do with using double? Note, Indriya has a major Jigsaw problem, so let's be extra careful with solving any functional problems beyond 2.0.4 before that is addressed, see unitsofmeasurement/indriya#306.

keilw added a commit that referenced this issue Dec 6, 2020
keilw added a commit that referenced this issue Dec 7, 2020
keilw added a commit to unitsofmeasurement/indriya that referenced this issue Jan 17, 2021
keilw added a commit to unitsofmeasurement/uom-systems that referenced this issue Jan 17, 2021
keilw added a commit that referenced this issue Jan 17, 2021
keilw added a commit to unitsofmeasurement/uom-impl-enum that referenced this issue Jan 25, 2021
@keilw keilw modified the milestones: 2.1, 2.2 Dec 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain Domain-specific demos
Projects
None yet
Development

No branches or pull requests

2 participants