Comments (15)
Thanks for the clarification. The beauty of open standards is, there are multiple implementations, if @jpink prefers to write his own, or use another one, sure no problem.
Will use this ticket to see, how Calculus
could be extended for additional converters.
from indriya.
Now I found the way to introduce my units using SimpleUnitFormat.getInstance().label(unit, unit.getSymbol())
and prossibly extending classes may also work. Investigating...
from indriya.
Thanks for mentioning this. I suppose, you do have some sort of CurrencyConverter
or similar subclass of AbstractConverter
?
The Calculus.normalFormOrder
is used in a very isolated way, so @andi-huber do you see any problems adding a method like registerUnitConverter
, somewhat similar to setCurrentNumberSystem
? And if added, how should it handle the order of new, custom converters? Before or after 99 for AbstractConverter.Pair
?
from indriya.
Correct, it's a sub-class of AbstractConverter
. I believe the proposed method would also allow for asymmetric converters (if they inherit from AbstractConverter
) and thus be useful for @jpink.
What I'm doing now is adding it via reflection (with order 1000), but that is of course a dirty hack.
from indriya.
I tried to create separate system using only javax.measure
(not to extend tech.units.indriya.*
classes). It is working correctly until I try to combine two systems by ProductUnit.ofQuotient
:
EURO.toString() // Prints "β¬"
EURO.divide(Units.MEGAWATT_HOUR).toString() // Prints "null/MWh"
How can I register my Euro unit to SimpleUnitFormat.unitToName
map?
I'm out of ideas. I try to use UoM in openHAB, but in this case it seems impossible to tell the unit for the system. Sadly I have to fall back use only BigDecimals.
from indriya.
Yes, that's indeed the way. Note, in the most recent Indriya versions, there is SimpleUnitFormat.getInstance()
which returns a shared instance across the JVM / application lifetime, while SimpleUnitFormat.getNewInstance() creates a new instance that is local to a particular class or session, where label()
is not so persistent. Allowing to adjust it for a particular purpose, e.g. a batch run, reporting or something similar, where you might want special settings that do not affect the rest of your application.
For EBNFUnitFormat
it would be a little trickier, because you have to create a SymbolMap
first, and then one could also use label()
on that instance before creating an EBNFUnitFormat
instance with it.
I just created ticket #403 to make that easier.
from indriya.
I don't know what EBNF means π
Now i faced minor issue. Let's say that USD
and AUD
have the same symbol $
. Is there any way to embed some metadata (currency code) in the BaseUnit
? The class is final, so I can't extend it. The idea what I got, is to create own dimension for each currency. UnitDimension.parse(char symbol)
allows only one character and there is 180 currencies. So maybe I can find free space from Unicode. Or it is possible to extend UnitDimension
, but if I understood correctly there shouldn't be multiple dimensions with same symbol? Or can I "force" currency code (three chars) as the dimension symbol?
from indriya.
I was thinking of a "hybrid" between this JSR and JSR 354 (Money and Currency) for quite a while, but it is a bit complicated.
@dautelle had a money implementation back in the days of JSR 275.
BaseUnit
should not be extended because it meets a very special purpose, the SI base units, nothing else.
Not sure, why you would use Dimension
for currencies, aren't those units? You might have to play a bit with the label() method of SimpleUnitFormat
, but that way USD
and AUD
could have distinct names but the same label ("$")
from indriya.
from indriya.
I'm working on a similar problem (openhab/openhab-core#3503). While conversion of currencies (we use symmetrical only, but the issue is similar) works fine, product units (like EUR/kWh
) don't work.
The reason is that UnitCompositionHandlerYieldingNormalForm
throws an NPE:
java.lang.NullPointerException: no normal-form order defined for class 'org.openhab.core.internal.library.unit.CurrencyConverter'
at java.util.Objects.requireNonNull(Objects.java:336) ~[?:?]
at tech.units.indriya.internal.function.simplify.UnitCompositionHandlerYieldingNormalForm.isNormalFormOrderWhenCommutative(UnitCompositionHandlerYieldingNormalForm.java:112) ~[?:?]
at tech.units.indriya.internal.function.simplify.UnitCompositionHandlerYieldingNormalForm.compose(UnitCompositionHandlerYieldingNormalForm.java:80) ~[?:?]
at tech.units.indriya.function.AbstractConverter.concatenate(AbstractConverter.java:179) ~[?:?]
at tech.units.indriya.unit.ProductUnit.getSystemConverter(ProductUnit.java:330) ~[?:?]
at tech.units.indriya.AbstractUnit.getConverterToAny(AbstractUnit.java:327) ~[?:?]
because it has a fixed set of supported converters and it is not possible to add new converters. The set of converters is retrieved from Calculus.getNormalFormOrder()
and initializes and returns Calculus.normalFormOrder
which is inaccessible.
For us using a DoubleMultiplyConverter
would be fine, but that's also not possible, because in our new class CurrencyUnit
we can't instantiate that because all constructors are package private.
from indriya.
BaseUnit
should not be extended because it meets a very special purpose, the SI base units, nothing else. Not sure, why you would useDimension
for currencies, aren't those units? You might have to play a bit with the label() method ofSimpleUnitFormat
, but that wayUSD
andAUD
could have distinct names but the same label ("$")
@keilw: I added currency "Β€" dimension, because I don't understand the dimension system and don't want to mess with existing ones. $ symbol isn't problem for me for now. I use ISO code for parsing using alias. And currencies are shown using symbols. The user knows the context.
@dautelle: I don't need to exchange currencies. I only want to convert units eg. 100 β¬/MWh => 10 snt/kWh. That's easy divide by ten without the units library, but I have fetish to use it π
For us using a
DoubleMultiplyConverter
would be fine, but that's also not possible, because in our new classCurrencyUnit
we can't instantiate that because all constructors are package private.
@keilw, @J-N-K: I don't understand what are the benefits of closing every single class in the implementation if they aren't the public API. Developers can always fork codes and patch them (like I often do). But that causes that I can't integrate my implementation to OpenHAB. Currently my UoM works as I like inside the binding, but OpenHAB doesn't understand those units. So I use full Quantities inside of the binding and tell only numbers (without units) to OpenHAB.
BaseUnit
should not be extended because it meets a very special purpose, the SI base units, nothing else.
@keilw: I really understand if there is good reasons to close something. But then you should document those (in the code) and tell what is the correct way to do things or provide some workaround (in documentation).
Sorry but I got a little pissed of this library. I didn't got it working in three weeks, so I give up, let it be and done thing the other way.
from indriya.
I would like to ensure that one thing is 100% clear: The statement of @jpink is in no way endorsed by openHAB maintainers group and does not reflect my or any other opinion I know of.
from indriya.
In a broader sense having units for money with different currencies (USD, EUR, ...) falls in the same ballpark as having units like RADIAN and DEGREE. All those units have same dimensions (dimensionless in that case) but cannot necessarily be converted into one another. (I believe you cannot convert RADIAN into USD, or RADIAN int STERADIAN.) We say those units are not commensurable. However having categories of units that form a set of commensurable units, would be nice. E.g. having a set of units for the category money that allows for converters to be defined within this category.
Not sure if the current API can do this or if it can be extended to do this.
I don't have immediate answers. Perhaps I find time later this month.
Some related material:
- There can be only one
ONE
#361 STERADIAN/RADIAN
discussion #257- Introduction of
Unit Categories
#258 - Unit Equivalence (Wiki) https://github.com/unitsofmeasurement/indriya/wiki/Unit-Equivalence
from indriya.
The use case of OpenHAB is mainly something like EUR/kWh
, or maybe the cost per ton of CO2, etc., not converting Euros into Dollars or Radian.
In the meantime, what about adding new custom converters (which as mentioned above are needed for EUR/kWh
or similar) to normalFormOrder
in Calculus
?
And how should its order look like, between the built-in ones and AbstractConverter.Pair
or at the end of the list?
from indriya.
@andi-huber: I agree that there will be challenges to convert many different kinds of dimensionless units. But I think this library wasn't birth because of ideological or theoretical reasons. It should solve real world problems and there is no need to try convert radians to USD.
from indriya.
Related Issues (20)
- Improve performance of DefaultNumberSystem.narrow(BigDecimal) HOT 10
- Add ability to remove label from `SimpleUnitFormat` HOT 2
- indriya 2.1.3 depends on two versions of javax.measure:unit-api
- Create Java 9+ version of Calculus
- Release Indriya 2.2
- Release 2.2 missing on Maven central HOT 2
- Turn Range into an Interface
- Allow to create a standard SymbolMap for EBNF
- EBNFUnitFormat can not handle chain of TransformedUnit HOT 4
- Lazy reduces scalability of applications using Indriya HOT 1
- Turn QuantityRange into a record for Java 17+
- Missing symbol for some derived units HOT 2
- Change internals of SimpleUnitFormat
- Create a "SymbolMapUnitFormat" abstraction over EBNF and LocalUnitFormat
- Adding a Pattern to SimpleUnitFormat similar to SimpleQuantityFormat or SimpleDateFormat
- Parsing of 1/mile is not possible HOT 1
- EBNFUnitFormat formats into a string that it cannot parse back anymore HOT 2
- Overflow or underflow happening for simple addition? HOT 7
- Correct JavaDoc for ComparableQuantity
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from indriya.