Use Advanced Search to search the entire archive.
Re: On Quantity - Measurement relationship
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: On Quantity - Measurement relationship
- Date: Sat, 1 Nov 2014 16:06:49 +0100
>
It goes pretty much alongside what current implementations like JScience
or UOMo do. 1 I think I could live with if a vast majority votes for it.
It''s pretty much the state we have in Unit-API now, but with a number of
>
operations like add(), subtract(), etc.
Indeed, but these operations may not be at the right level in Quantity (for
the same reasons as Comparable). To be consistent we should move them to
Measure(ment)/Amount.
Sound like going back to the start [?]
On Sat, Nov 1, 2014 at 3:09 PM, Werner Keil
<
>
wrote:
>
+1 for 2
>
>
It goes pretty much alongside what current implementations like JScience
>
or UOMo do. 1 I think I could live with if a vast majority votes for it.
>
It''s pretty much the state we have in Unit-API now, but with a number of
>
operations like add(), subtract(), etc.
>
>
IMHO 3 could be pretty confusing, and we already got that with Measure
>
vs.Measurable, you remember, though they implemented each other, people
>
had no clear understanding of what to use where. Unless Quantity was
>
completely turned into a pure "tagging" interface for a separar
>
Measure/Measurement/Amount type.
>
>
Cheers,
>
Werner
>
>
On Sat, Nov 1, 2014 at 2:53 PM, Jean-Marie Dautelle
>
<
>
>
wrote:
>
>
> Hi All,
>
>
>
> Here are the different options, I think:
>
>
>
> 1. Quantity and Measurement are merged into a single Quantity abstraction
>
> having a value (number) and a unit (and there is no Measurement
>
> abstraction)
>
>
>
> 2. Measure(ment)/Amount extends a high level Quantity abstraction (which
>
> allows for very abstract quantities, even enum, e.g. Mass m = HEAVY, no
>
> value and no unit). Note: We see in that case that Quantity cannot
>
> implement Comparable. HEAVY/LIGHT may depend on the context, the boundary
>
> may not be well defined or be relative, e.g. we can compare HEAVY with
>
> LIGHT but not HEAVY with another mass).
>
>
>
> 3. Quantity and Measure(ment) have distinct hierarchies. A Measure(ment)
>
> is not a quantity but a numerical/scalar representation of it (the same way
>
> that the image of an Elephant is not an Elephant).
>
>
>
> All options are valid and the choice is yours [?] !
>
>
>
> My personal favor goes for 2
>
>
>
> Cheers,
>
> JM
>
>
>
>
>
> On Sat, Nov 1, 2014 at 11:12 AM, Werner Keil
>
> <
>
>
> wrote:
>
>
>
>> And Amount extend Quantity or vice versa?
>
>>
>
>> Aside from JSRs dealing with only a single quantity type like 354 or 310
>
>> (though its TemporalAmount is a "Mash" or whatever you wanna call it,
>
>> holding a Collection of amounts, not a single amount;-) ICU4J uses
>
>> CurrencyAmount or TimeUnitAmount for subclasses of an abstract Measure.
>
>> Thus one could say ICU4J suggests you may use Amount as substitute for
>
>> Measure.
>
>>
>
>> Werner
>
>> Am 01.11.2014 09:21 schrieb "Jean-Marie Dautelle"
>
>> <
>:
>
>>
>
>> Hi Martin and All,
>
>>>
>
>>> A scalar is a physical quantity that it represented by a dimensional
>
>>> number at a particular point in space and time. Examples are hydrostatic
>
>>> pressure and temperature.
>
>>>
>
>>> A vector is a bookkeeping tool to keep track of two pieces of
>
>>> information (typically magnitude and direction) for a physical quantity.
>
>>>
>
>>> From this reference book definition we see that a vector is not a
>
>>> quantity (only its magnitude is). Therefore to respond to Martin (and
>
>>> what
>
>>> should be written in the spec) is that a Vector/Tensor does not belongs
>
>>> to
>
>>> this hierarchy and they are aggregate of quantities or aggregate of one
>
>>> quantity with something else (direction)
>
>>>
>
>>> A possible choice to enforce this notion of "magnitude" for measured
>
>>> quantity would be to replace the name Measurement with Amount !
>
>>>
>
>>> I hope this help.
>
>>>
>
>>> Jean-Marie.
>
>>>
>
>>>
>
>>> On Sat, Nov 1, 2014 at 5:39 AM, Martin Desruisseaux <
>
>>>
>
>
>>> wrote:
>
>>>
>
>>>> Thanks Werner for the link to the Microsoft articles. I had a look.
>
>>>>
>
>>>> I'm not aware of universally accepted definition of "quantity". Some
>
>>>> peoples make a distinction between "quantity" and "*physical*
>
>>>> quantity". For example in an article cited by Werner [1], the author
>
>>>> first
>
>>>> mention "physical quantity", then use only the word "quantity" in the
>
>>>> remaining of his article. He said "*Typically these quantities
>
>>>> possess unit of measure*", but I think that he implicitly means
>
>>>> "physical quantity".
>
>>>>
>
>>>> One could imagine the following type hierarchy:
>
>>>>
>
>>>> Quantity
>
>>>> ↑
>
>>>> Measurement
>
>>>> ↑
>
>>>> PhysicalQuantity or Scalar or ScalarMeasure
>
>>>>
>
>>>> But where would we put Vector, Tensor or any other kind of
>
>>>> measurement that are not a scalar in this hierarchy? Putting Vector
>
>>>> as a subtype of Measurement seems contradictory with the Quantity
>
>>>> base type.
>
>>>>
>
>>>> There is my proposal:
>
>>>>
>
>>>> - I think that Measurement should not extends Quantity, because
>
>>>> (to me) it would imply that all measurements are scalars, which would
>
>>>> exclude other kind of measurements like vectors.
>
>>>> - I think we should explain that, for the sake of simplicity,
>
>>>> JSR-363 merges the "pure quantity" concept with the "physical
>
>>>> quantity"
>
>>>> concept, and that we call that just "quantity". We may define our
>
>>>> quantity
>
>>>> as a "quantitative measurement".
>
>>>>
>
>>>> A Quantity in the "pure" sense is hard to fit in our type hierarchy
>
>>>> (e.g. above-cited contradiction with non-scalar measurement) and make
>
>>>> all
>
>>>> Length, Mass, *etc.* subtypes useless for other purpose than marking
>
>>>> interface. Furthermore the above hierarchy would allow users to
>
>>>> parameterize Unit instances with arbitrary Measurement subtypes that
>
>>>> are not something like Length or Mass. On the other hand, keeping the
>
>>>> current hierarchy, with the idea that we merged "quantity" concept with
>
>>>> "physical quantity" or "quantitative measurement", keep Unit
>
>>>> parameterization safer (can not use arbitrary Measurement), and keep
>
>>>> Measurement applicable to non-scalar measurement.
>
>>>>
>
>>>> In summary, I suggest to keep current hierarchy as-is but explain
>
>>>> better what we means by "quantity".
>
>>>>
>
>>>> Martin
>
>>>>
>
>>>>
>
>>>> [1]
>
>>>> http://research.microsoft.com/en-us/um/people/akenn/units/RelationalParametricityAndUnitsOfMeasure.pdf
>
>>>>
>
>>>>
>
>>>
>
>>>
>
>>> --
>
>>> It is not the strongest of the species that survives, nor the most
>
>>> intelligent. It is the one that is most adaptable to change. - Darwin's
>
>>> Origin of Species (digest)
>
>>>
>
>>
>
>
>
>
>
> --
>
> It is not the strongest of the species that survives, nor the most
>
> intelligent. It is the one that is most adaptable to change. - Darwin's
>
> Origin of Species (digest)
>
>
>
>
--
It is not the strongest of the species that survives, nor the most
intelligent. It is the one that is most adaptable to change. - Darwin's
Origin of Species (digest)
Attachment:
361.gif
Description: GIF image
Attachment:
347.gif
Description: GIF image