Re: [boost] Boost Units library preview
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen Sent: Friday, August 18, 2006 4:35 AM To: boost@lists.boost.org Subject: Re: [boost] Boost Units library preview
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
// Quan quan::length::ft qft(3); std::cout << "quan qft.numeric_value() = "<< qft.numeric_value() << '\n'; assert(qft.numeric_value() ==3);
Just a question: why is the member called numeric_value? are there other values?
I think Thorsten's question is a sympotom of a larger issue. Why does Quan use such convoluted terminology? Fixed quantity? Abstract quantity? Coherent quantity? Named quantity? Concrete quantity? Anonymous quantity? Static unit? United value? A general-purpose library should use simple terms and a bare minimum of names. Just some constructive criticism. Eric.
"Eric Lemings" <lemings@roguewave.com> wrote in message news:D730FF7CEDDCA64483F9E99D999A158B420671@qxvcexch01.ad.quovadx.com...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen Sent: Friday, August 18, 2006 4:35 AM To: boost@lists.boost.org Subject: Re: [boost] Boost Units library preview
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
// Quan quan::length::ft qft(3); std::cout << "quan qft.numeric_value() = "<< qft.numeric_value() << '\n'; assert(qft.numeric_value() ==3);
Just a question: why is the member called numeric_value? are there other values?
I think Thorsten's question is a sympotom of a larger issue.
Why does Quan use such convoluted terminology? Fixed quantity?
fixed_quantity is the name of the class template implemented so far ( one of 3 or possibly 4 different classes). It has gone through various names. Once just quantity, then ct_quantity, then t1_quantity, now fixed_quantity. It is a quantity where the Unit is fixed at runtime. All suggestions for alternate names are welcome.
Abstract quantity?
An abstract quantity is a quantity without a numeric value or a conversion factor. It still conforms to dimensional analysis and dimensional math. In fact the abstract quantity concept (small c) has now been gobbled up by the all encompassing Static Unit concept.
Coherent quantity?
PQS used the term coherent quantity to refer to a 'clean' si quantity. We now went for the simpler 'SI unit'.
Named quantity?
A named quantity has a name. In practise in Quan-0_2_0 this means that, where U is a model of StaticUnit and is_named_quantity<U>::value is true, that get_named_quantity_traits<U>::type , returns a traits class, which provides useful information, such as the name of the quantity and other information mainly useful for I/O purposes.
Concrete quantity?
A concrete quantity is a quantity which has a unit and a numeric value.
Anonymous quantity?
An anonymous quantity doesnt have a name, kind of the opposite of a named quantity. is_named_quantity<U>::value is false for anonymous quantities in the next version of Quan, and so their Named Quantity Traits class is effectively void.
Static unit?
This is a proper C++ Concept. Effectively its a compile time database which can be queried about various aspects of a particular fixed_quantity. It is a template parameter to fixed_quantity: fixed_quantity<StaticUnit,NumericType>
United value?
It is a detail of the implementation. Has it leaked into the docs somewhere? If so I will remove it as it may change without notice.
A general-purpose library should use simple terms and a bare minimum of names.
I am happy to accept that I am not very good at the documentation side of things. Luckily now I am getting some very good help with the Quan documentation and the code in general and that I hope will be reflected in the next version of Quan. regards Andy Little
On Aug 18, 2006, at 7:43 PM, Andy Little wrote:
"Eric Lemings" <lemings@roguewave.com> wrote in message
I think Thorsten's question is a sympotom of a larger issue.
Why does Quan use such convoluted terminology? Fixed quantity?
fixed_quantity is the name of the class template implemented so far ( one of 3 or possibly 4 different classes). It has gone through various names. Once just quantity, then ct_quantity, then t1_quantity, now fixed_quantity. It is a quantity where the Unit is fixed at runtime. All suggestions for alternate names are welcome.
Abstract quantity?
An abstract quantity is a quantity without a numeric value or a conversion factor. It still conforms to dimensional analysis and dimensional math. In fact the abstract quantity concept (small c) has now been gobbled up by the all encompassing Static Unit concept.
I am confused. What is a quantity without a numeric value? Just a unit? I don't see the reason for a quantity without a value. Just the name quantity implies a value.
Named quantity?
A named quantity has a name. In practise in Quan-0_2_0 this means that, where U is a model of StaticUnit and is_named_quantity<U>::value is true, that get_named_quantity_traits<U>::type , returns a traits class, which provides useful information, such as the name of the quantity and other information mainly useful for I/O purposes.
I assume that this mean that the unit has a special name, and additional information?
Concrete quantity?
A concrete quantity is a quantity which has a unit and a numeric value.
Same confusion as with abstract quantity. Isn't abstract quantity just the unit? I
Anonymous quantity?
An anonymous quantity doesnt have a name, kind of the opposite of a named quantity. is_named_quantity<U>::value is false for anonymous quantities in the next version of Quan, and so their Named Quantity Traits class is effectively void.
Does this mean that the name will be derived, like in m/s^2 ? Or that there is no unit symbol at all that can be printed? Again this seems to be a property of the unit of the quantity. Wouldn't unnamed unit be a better name?
Static unit?
This is a proper C++ Concept. Effectively its a compile time database which can be queried about various aspects of a particular fixed_quantity. It is a template parameter to fixed_quantity:
fixed_quantity<StaticUnit,NumericType>
United value?
It is a detail of the implementation. Has it leaked into the docs somewhere? If so I will remove it as it may change without notice.
A general-purpose library should use simple terms and a bare minimum of names.
If I understand the above concepts correctly then we only need three terms: - named unit - unnamed unit - quantity (value + unit) Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:09128591-A3C8-4432-A934-9C01B9042AF7@itp.phys.ethz.ch...
Andy little wrote
Eric leemings wrote
Abstract quantity?
An abstract quantity is a quantity without a numeric value or a conversion factor. It still conforms to dimensional analysis and dimensional math. In fact the abstract quantity concept (small c) has now been gobbled up by the all encompassing Static Unit concept.
I am confused. What is a quantity without a numeric value? Just a unit? I don't see the reason for a quantity without a value. Just the name quantity implies a value.
I was taught at school to do dimensional analysis checks manually. For example force = mass * acceleration; M = mass L = length T = time; force == M * L / T^2 acceleration = L/T^2 Therefore (M* L/T^2) = (M) * ( L/ T^2) In this case its just dimensional math, no value is involved. FWIW AbstractQuantity isnt a Concept in the latest version of Quan, its just a class template used by the default implementation.
Named quantity?
A named quantity has a name. In practise in Quan-0_2_0 this means that, where U is a model of StaticUnit and is_named_quantity<U>::value is true, that get_named_quantity_traits<U>::type , returns a traits class, which provides useful information, such as the name of the quantity and other information mainly useful for I/O purposes.
I assume that this mean that the unit has a special name, and additional information?
Yes. The classic example is torque and energy. They are dimensionally equivalent, but have different output Energy in Joules is output as J.. Torque as N.m Note: I am aware that the output as it stands is pretty fixed ( It is still useful for getting some output in quick examples and tests though), but One day hopefully it should be possible to use locales and facets or whatever and somehow to customise for various file formats.. I hope that functionality could be added by someone with experience of that type of thing if Quan got into boost , or at least I could get advice on how to go about it. This is the idea anyway of the NamedQuantityTraits Concept.
Concrete quantity?
A concrete quantity is a quantity which has a unit and a numeric value.
Same confusion as with abstract quantity. Isn't abstract quantity just the unit? I
All this has data been moved into the StaticUnit in the latest version of Quan, yes.
Anonymous quantity?
An anonymous quantity doesnt have a name, kind of the opposite of a named quantity. is_named_quantity<U>::value is false for anonymous quantities in the next version of Quan, and so their Named Quantity Traits class is effectively void.
Does this mean that the name will be derived, like in m/s^2 ?
Yes. Or that
there is no unit symbol at all that can be printed?
No, it defaults to something like the above for an anonymous quantity. Again this seems
to be a property of the unit of the quantity. Wouldn't unnamed unit be a better name?
I prefer anonymous FWIW. Someone who writes a letter anonymously does have a name, we just don't know what it is, so that is not quite the same as someone not having a name. Anonymous quantities do represent a particular quantity, but because they arise from calculations, then it is not possible to know which quantity is intended, so it is not possible to know what their name is. The programmer can 'name' a quantity by assigning or initialising a named quantity from an anonymous quantity, when they need to be explicit about what quantity it represents.
Static unit?
This is a proper C++ Concept. Effectively its a compile time database which can be queried about various aspects of a particular fixed_quantity. It is a template parameter to fixed_quantity:
fixed_quantity<StaticUnit,NumericType>
United value?
It is a detail of the implementation. Has it leaked into the docs somewhere? If so I will remove it as it may change without notice.
A general-purpose library should use simple terms and a bare minimum of names.
If I understand the above concepts correctly then we only need three terms:
- named unit - unnamed unit - quantity (value + unit)
Strictly speaking AFAIK the 'value' of a quantity is the numeric value + unit. Otherwise that is quite close to the latest thinking in the latest CVS Version of Quan. It is (almost) summed up in the fixed_quantity definition. fixed_quantity<StaticUnit,NumericType> (A Static Unit is just a Unit where all the data is available at compile time.) regards Andy Little
On Aug 19, 2006, at 2:04 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:09128591-A3C8-4432-A934-9C01B9042AF7@itp.phys.ethz.ch...
Andy little wrote
Eric leemings wrote
Abstract quantity?
An abstract quantity is a quantity without a numeric value or a conversion factor. It still conforms to dimensional analysis and dimensional math. In fact the abstract quantity concept (small c) has now been gobbled up by the all encompassing Static Unit concept.
I am confused. What is a quantity without a numeric value? Just a unit? I don't see the reason for a quantity without a value. Just the name quantity implies a value.
I was taught at school to do dimensional analysis checks manually. For example
force = mass * acceleration;
M = mass L = length T = time;
force == M * L / T^2 acceleration = L/T^2
Therefore (M* L/T^2) = (M) * ( L/ T^2)
In this case its just dimensional math, no value is involved.
This is just a check of units. I would prefer calling them units and not quantities
Named quantity?
A named quantity has a name. In practise in Quan-0_2_0 this means that, where U is a model of StaticUnit and is_named_quantity<U>::value is true, that get_named_quantity_traits<U>::type , returns a traits class, which provides useful information, such as the name of the quantity and other information mainly useful for I/O purposes.
I assume that this mean that the unit has a special name, and additional information?
Yes. The classic example is torque and energy. They are dimensionally equivalent, but have different output
Energy in Joules is output as J.. Torque as N.m
Note: I am aware that the output as it stands is pretty fixed ( It is still useful for getting some output in quick examples and tests though), but One day hopefully it should be possible to use locales and facets or whatever and somehow to customise for various file formats.. I hope that functionality could be added by someone with experience of that type of thing if Quan got into boost , or at least I could get advice on how to go about it. This is the idea anyway of the NamedQuantityTraits Concept.
Concrete quantity?
A concrete quantity is a quantity which has a unit and a numeric value.
Same confusion as with abstract quantity. Isn't abstract quantity just the unit? I
All this has data been moved into the StaticUnit in the latest version of Quan, yes.
OK
Anonymous quantity?
An anonymous quantity doesnt have a name, kind of the opposite of a named quantity. is_named_quantity<U>::value is false for anonymous quantities in the next version of Quan, and so their Named Quantity Traits class is effectively void.
Does this mean that the name will be derived, like in m/s^2 ?
Yes.
Or that
there is no unit symbol at all that can be printed?
No, it defaults to something like the above for an anonymous quantity.
ok, so named quantity has a special unit symbol, and anonymous quantity a default unit symbol?
Again this seems
to be a property of the unit of the quantity. Wouldn't unnamed unit be a better name?
I prefer anonymous FWIW. Someone who writes a letter anonymously does have a name, we just don't know what it is, so that is not quite the same as someone not having a name. Anonymous quantities do represent a particular quantity, but because they arise from calculations, then it is not possible to know which quantity is intended, so it is not possible to know what their name is. The programmer can 'name' a quantity by assigning or initialising a named quantity from an anonymous quantity, when they need to be explicit about what quantity it represents.
Wait, if I multiply quantities (which have units) then also the result will have a unit. E.g. if I divide 10 meters by 2 seconds then I get 5 m/s . I wouldn't call that anonymous since I know the unit: m/s
Static unit?
This is a proper C++ Concept. Effectively its a compile time database which can be queried about various aspects of a particular fixed_quantity. It is a template parameter to fixed_quantity:
fixed_quantity<StaticUnit,NumericType>
United value?
It is a detail of the implementation. Has it leaked into the docs somewhere? If so I will remove it as it may change without notice.
A general-purpose library should use simple terms and a bare minimum of names.
If I understand the above concepts correctly then we only need three terms:
- named unit - unnamed unit - quantity (value + unit)
Strictly speaking AFAIK the 'value' of a quantity is the numeric value + unit.
OK
Otherwise that is quite close to the latest thinking in the latest CVS Version of Quan. It is (almost) summed up in the fixed_quantity definition.
fixed_quantity<StaticUnit,NumericType>
(A Static Unit is just a Unit where all the data is available at compile time.)
OK, this sounds reasonable enough, except that I'm still confused what exactly an anonymous quantity is. Matthias
On 2006-08-20, Matthias Troyer <troyer@itp.phys.ethz.ch> wrote:
On Aug 19, 2006, at 2:04 PM, Andy Little wrote:
I was taught at school to do dimensional analysis checks manually. For example force = mass * acceleration; M = mass L = length T = time; force == M * L / T^2 acceleration = L/T^2 Therefore (M* L/T^2) = (M) * ( L/ T^2) In this case its just dimensional math, no value is involved. This is just a check of units. I would prefer calling them units and not quantities
Nope, it's a check of dimensionality, not units. A check of units would be one that found an error in: m/s = ft/min The difference between units and dimensionality incorrectness is that units can be converted (if they are compatible). They are (sometimes) compatible when their dimensionality is the same. If your dimensionality is incorrect, you are screwed. phil, back to my rock to hide under -- change name before "@" to "phil" for email
On Aug 20, 2006, at 3:09 PM, Phil Richards wrote:
On 2006-08-20, Matthias Troyer <troyer@itp.phys.ethz.ch> wrote:
On Aug 19, 2006, at 2:04 PM, Andy Little wrote:
I was taught at school to do dimensional analysis checks manually. For example force = mass * acceleration; M = mass L = length T = time; force == M * L / T^2 acceleration = L/T^2 Therefore (M* L/T^2) = (M) * ( L/ T^2) In this case its just dimensional math, no value is involved. This is just a check of units. I would prefer calling them units and not quantities
Nope, it's a check of dimensionality, not units.
A check of units would be one that found an error in: m/s = ft/min
The difference between units and dimensionality incorrectness is that units can be converted (if they are compatible). They are (sometimes) compatible when their dimensionality is the same.
If your dimensionality is incorrect, you are screwed.
phil, back to my rock to hide under
OK, then it checks dimensions, but still not quantities
"Phil Richards" <news@derived-software.ltd.uk> wrote in message news:20060820130917.7C4199D2FE@derisoft.derived-
Nope, it's a check of dimensionality, not units.
A check of units would be one that found an error in: m/s = ft/min
The difference between units and dimensionality incorrectness is that units can be converted (if they are compatible). They are (sometimes) compatible when their dimensionality is the same.
If your dimensionality is incorrect, you are screwed.
phil, back to my rock to hide under
Thanks for crawling out ! (Basically I'm with you on this. Unfortunately, as usual, the Americans have to do everything differently ) ;-) regards Andy Little
"Matthias Troyer"
On Aug 19, 2006, at 2:04 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:09128591-A3C8-4432-A934-9C01B9042AF7@itp.phys.ethz.ch...
Andy little wrote
<...>
force = mass * acceleration;
M = mass L = length T = time;
force == M * L / T^2 acceleration = L/T^2
Therefore (M* L/T^2) = (M) * ( L/ T^2)
In this case its just dimensional math, no value is involved.
This is just a check of units. I would prefer calling them units and not quantities.
Having had correspondence from various people, I am now fairly sure that the Americans have a different concept of a unit than (at least) Europeans. <...>
Does this mean that the name will be derived, like in m/s^2 ?
Yes.
Or that
there is no unit symbol at all that can be printed?
No, it defaults to something like the above for an anonymous quantity.
ok, so named quantity has a special unit symbol, and anonymous quantity a default unit symbol?
Basically the output routine interrogates the StaticUnit as to whether its a named quantity. If not then it basically spews out a list of non zero dimensions. There are some other complexities but that is the gist of it. In case of named quantities it looks at The named quantity traits class. Si quantities have some manipulations done to provide a prefix which is then applied to a symbol which is in the traits class. For Non SI named quantities it is assumed that there is an output overload for that particular unit . No formula can be applied by definition as these are just a rag bag of odd units with funny names, which the SI system wants to get rid of anyway.
The programmer can 'name' a quantity by assigning or initialising a named quantity from an anonymous quantity, when they need to be explicit about what quantity it represents.
Wait, if I multiply quantities (which have units) then also the result will have a unit. E.g. if I divide 10 meters by 2 seconds then I get 5 m/s . I wouldn't call that anonymous since I know the unit: m/s
It would be possible to try to predict a named quantity result of a calculation for some cases, but it would add a lot of complexity, and I am fairly confident that the prediction would be wrong in some cases and not possible in others. I took the simple option and decided not to bother even to try to guess. ( In fact the rules are somewhat more complicated, for example Q+Q --> Q does return what went in, etc, but you would need to read the docs in some detail ) The programmer will know which quantity they want, when they want to be specific, and in many cases of temporaries it isnt really important. The main use of named quantities is for 'pretty' output.
fixed_quantity<StaticUnit,NumericType>
(A Static Unit is just a Unit where all the data is available at compile time.)
OK, this sounds reasonable enough, except that I'm still confused what exactly an anonymous quantity is.
The distinction between a named quantity and an anonymous quantity is really only important for input/output purposes, but that isnt trivial.One area I would like to investigate is trying to get Quan to output STEP files http://en.wikipedia.org/wiki/ISO_10303 which I have been told Quan would be very suitable for. Unfortunately the Spec looks to be quite expensive though, so I don't know very much about it. regards Andy Little
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
OK, this sounds reasonable enough, except that I'm still confused what exactly an anonymous quantity is.
I realise I didnt answer this question. In the calculation: force * distance; The programmer might be dealing with a force acting at a moment, or the energy required to move an object. There is no way to tell from the calculation which. (One could apply some angular tag to torque, but after experimenting with this I found it rather vague and fussy). Therefore, as there is no way to tell which quantity is intended I don't try, so the result is an anonymous quantity. One could apply various rules (for instance length * length --> area), but as I can't apply a rule easily to the above case, I opted to apply the same rule to every case of dimensionful multiplication and division, which was to return an anonymous quantity and leave it to the programmer to decide which quantity they were dealing with. regards Andy Little
On Aug 20, 2006, at 8:36 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
OK, this sounds reasonable enough, except that I'm still confused what exactly an anonymous quantity is.
I realise I didnt answer this question.
In the calculation:
force * distance;
The programmer might be dealing with a force acting at a moment, or the energy required to move an object. There is no way to tell from the calculation which. (One could apply some angular tag to torque, but after experimenting with this I found it rather vague and fussy).
Therefore, as there is no way to tell which quantity is intended I don't try, so the result is an anonymous quantity.
One could apply various rules (for instance length * length --> area), but as I can't apply a rule easily to the above case, I opted to apply the same rule to every case of dimensionful multiplication and division, which was to return an anonymous quantity and leave it to the programmer to decide which quantity they were dealing with.
As far as I understand, the named quantities just use special symbols then? Actually Nm is a valid unit for both energy and torque, but you sometimes want it printed as J and sometimes as Nm, and you use named quantities to force this? Is this correct? Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:733C7C06-D235-453C-A2CA-CCF3F7DFA165@itp.phys.ethz.ch...
On Aug 20, 2006, at 8:36 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
OK, this sounds reasonable enough, except that I'm still confused what exactly an anonymous quantity is.
I realise I didnt answer this question.
In the calculation:
force * distance;
The programmer might be dealing with a force acting at a moment, or the energy required to move an object. There is no way to tell from the calculation which. (One could apply some angular tag to torque, but after experimenting with this I found it rather vague and fussy).
Therefore, as there is no way to tell which quantity is intended I don't try, so the result is an anonymous quantity.
One could apply various rules (for instance length * length --> area), but as I can't apply a rule easily to the above case, I opted to apply the same rule to every case of dimensionful multiplication and division, which was to return an anonymous quantity and leave it to the programmer to decide which quantity they were dealing with.
As far as I understand, the named quantities just use special symbols then? Actually Nm is a valid unit for both energy and torque, but you sometimes want it printed as J and sometimes as Nm, and you use named quantities to force this? Is this correct?
Yes. The ability to identify a particular quantity must have a variety of uses. Quan provides a means to get at the name: #include <quan/torque.hpp> #include <quan/energy.hpp> #include <iostream> int main() { typedef quan::meta::get_named_quantity_traits< quan::torque::N_m::unit >::type torque_traits; typedef quan::meta::get_named_quantity_traits< quan::energy::J::unit >::type energy_traits; std::cout << torque_traits::abstract_quantity_name() <<'\n'; std::cout << energy_traits::abstract_quantity_name() <<'\n'; } /* output: torque energy */ I could imagine that being useful to look up some custom data in a map or to access a database for example. regards Andy Little
On Aug 22, 2006, at 4:54 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:733C7C06-D235-453C-A2CA-CCF3F7DFA165@itp.phys.ethz.ch...
On Aug 20, 2006, at 8:36 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
OK, this sounds reasonable enough, except that I'm still confused what exactly an anonymous quantity is.
I realise I didnt answer this question.
In the calculation:
force * distance;
The programmer might be dealing with a force acting at a moment, or the energy required to move an object. There is no way to tell from the calculation which. (One could apply some angular tag to torque, but after experimenting with this I found it rather vague and fussy).
Therefore, as there is no way to tell which quantity is intended I don't try, so the result is an anonymous quantity.
One could apply various rules (for instance length * length --> area), but as I can't apply a rule easily to the above case, I opted to apply the same rule to every case of dimensionful multiplication and division, which was to return an anonymous quantity and leave it to the programmer to decide which quantity they were dealing with.
As far as I understand, the named quantities just use special symbols then? Actually Nm is a valid unit for both energy and torque, but you sometimes want it printed as J and sometimes as Nm, and you use named quantities to force this? Is this correct?
Yes.
The ability to identify a particular quantity must have a variety of uses. Quan provides a means to get at the name:
#include <quan/torque.hpp> #include <quan/energy.hpp> #include <iostream> int main() { typedef quan::meta::get_named_quantity_traits< quan::torque::N_m::unit
::type torque_traits;
typedef quan::meta::get_named_quantity_traits< quan::energy::J::unit
::type energy_traits;
std::cout << torque_traits::abstract_quantity_name() <<'\n'; std::cout << energy_traits::abstract_quantity_name() <<'\n';
} /* output: torque energy */
I could imagine that being useful to look up some custom data in a map or to access a database for example.
I have a question here: what is the purpose of these named quantities - is it to output J instead of kgm^2s^2 for energy and Nm instead of kgm^2s^2 for torque? - is it to prevent adding energy and torque? Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:14AD1E01-8077-42A7-A25E-5B5AF8AB1EFA@itp.phys.ethz.ch...
I have a question here: what is the purpose of these named quantities - is it to output J instead of kgm^2s^2 for energy and Nm instead of kgm^2s^2 for torque?
Basically yes. Way back someone requested that they be differentiated, so I differentiated them and hence (BTW) the notion of an anonymous quantity was born as a logical result of not being able to distinguish the two in some cases. After all torque is a vector quantity and energy is a scalar quantity, so they are quite different. One could output energy units as N.m , but the joule is the more well known SI energy unit, so it helps to put things in a familiar context. Also there are various non SI units which specifically mean torque, such as (reading from the SI manual) dyne centimeter, kilogram-force meter, etc. And for energy: erg per square centimeter second, watt per square inch etc..
- is it to prevent adding energy and torque?
It could be in Quan, by more querying of the unit and disallowing the calculation in this case. At one point Quan (in a previous incarnation) did do this, but then maybe there are situations where adding or comparing torque and energy is appropriate, so I opted for the freer semantics. If there is a proof of some sort that they can never be compared or added then I will change the current semantics, but I am not enough of an expert to say for sure. regards Andy little
On Aug 23, 2006, at 8:40 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:14AD1E01-8077-42A7-A25E-5B5AF8AB1EFA@itp.phys.ethz.ch...
I have a question here: what is the purpose of these named quantities - is it to output J instead of kgm^2s^2 for energy and Nm instead of kgm^2s^2 for torque?
Basically yes. Way back someone requested that they be differentiated, so I differentiated them and hence (BTW) the notion of an anonymous quantity was born as a logical result of not being able to distinguish the two in some cases.
After all torque is a vector quantity and energy is a scalar quantity, so they are quite different. One could output energy units as N.m , but the joule is the more well known SI energy unit, so it helps to put things in a familiar context.
Also there are various non SI units which specifically mean torque, such as (reading from the SI manual) dyne centimeter, kilogram-force meter, etc.
And for energy: erg per square centimeter second, watt per square inch etc..
OK, to be able to output specific unit symbols is a good thing.
- is it to prevent adding energy and torque?
It could be in Quan, by more querying of the unit and disallowing the calculation in this case. At one point Quan (in a previous incarnation) did do this, but then maybe there are situations where adding or comparing torque and energy is appropriate, so I opted for the freer semantics. If there is a proof of some sort that they can never be compared or added then I will change the current semantics, but I am not enough of an expert to say for sure.
I am strictly against any disallowing of calculations. Just consider the following pseudo code (I do not refer to any specific implementation but hope the types are self-explanatory unit::force::N force; unit::length::m distance; unit::energy::J energy; unit::torque::Nm torque; energy = force*distance; // should this be allowed? torque = force*distance; // should this be allowed? I think that in both cases the implicit conversion from the (annonymous?) quantity force*distance to either energy or torque. I think that to make the library usable one needs to allow these conversions. If one want to prevent the operations then because one is a vector scalar product (the energy) and the other a vector cross product (the torque) then this should be done at the level of the value_type of the quantity and not at the unit level. Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:0F6E6AED-1E91-4356-A72E-AFA684879045@itp.phys.ethz.ch...
On Aug 23, 2006, at 8:40 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:14AD1E01-8077-42A7-A25E-5B5AF8AB1EFA@itp.phys.ethz.ch...
I have a question here: what is the purpose of these named quantities - is it to output J instead of kgm^2s^2 for energy and Nm instead of kgm^2s^2 for torque?
Basically yes. Way back someone requested that they be differentiated, so I differentiated them and hence (BTW) the notion of an anonymous quantity was born as a logical result of not being able to distinguish the two in some cases.
After all torque is a vector quantity and energy is a scalar quantity, so they are quite different. One could output energy units as N.m , but the joule is the more well known SI energy unit, so it helps to put things in a familiar context.
Also there are various non SI units which specifically mean torque, such as (reading from the SI manual) dyne centimeter, kilogram-force meter, etc.
And for energy: erg per square centimeter second, watt per square inch etc..
OK, to be able to output specific unit symbols is a good thing.
- is it to prevent adding energy and torque?
It could be in Quan, by more querying of the unit and disallowing the calculation in this case. At one point Quan (in a previous incarnation) did do this, but then maybe there are situations where adding or comparing torque and energy is appropriate, so I opted for the freer semantics. If there is a proof of some sort that they can never be compared or added then I will change the current semantics, but I am not enough of an expert to say for sure.
I am strictly against any disallowing of calculations. Just consider the following pseudo code (I do not refer to any specific implementation but hope the types are self-explanatory
unit::force::N force; unit::length::m distance;
unit::energy::J energy; unit::torque::Nm torque;
energy = force*distance; // should this be allowed? torque = force*distance; // should this be allowed?
Quan allows this as it stands.
I think that in both cases the implicit conversion from the (annonymous?) quantity force*distance to either energy or torque. I think that to make the library usable one needs to allow these conversions.
The temporary result of force * distance is a so-called anonymous quantity.
If one want to prevent the operations then because one is a vector scalar product (the energy) and the other a vector cross product (the torque) then this should be done at the level of the value_type of the quantity and not at the unit level.
Yes the obvious way to make a quantity a vector quantity is simple. Put it as the value_type of a vector. Currently quan has 2D and 3D vectors in separate namespaces, but it was suggested that it would be more flexible to just have a quan::simple_vector<N_dimensions,quantity> and hopefully that will be implemented at some stage. regards Andy Little
On Aug 24, 2006, at 7:24 PM, Andy Little wrote:
energy = force*distance; // should this be allowed? torque = force*distance; // should this be allowed?
Quan allows this as it stands.
Good.
I think that in both cases the implicit conversion from the (annonymous?) quantity force*distance to either energy or torque. I think that to make the library usable one needs to allow these conversions.
The temporary result of force * distance is a so-called anonymous quantity.
OK
If one want to prevent the operations then because one is a vector scalar product (the energy) and the other a vector cross product (the torque) then this should be done at the level of the value_type of the quantity and not at the unit level.
Yes the obvious way to make a quantity a vector quantity is simple. Put it as the value_type of a vector. Currently quan has 2D and 3D vectors in separate namespaces, but it was suggested that it would be more flexible to just have a quan::simple_vector<N_dimensions,quantity> and hopefully that will be implemented at some stage.
Why not just use a ublas vector or MTL vector with a quan quantity? As i mentioned before I see no reason for reinventing the wheel. I still have not seen your reason for having your own vector classes. Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:E76A322A-1D3B-4B5C-88A0-2B52FD2387EE@itp.phys.ethz.ch... <...>
Why not just use a ublas vector or MTL vector with a quan quantity? As i mentioned before I see no reason for reinventing the wheel. I still have not seen your reason for having your own vector classes.
My use cases for vectors are limited to vectors representing 2 dimensional and 3 dimensional space. I find it convenient to represent a vector in 3 dimensions as a container with 3 elements representing the direction and magnitude projected onto the x, y, z axes. I will certainly look into UBLAS, but my initial impression is that it is quite heavyweight for this task. Though I havent looked at MTL, I would guess that it is even more complex than UBLAS. I will look at MTL2, but so far I have been unable to locate any information on MTL4. For matrices my tests have been limited to homogeneous transformation matrices. In this case the matrix elements for a *simple/obvious* implementation of a matrix for a physical quantity are comprised of various types, comprising of the quantity type, the reciprocal of the quantity and numeric types. It may be possible to somehow 'tag' a numeric matrix as a quantity matrix, but I havent invetigated that. I havent looked into other use cases for linear algebra in association with Quan however. It may be that in the general case ( for large matrices) that it is impractical ( IOW the costs outweigh any possible benefits) to use non-numeric types as the elements, but that remains to be investigated. regards Andy Little
On Aug 24, 2006, at 11:17 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:E76A322A-1D3B-4B5C-88A0-2B52FD2387EE@itp.phys.ethz.ch...
<...>
Why not just use a ublas vector or MTL vector with a quan quantity? As i mentioned before I see no reason for reinventing the wheel. I still have not seen your reason for having your own vector classes.
My use cases for vectors are limited to vectors representing 2 dimensional and 3 dimensional space. I find it convenient to represent a vector in 3 dimensions as a container with 3 elements representing the direction and magnitude projected onto the x, y, z axes. I will certainly look into UBLAS, but my initial impression is that it is quite heavyweight for this task. Though I havent looked at MTL, I would guess that it is even more complex than UBLAS. I will look at MTL2, but so far I have been unable to locate any information on MTL4.
For that purpose the Blitz++ TinyVector class seems ideal, and I think that MTL4 will have something similar.
For matrices my tests have been limited to homogeneous transformation matrices. In this case the matrix elements for a *simple/obvious* implementation of a matrix for a physical quantity are comprised of various types, comprising of the quantity type, the reciprocal of the quantity and numeric types. It may be possible to somehow 'tag' a numeric matrix as a quantity matrix, but I havent invetigated that.
Just use a quantity as value type? What's the problem with that?
I havent looked into other use cases for linear algebra in association with Quan however. It may be that in the general case ( for large matrices) that it is impractical ( IOW the costs outweigh any possible benefits) to use non-numeric types as the elements, but that remains to be investigated.
Why? What should be the problem? Your quantity is just a number, and the rest is compile time type information? Or is a quantity heavier than just a floating point number? Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
Andy Little wrote <...>
For matrices my tests have been limited to homogeneous transformation matrices. In this case the matrix elements for a *simple/obvious* implementation of a matrix for a physical quantity are comprised of various types, comprising of the quantity type, the reciprocal of the quantity and numeric types. It may be possible to somehow 'tag' a numeric matrix as a quantity matrix, but I havent invetigated that.
Just use a quantity as value type? What's the problem with that?
Assume a 2D homogeneous transform matrix intended to transform 2d points. With 9 elements it is possible for the matrix to contain up to 9 separate types T0 - T9 ( T1 , T2, T3) ( T4, T5, T6 ) ( T7, T8, T9) In the transform matrix T1, T2, T4 and T5 are concerned with rotation. IOW to rotate a point through an angle alpha (cos(alpha), sin(alpha), T3 (-sin(alpha), cos(alpha), T6) ( T7, T8, T9) Therefore T1, T2, T4, T5 must be numeric. T7 and T8 represent translation. To translate a homogeneous point [ X Y h], assuming h is a numeric and X and Y are some quantity, T7 and T8 must have the dimensionally equivalent quantity type ( but not necesarily same unit) as X and Y. (In fact in this case T3 and T6 have the reciprocal quantity type of X and Y and T9 is always a numeric representing scaling) Concatenating two matrices of the above type yields another matrix of the same type and multiplying by the point yields a point of the same type. Other matrix operations that I have tried also work from the point of view of dimensional analysis too. Another alternative is to make all the elements of the matrix numeric. In this case h in the homogeneous coordinate [X Y h] would have the same type as X and Y. That isnt as neat though as you have then lost the unit information in T7 and T8 regarding the translation and applying the matrix to a point in different units would give different results.
I havent looked into other use cases for linear algebra in association with Quan however. It may be that in the general case ( for large matrices) that it is impractical ( IOW the costs outweigh any possible benefits) to use non-numeric types as the elements, but that remains to be investigated.
Why? What should be the problem? Your quantity is just a number, and the rest is compile time type information? Or is a quantity heavier than just a floating point number?
I hope I have demonstrated some of the issues in the above example. However I have only limited my experiments to transform matrices. I should probably look at other matrix calculations to see what happens in other cases too. regards Andy Little
On Aug 24, 2006, at 8:02 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
Andy Little wrote <...>
For matrices my tests have been limited to homogeneous transformation matrices. In this case the matrix elements for a *simple/obvious* implementation of a matrix for a physical quantity are comprised of various types, comprising of the quantity type, the reciprocal of the quantity and numeric types. It may be possible to somehow 'tag' a numeric matrix as a quantity matrix, but I havent invetigated that.
Just use a quantity as value type? What's the problem with that?
Assume a 2D homogeneous transform matrix intended to transform 2d points. With 9 elements it is possible for the matrix to contain up to 9 separate types T0 - T9
( T1 , T2, T3) ( T4, T5, T6 ) ( T7, T8, T9)
In the transform matrix T1, T2, T4 and T5 are concerned with rotation. IOW to rotate a point through an angle alpha
(cos(alpha), sin(alpha), T3 (-sin(alpha), cos(alpha), T6) ( T7, T8, T9)
Therefore T1, T2, T4, T5 must be numeric.
T7 and T8 represent translation. To translate a homogeneous point [ X Y h], assuming h is a numeric and X and Y are some quantity, T7 and T8 must have the dimensionally equivalent quantity type ( but not necesarily same unit) as X and Y. (In fact in this case T3 and T6 have the reciprocal quantity type of X and Y and T9 is always a numeric representing scaling)
Wait a moment, matrices are representations of linear operators in a vector space Let us first consider what that vector space here is. For the transformation matrices you mention we have vectors (x, y, 1) that we want to transform. We can choose, as is usual, the same units for the three components. If we now have a linear operator from this vector space to itself, as we have here, then all entries in the matrix must be pure numbers, since we do not change any units. And indeed, if one looks at the matrix you propose than for translations + rotations it actually is (cos(alpha), sin(alpha), dx ) (-sin(alpha), cos(alpha), dy) (0, 0, 1) all entries are pure numbers, and the translations dx and dy are given in terms of the unit chosen for the 1 in the vector. This is actually just what you propose as second option:
Another alternative is to make all the elements of the matrix numeric. In this case h in the homogeneous coordinate [X Y h] would have the same type as X and Y.
But I disagree with your next statement:
That isnt as neat though as you have then lost the unit information in T7 and T8 regarding the translation and applying the matrix to a point in different units would give different results.
No, you have not lost the unit information, since it is encoded in the vector type. And indeed applying a matrix to different vector spaces (e.g. points with different units), should actually give different results!
I hope I have demonstrated some of the issues in the above example. However I have only limited my experiments to transform matrices. I should probably look at other matrix calculations to see what happens in other cases too.
From my 20 years of experience with matrix calculations I have not seen a case yet where different value types are required for different matrix elements - this actually contradicts the definition f a matrix, where all elements are taken from the same number field. Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:A2F5F048-A738-4E3D-A9AC-F34F6FFA181F@itp.phys.ethz.ch...
On Aug 24, 2006, at 8:02 PM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
Wait a moment, matrices are representations of linear operators in a vector space Let us first consider what that vector space here is. For the transformation matrices you mention we have vectors (x, y, 1) that we want to transform. We can choose, as is usual, the same units for the three components. If we now have a linear operator from this vector space to itself, as we have here, then all entries in the matrix must be pure numbers, since we do not change any units. And indeed, if one looks at the matrix you propose than for translations + rotations it actually is
(cos(alpha), sin(alpha), dx ) (-sin(alpha), cos(alpha), dy) (0, 0, 1)
all entries are pure numbers, and the translations dx and dy are given in terms of the unit chosen for the 1 in the vector. This is actually just what you propose as second option:
Another alternative is to make all the elements of the matrix numeric. In this case h in the homogeneous coordinate [X Y h] would have the same type as X and Y.
Well that is OK as far as it goes, however a homogeneous coordinate also has rules and in fact the above statement is probably incorrect as I realised after I posted it. Generally speaking a (non-homogeneous) coordinate [ X, Y] is transformed to a homogeneous coordinate by: [X,Y] -> [ X',Y', h] where X' == X * h and Y' == Y * h. If X and Y are Quantities, lets say lengths in meters, then if h is the same type as X and Y ( IOW h is a length in meters) then X' and Y' are transformed into something dimensionally equivalent to an area in meters^2 , but unfortunately 'h' is still a quantity in meters. OTOH if h is a pure number then X' and Y' are of the same quantity type as X and Y ( IOW lengths), but h is and remains a pure number. The other choice is to make h a reciprocal of length. In this case X and Y are transformed to pure numbers , but h remains a quantity again. IOW if X and Y are dimensioned quantities then h can never have the same type as X' and Y'. The only way that X' Y' and h can be of the same type is the one case where X and Y and h are pure numbers. It follows that, if the elements of coordinate are dimensioned quantities, then some elements of the matrix must also be dimensioned quantities. There is no way around that: Assume: a variable with an L prefix stands for a length, a variable with an N prefix for a number, a variable with an U prefix as having some unknown type yet to be determined Assume a homogeneous coordinate as a row vector v1 == [Lx, Ly, Nh]. assume a column vector v2 == { N1, N2, N3} Multiplying v1 by v2 gives a 1 x1 matrix, M1 whose element, Uv1 = Lx * N1 + Ly * N2 + Nh * N3 However Lx * N1 is a length, Ly * N2 is a length, but Nh * N3 is a pure number and ( if one observes the rules of dimensional analysis), cannot be added to a length. Next assume a column vector v3 == { N1, N2, L3} ( The only change from v1 is that the 3rd element is now a length, not a number) Multiplying v1 by v3 gives a 1 x 1 matrix, M2 whose element, Uv2 = Lx * N1 + Ly * N2 + Nh * L3; In this case the calculation is permitted and the element of M2 is a length. <...>
That isnt as neat though as you have then lost the unit information in T7 and T8 regarding the translation and applying the matrix to a point in different units would give different results.
No, you have not lost the unit information, since it is encoded in the vector type. And indeed applying a matrix to different vector spaces (e.g. points with different units), should actually give different results!
But dimensioned quantities of different units can exist quite happily in one space ( a measurement in kilometers is just as valid as one in meters on this earth for instance), so logically, applying a transform should give the same results independent of the units. regards Andy Little
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:09128591-A3C8-4432-A934-9C01B9042AF7@itp.phys.ethz.ch... Matthias Troyer wrote
Does this mean that the name will be derived, like in m/s^2 ? Or that there is no unit symbol at all that can be printed? Again this seems to be a property of the unit of the quantity. Wouldn't unnamed unit be a better name?
Actually on reflection maybe unnamed is better.. regards Andy Little
participants (4)
-
Andy Little -
Eric Lemings -
Matthias Troyer -
Phil Richards