-
-
Notifications
You must be signed in to change notification settings - Fork 42
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
Arithmetic operations should be done in system units for certain scales #128
Comments
I certainly would not do that for every single operation. It is a burden and hassle having to convert If you plan to do this for Temperature only, why not, but please let's wait till all the items are worked on in a particular order. |
Actually it does not depends on the level of quantity (Interval versus Ratio). In current state of Unit API, all This issue is already fixed in Apache SIS implementation of units of measurement without additional burden and without the need to perform any special case for temperature. I will try to copy the code to seshat this week. |
Well then let's park this till we see, how Seshat deals with it. The users do expect the same behavior for a majority of units, so a |
Please note, while scheduled for 2.0 of course, both this ticket and #124 (which is currently considered prio1, but there are other UnitFormat implementations that can deal with it, so there is a workaround and it only occurs with newly introduced labelled units) should either be solved within 2-3 weeks, otherwise we can't have it in EDR1. And the EDR must be published within 9 months, which is reached in September, so no later than the last week of August everything else goes into the Public Review stage (that is another 6 months later, we should aim for end of the year to be ready for the SI reforms in early 2019) |
I found out that we probably have to do the arithmetic in BigDecimal (both for correct precision and overflow handling) and with some conversion anyway, and since I'm moving this code into a single class, implementation would be relatively simple. I had it working for multiplication (quantity × quantity), but haven't had time to check it in and create a pull request. |
Are any other PRs or tickets related to this one? Have not tried for a PR, but issues in Waffle can be marked as needs #X or requires #Y (only in the first description field), so they are connected in the Waffle Kanban board. |
Note: when Wikipedia said that multiplication of an absolute measurement in Celsius is not allowed, my interpretation is that the multiplication is not allowed with the value as-is (in Celsius). There is nothing saying that we are not allowed to convert the quantity in order to carry the operation. Multiplying a
Implementation is free to convert the result back to °C if they wish. My proposal is to keep the result of case 1 above in kelvin for less surprising behavior. Case 2 can be converted back to Celsius with no harm. |
After discussion with @keilw and given the comments above, it looks like this is one of our major stories for the near future. @filipvanlaenen I see you mentioned that you've already started working on this. Do we have any update? |
@thodorisbais Thanks for offering to help. @filipvanlaenen has assigned this to himself, so if you were able to help him where necessary, it would be great. The 2.0 milestone tickets that are still open are https://github.com/unitsofmeasurement/indriya/milestone/1. While Compound Formatting already works as intended, parsing is to be done. I should be able to do the lion share of the format epic. Beside that "function" is where this ticket resides, there is also something to do in the "documentation" epic, e.g. JavaDoc, but some of it has already been done. |
@thodorisbais let me know if you need my helping hand in this implementation. |
Is this typo mistake How will we know the target unit to be converted if it is not part of input? |
It is not a typo. 0°C + 0°C = 275.15 K + 275.15 K = 550.3 K = 275.15 °C (note: there is no "°" in front of Kelvin units). We know this is counter-intuitive. About what should be the target units: I don't think it needs to be specified. It can be implementation choice, as long as the result is equivalent. For example 550.3 K is equivalent to 275.15°C, so both are acceptable output. But 275.15 K is not equivalent to above measurements, so it is not allowed. |
@magesh678 as you can see (in the discussion above and in the assignees' section of the right top of this issue), Filip is the one who's working on it, so, I guess the question regarding any help should be addressed to him. :-) That said, @filipvanlaenen , do you need any help here? :-) |
Thanks @thodorisbais . @filipvanlaenen Do you need any help here? |
Maybe I/it start/s becoming annoying, but given that our PR is soon, I need to ping @filipvanlaenen again for the status of this issue :-) . Any news, Filip? |
@filipvanlaenen any news here? |
Just a few days left until Apr. 19, so, I need to ask again :-) : @filipvanlaenen any news here? How is this going? Do you need any help? |
I'm not sure there is need for action (or maybe I have missed the point). What are the choices on the table? Regarding above discussion about whether to allow or disallow 1°C + 1 K for example, I have no objection to leave the choice to implementations. My only requirement is that if an implementation chooses to allow those operations, then the result shall be as if all calculations were done in ratio units (taking in account the |
Well this is the Reference Implementation, so unless we suggest that |
@desruisseaux I agree with most of what you wrote, except for a small point: I like the quote on wikidedia (https://en.wikipedia.org/wiki/Celsius) : Whatever is chosen, I'd say, if there is a unit with an interval scale involved, have the user be explicit about how he wants it to be evaluated. e.g.
and thus, given U_i is the unit with an interval scale (e.g C), U the corresponding ratio scaled unit (e.g. K) and b the distance of the origin of U_i from the U scale (e.g. 273,15):
PS. |
True, but if the user did not said explicitly if the values are interval or absolute measurements, we have to make some assumptions. In past debates we did not found an arithmetically consistent assumption other than assuming that all measurements are absolute (thread of past debates contain equations showing inconsistencies of other assumptions). For making possible to get 0°C + 0°C = 0°C, we need to explicitly specify that at least one measurement is an interval. The equations that you wrote are fine and illustrate well this need: an information about ratio versus interval scale is attached to every measurements. The currently proposed way to provide this information in JSR-363 is the |
No it's not provided by JSR-363, it is by JSR-385 however ;-) |
Ah, sorry! Thanks for the correction. |
Please have a look at https://github.com/unitsofmeasurement/indriya/blob/master/src/test/java/tech/units/indriya/quantity/AbsoluteVsRelativeTest.java and https://github.com/unitsofmeasurement/indriya/blob/master/src/test/java/tech/units/indriya/quantity/WolframTuturialTemperatureTest.java based on the Wolfram statements about calculating Temperature quantities. Except 2 all others are met already. If there are specific operations that need tweaking or extension, I guess an SPI approach similar to addressing #229 (a detail of Quantity arithmetics from a numeric precision point here, the |
I need a better look at this one so that I can express an opinion. Hopefully, that's gonna happen during the weekend. Good discussions, though, people! |
@desruisseaux and that was just my point: don't make assumptions when dealing with units that are non-ratio-scale (e.g. C). Let the user be explicit. Assumptions are what made the spacecraft crash in the first place ;-) @keilw the tests look great. But like my comment to @desruisseaux , would it be an idea to make RELATIVE/ABSOLUTE mandatory for non-ratio-scale units ? This is my last comment on this subject :P I think I have bothered you guys enough by now. Thanks for the patience. |
@dstibbe |
Talking about Public Review, is there a place where we can comment? More specifically I'm a little bit confused about the |
There is no such directory in the RI, and for optional smaller modules there is this ticket: unitsofmeasurement/unit-api#42 It is not subject to the main deliverables but if a tiny box with very constrained memory (e.g. Raspberry Pi Zero or similar) needs a tailor-made version of the API they can use these profiles. And likely have to create a smaller implementation (like https://github.com/unitsofmeasurement/uom-impl-enum) Again, we're not talking about the deployables to MavenCentral, this is for Embedded use cases where they only need one or two modules for a particular profile. |
Coming back to the original problem here, @dstibbe thanks a lot for the detailed listing of possible combinations. The most important question is, can https://en.wikipedia.org/wiki/Conversion_of_units_of_temperature#Comparison_of_temperature_scales contains a good comparison of temperature scales. It does not talk about However taking the last two cases
It just does not seem right if you took
Taking a forced conversion into the system unit ( So all we know at the moment at runtime is the |
Given that 1. the discussions are escalating to a completely different level, and 2. Filip has not provided any update here for a while, it's wise to remove Filip as the assignee of this issue so that we give the chance to anyone else who might be interested in taking this over. In case Filip comes back with an update, we can always rediscuss it :-) . |
Thanks, the ticket already has "Help needed" and from what I recall Filip expects a new member of his family, so I guess he could be busy for a good reason right now ;-) |
Previous equationsTo start, in my previous set of equations, the
was actually:
A small difference, but not unimportant. The K unit is very relevant. I have fixed the previous post. @keilw Regarding your remark about force convert; I absolutely agree with you. The DefinitionsLet's start with terminology, I noticed that I myself have not been as consistent as I would like to be Units have a:
Quantities are
If one disagrees with these definitions, don't mind correcting me. I could find no proper alternative for the above term 'measurement' TemperatureFollowing these definitions, the units for C and K are, in pseudo code:
providing quantities for K is done as following:
Since K is in absolute scale (AbsoluteUnit), there is no need to indicate the type of quantity. When providing quantities for C we should require(!) the user to provide an indication of the type of Quantity, because it is a RelativeUnit and
or
@keilw LengthBoth ft and m are AbsoluteUnit's in the Length dimension. Unlike K and C, they do not differ in origin. However, where K and C are equal That means that ft and m would not require a quantity type, since they are both AbsoluteUnits:
We can use MEASUREMENT/DIFFERENCE, but it is not required. ConversionHow to convert between Relative and Absolute units? Let's take Plumbus once more :) Now let's redefine the Plumbus (Plb) to have an origin at -200 m and have a Plb be the size of 13 m In pseudo
The conversion between Plb and m would be done as following:
Same unit, different originLets say you want to do some logic with measurements of the height of the water. In the Netherlands this is done relative to the NAP (Amsterdam Ordnance Datum). How do we handle that? It is actually irrelevant what the actual height of the NAP is, as long as all are measured alongside it. We can't say I would propose something along the lines of:
And Length measurement quantities can be given according to the NAP reference:
But the following would be invalid:
Since we cannot add NAP to a measurement if we do not know the offset. And we can't add NAP to a measurement of some other reference. @keilw |
Sorry about that :S |
@dstibbe, @thodorisbais No need to be sorry, that's exactly what a Review is for ;-) |
First things first, so, just a few words about the logistics:
On topic, what is your take on this one (, given that you have already been exposed to it during our Adopt-a-JSR Day)? |
Thanks @thodorisbais, lots to read up on! Looking at @dstibbe 's comment, I agree with what he said. During the Adopt-a-JSR day I worked on this issue and found a fix for adding relative temperatures in anything but Kelvin. It was based on only converting the value of the quantity if the quantity was relative, or a difference as @dstibbe calls it, and if addition is used in converting. I believe only converting for the ratio (or size?) between two units if it is a relative quantity (or difference) and not for the offset in origin would lead to the right numbers at least. How do we proceed from here? I can offer my fork for a pull request if you'd like, even though I've only changed the behavior for addition at the moment. |
@mthoolen Yes, if you could propose a pull request, that would be great. We could then have others review it (including @dstibbe although I'm not sure if he's a JCP member but making comments here or reviewing a PR is open to everyone, only those who raise the PR or merge it should be JCP members) to get an outcome everyone feels works best. |
@keilw I'd be happy to review it. I'd even be happy to make a PR, but I am indeed not yet a JCP member. I did sign the JCP Full Membership Agreement, but it is waiting for review. |
Cool, no problem to review PRs by others in the meantime. As the PMO accepted somebody else's EG membership for JSR 385 quite recently, should your Full membership get approved within a few weeks rather than months, we could still offer you a full EG membership if you want. Helping this rather sophisticated ticket alone justifies that IMO ;-) |
Added behaviour for adding values with an offset origin (issue #128)
Closing this, created #247 as a follow up for some lose ends. |
Implementation of unitsofmeasurement/unit-api#95 and unitsofmeasurement/unit-api#131 in Indriya.
Some examples of the expected behavior:
Needs unitsofmeasurement/unit-api#95
Also see https://github.com/unitsofmeasurement/unit-api/wiki/Arithmetic-rules-for-Difference-versus-Absolute-quantities
The text was updated successfully, but these errors were encountered: