{"action":"created","issue":{"url":"https://api.github.com/repos/bjornbm/dimensional-dk/issues/72","labels_url":"https://api.github.com/repos/bjornbm/dimensional-dk/issues/72/labels{/name}","comments_url":"https://api.github.com/repos/bjornbm/dimensional-dk/issues/72/comments","events_url":"https://api.github.com/repos/bjornbm/dimensional-dk/issues/72/events","html_url":"https://github.com/bjornbm/dimensional-dk/issues/72","id":75969070,"number":72,"title":"Plane and solid angles as base dimensions?","user":{"login":"bjornbm","id":37268,"avatar_url":"https://avatars.githubusercontent.com/u/37268?v=3","gravatar_id":"","url":"https://api.github.com/users/bjornbm","html_url":"https://github.com/bjornbm","followers_url":"https://api.github.com/users/bjornbm/followers","following_url":"https://api.github.com/users/bjornbm/following{/other_user}","gists_url":"https://api.github.com/users/bjornbm/gists{/gist_id}","starred_url":"https://api.github.com/users/bjornbm/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bjornbm/subscriptions","organizations_url":"https://api.github.com/users/bjornbm/orgs","repos_url":"https://api.github.com/users/bjornbm/repos","events_url":"https://api.github.com/users/bjornbm/events{/privacy}","received_events_url":"https://api.github.com/users/bjornbm/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/bjornbm/dimensional-dk/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-05-13T12:31:14Z","updated_at":"2015-05-13T13:44:12Z","closed_at":null,"body":"See the issue and comments posted by fredhpitts at: https://code.google.com/p/dimensional/issues/detail?id=43\r\n\r\nThey have been copied below for posterity(?) as google code is going away next year.\r\n\r\n@dmcclean feel free to add your thoughts here as well!\r\n\r\n---\r\n\r\n# Issue 43:\tPlane and solid angle inconsistencies in dimensional-tf\r\n\r\n## Reported by fredhpitts, Apr 12, 2015\r\n\r\n**What steps will reproduce the problem?**\r\n1. Edit TF.lhs and Quantities.lhs to add plane and solid angles to the 7 base dimensions.\r\n2. Attempt to compile and execute Test.hs\r\n\r\n**What is the expected output? What do you see instead?**\r\nExpect Test.hs to compile and run successfully.  Test.hs does not compile because\r\n1) 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)\r\n2) in Quantities.lhs, DAngularVelocity should be defined as plane angle per time, not DFrequency, which has dimension of reciprocal time.\r\n3) in Quantities.lhs, DRadiantIntensity should be defined as having the dimensions of power divided by solid angle\r\n4) in Quantities.lhs, DRadiance should be defined as having the dimensions of irradiance divided by solid angle\r\n\r\n**What version of the product are you using? On what operating system?**\r\ndimensional-tf-0.3.0.1 downloaded with cabal.  Fedora 20\r\n\r\n**Please provide any additional information below.**\r\nI 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).\r\n\r\n---\r\n\r\n## Apr 24, 2015 #1 bjorn.buckwalter\r\n\r\nThanks for the report. I have fixed the definition of `lumen`.\r\n\r\nHowever, 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.\r\n\r\n**Status: Fixed**\r\n\r\n---\r\n\r\n## May 9 (3 days ago) #2 fredhpitts via email\r\n\r\nThe answers to \"should dividing two lengths result in `Dimensionless' or a\r\n`PlaneAngle`\" are:\r\n1) `Dimensionless' if you have no need to know how the dimensionless number came in to being in subsequent computation.\r\n2) 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.\r\n3) 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.\r\n\r\nCase 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.\r\n\r\nBTW, 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.\r\n\r\nFurthermore dimension consistency software needs to address vector and affine quantities which SI says nothing about.[?]\r\n\r\n---\r\n\r\n## Today (moments ago) #3 bjorn.buckwalter\r\nThanks 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.\r\n\r\nOn 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.\r\n\r\nFYI 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."},"comment":{"url":"https://api.github.com/repos/bjornbm/dimensional-dk/issues/comments/101667901","html_url":"https://github.com/bjornbm/dimensional-dk/issues/72#issuecomment-101667901","issue_url":"https://api.github.com/repos/bjornbm/dimensional-dk/issues/72","id":101667901,"user":{"login":"dmcclean","id":603347,"avatar_url":"https://avatars.githubusercontent.com/u/603347?v=3","gravatar_id":"","url":"https://api.github.com/users/dmcclean","html_url":"https://github.com/dmcclean","followers_url":"https://api.github.com/users/dmcclean/followers","following_url":"https://api.github.com/users/dmcclean/following{/other_user}","gists_url":"https://api.github.com/users/dmcclean/gists{/gist_id}","starred_url":"https://api.github.com/users/dmcclean/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dmcclean/subscriptions","organizations_url":"https://api.github.com/users/dmcclean/orgs","repos_url":"https://api.github.com/users/dmcclean/repos","events_url":"https://api.github.com/users/dmcclean/events{/privacy}","received_events_url":"https://api.github.com/users/dmcclean/received_events","type":"User","site_admin":false},"created_at":"2015-05-13T13:44:12Z","updated_at":"2015-05-13T13:44:12Z","body":"My notes on this:\r\n\r\n## From a 5/10 email to Bjorn\r\n\r\nRaises some interesting points.\r\n\r\nTaking the easy part first: The point about vector and affine quantities is something we are tackling in -experimental, and it really isn't problematic it's just about legwork. (The one problematic part is that linear is a nice package, but only works when the vector types are also functors, almost worth adding a Numeric.Units.Dimensional.DK.MorallyDubiousFunctorInstance module with the orphan...)\r\n\r\nOn the angle part, I'm personally inclined to agree. There is a widely accepted argument that angles are dimensionless because they are defined to be one length divided by another. On view A this is true and the essence of angles. On another view, view B, (apparently this person's) it is true but unhelpful from an engineering and software engineering perspective. On a third view, C, we should hunt around for-even a slightly twisted-definition of angle where this isn't the case so that angles can have dimensions.\r\n\r\nOn one hand, I like the fact that we are playing it straight down the line in terms of the NIST/BIPM/UCUM documents. On the other hand though, I'm halfway between B and C. There's a lot to be gained from an engineering perspective by tracking it. AFAICS it's impossible to do both without splitting the entire ecosystem, which stinks because you lose the chance for dimensional to be a strong basis for interoperation between libraries that deal with physical things. I think the best you can hope for is a convenient and functional DropAngles tyoe family that zeroes out the 8th and 9th base dimensions, and the obvious term level function that goes with it.\r\n\r\nIf you make the jump, it does work out and is pretty nice, except for its non-standards-compliance. You change the types of all the trig functions in the obvious way. The one big problem I had with it, which needs some thinking, is that there are two kinds of vector cross products, one common one that introduces an angle^-1, e.g. r x F, w x (r1 - r2). But try as I might, I can't twist things enough to get that to be the case in the Lorentz force equation, unless somehow the B-field is carrying a angle^-1 that I can't see.\r\n\r\nAt any rate, with the smell of the two cross product operators, it all worked out when I compiled my autopilot program against a prototype version that tracked these dimensions, and caught one goof up in some flight plan code on a branch I had never actually tried in the simulator.\r\n\r\nPersuasive arguments on both sides of this one.\r\n\r\n## From a follow up email of later the same day\r\n\r\nPossible line of argument for view C over view B is that angles measured on the sphere are still very useful, and *locally* look just like angles on the plane, but the angle = arc length / radius definition doesn't work in that setting, and so you need a whole new definition of \"spherical angle\" and to jiggle things around and embed S2 in R3 to use the arc length / radius definition operationally. If you accept that angles have a dimension, the situation is more cohesive."}}