Use Advanced Search to search the entire archive.
Re: On Quantity - Measurement relationship
- From: Werner Keil <
>
- To:
- Subject: Re: On Quantity - Measurement relationship
- Date: Sat, 1 Nov 2014 11:12:20 +0100
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)
>