Plane and solid angle inconsistencies in dimensional-tf

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Edit TF.lhs and Quantities.lhs to add plane and solid angles to the 7 base 
dimensions.
2. Attempt to compile and execute Test.hs
3.

What is the expected output? What do you see instead?
Expect Test.hs to compile and run successfully.  Test.hs does not compile 
because
1) in SIUnits.lhs, `lumen' should be defined as `candela * steradian' not 
`candela / steradian' (see luminus flux entry of Table 3 at 
http://physics.nist.gov/cuu/Units/units.html)
2) in Quantities.lhs, DAngularVelocity should be defined as plane angle per 
time,
not DFrequency, which has dimension of reciprocal time.
3) in Quantities.lhs, DRadiantIntensity should be defined as having the 
dimensions of power divided by solid angle
4) in Quantities.lhs, DRadiance should be defined as having the dimensions of 
irradiance divided by solid angle

What version of the product are you using? On what operating system?
dimensional-tf-0.3.0.1 downloaded with cabal.  Fedora 20

Please provide any additional information below.
I fully appreciate that only item 1) above is an error and that the remaining 
three items are a consequence of plane and solid angles being added to the list 
of primary dimensions. But taken as a whole, the items highlight the danger of 
not adding plane and solid angles to the list.  Even though dimensionless, they 
are physical quantities with various units of measure (radian, degree, grad, 
steradian, square degree, etc) that can easily get lost or misused as in item 
1).

Original issue reported on code.google.com by fredhpi...@gmail.com on 12 Apr 2015 at 3:45

[GoogleCodeExporter]

Thanks for the report. I have fixed the definition of `lumen`.

However, I have to decline the request for adding plane and solid angles as 
base dimensions. Doing so would not be consistent with the SI and I believe it 
would likely introduce as many problems and ambiguities as it would remove. For 
example, should dividing two lengths result in a `Dimensionless` or a 
`PlaneAngle`? I recommend wrapping your angles in newtypes when you are 
particularly concerned about mixing them up or misusing them.

Original comment by bjorn.bu...@gmail.com on 24 Apr 2015 at 10:20

• Changed state: Fixed

[GoogleCodeExporter]

The answers to "should dividing two lengths result in `Dimensionless' or a
`PlaneAngle`" are:
1) `Dimensionless' if you have no need to know how the dimensionless number
came in to being in subsequent computation.
2) A ratio of lengths if you're dealing with ratios of mass, for instance,
in subsequent computation.  Adding length ratios and mass ratios is as much
a dimension error as adding length and mass quantities.  And even addition
of length ratios is meaningless if the length
ratios are not on the same basis.
3) The only circumstance in which dividing two lengths should result in a
PlaneAngle is when the numerator is the distance along a circle arc and the
denominator is the radius length of the same circle.

Case 3 above is the exception and should be handled as such (i.e. wrapped
in a function).
Being consistent with SI is laudable, but ignoring the issues that are not
dealt with by SI
will significantly restrict the usefulness of dimensional consistency
software.  I think blind canceling of dimensions during multiplications and
divisions is a fundamental mistake.  Finesse is needed here so as to not
loose valuable information.

BTW, at one time PlaneAngle and SolidAngle were recognized as secondary
dimensions in SI.  For whatever reason they were deprecated.  That does
mean they not important to implementing dimensional consistency software.
I dare say you would not have made the error in the lumen implementation if
SolidAngle had been rigorously accounted for by the code.  Isn't the point
of dimensional consistency software to prevent such errors.

Furthermore dimension consistency software needs to address vector and
affine quantities which SI says nothing about.[?]

Original comment by fredhpi...@gmail.com on 10 May 2015 at 3:24

[GoogleCodeExporter]

Thanks again. I appreciate you taking your time and effort writing this. I 
agree with you in principle, and you are absolutely correct that the error in 
lumen would have been avoided if SolidAngle was tracked in it's own base 
dimension.

On the other hand I don't think it is an easy problem to solve, with an obvious 
implementation and API. As you say: finesse is needed to make it work well. But 
if you are willing to help draft one we could consider adding it.

FYI current and future development of dimensional is being performed on the 
not-yet-on-hackage dimensional-dk (https://github.com/bjornbm/dimensional-dk) 
that is intended to supersede dimensional and dimensional-tf. Nowadays my 
co-maintainer Douglas McClean (https://github.com/dmcclean) actually does most 
of the work on improving and expanding functionality, and he is quite 
sympathetic with your concerns. If you are interested in contributing I suggest 
that you continue the discussion of what a possible implementation could look 
like with him on Github while I follow from the side-lines. I've copied our 
conversation here to https://github.com/bjornbm/dimensional-dk/issues/72 for 
further discussion.

Original comment by bjorn.bu...@gmail.com on 13 May 2015 at 12:34