Closed occamsystems closed 10 months ago
This PR introduces a fundamental change of the library contract, and I am not (yet) convinced it is necessary.
Until now, the library instantiates the model in the static initializer. Instantiation is deferred to the InitializerImpl class, which has to be on the classpath. This mechanism allows you to populate the model with whatever units you need. This would allow to use a smaller model if needed, or to use additional units. However, we have not allowed runtime manipulation for a long time so as to defend against introducing errors that are hard to spot. Up until recently, the complete model used final members to ensure this, but I've had to loosen this constraint to allow for runtime manipulation for the case of creating units with the intent of contributing them to QUDT. (See e.g. qudtlib-tools/src/main/java/io/github/qudtlib/QudtEntityAtRuntimeAdder.java)
What's the use case you want to tackle with these changes? Do you want to enable users to create new units? Or do you need a set of units for a certain domain and you could add them during class initialization?
The use case I have is that I have a software package that enables doing general math over quantities. This is used in engineering applications. I have code that is very good at finding exact or analogous matches among predefined units over operations like multiplication and exponentiation. However, the users often need to write equations that produce results (especially intermediate results) that do not have associated named quantities or units in QUDT vocabulary.
For example, let's suppose some system that maintains a concentration (g/L) proportional to power consumption (/W). Then I have some kind of optimization I want to do that relies on the second derivative of this function with respect to power. I am now looking for (g/L/W3). That unit is perfectly well-defined and one that I might conceivably need. I have all the information I need to construct it. But it doesn't (and shouldn't) exist in QUDT vocabulary. I just need it at this moment.
Depending on whether this in an intermediate or final result, I may or may not want to serialize the quantity back to RDF. If I do, it should be in my RDF namespace, which is why the Quantity constructor takes the baseIri argument.
Right now, it is impossible for me to generate this unit at runtime with QUDT lib. And that's a significant problem for me.
Thanks for the explanation. I understand your requirement and I think it should be supprted by qudtlib.
One thing I have recently stumbled across is the requirement for fractional exponents . I forget which unit but it had an exponent of 1/2. Is that something you need as well?
I think this is almost inevitable. I don’t know of any specific equations currently requested that would use them, but I’m certain it would come up before long.
Get Outlook for iOShttps://aka.ms/o0ukef
From: Florian Kleedorfer @.> Sent: Friday, December 22, 2023 4:37:58 AM To: qudtlib/qudtlib-java @.> Cc: Josh Feingold @.>; Mention @.> Subject: Re: [qudtlib/qudtlib-java] Runtime Unit Creation (PR #74)
One thing I have recently stumbled across is the requirement for fractional exponents . I forget which unit but it had an exponent of 1/2. Is that something you need as well?
— Reply to this email directly, view it on GitHubhttps://github.com/qudtlib/qudtlib-java/pull/74#issuecomment-1867460851, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4EKAK2ASPEKWWJO3IFFJVDYKVIHNAVCNFSM6AAAAABA5OWXESVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRXGQ3DAOBVGE. You are receiving this because you were mentioned.Message ID: @.***>
To be clear, regarding fractional unit exponents, I certainly would not consider fractional exponents to be a prerequisite for dynamic units. I do think they are worthwhile though.
That's how I understood your point, but thanks for clarifying.
Sorry this takes a bit of time, I am traveling and have lots of family events. I may not be able to merge and release before early January.
No problem. I just didn't want to cause a misunderstanding.
This allows for the construction of new units at runtime from FactorUnits, which is very useful when trying to do general computations over quantities.