Haskell-Things / ImplicitCAD

A math-inspired CAD program in haskell. CSG, bevels, and shells; 2D & 3D geometry; 2D gcode generation...
https://implicitcad.org/
GNU Affero General Public License v3.0
1.39k stars 142 forks source link

units function doesn't nest #91

Open chuck-h opened 11 years ago

chuck-h commented 11 years ago

motorplate The "units" primitive added at https://github.com/colah/ImplicitCAD/commit/3258647321c3fc4c6f9223074724355e5d9d2ddd doesn't behave the way I would like when it is nested within a model.

For example, in https://gist.github.com/4391674 I would like the object invoking the "size34_cutout" model to be able to use its own units environment independently of the invoked model. (I want a result like the picture above.)

chuck-h commented 11 years ago

Thinking more about units handling, I am suggesting we add a new data type for "physical-data" such as length. This data type is distinct from a float. Unit processing is performed during conversion between a float and a physical-data variable. Internally, a physical-data variable contains a float value in canonical units (mm is fine). It also contains a rational number representing the applicable exponent for the length units. This distinguishes area and volume data from length data.

Persons familiar with "dimensional analysis" http://en.wikipedia.org/wiki/Dimensional_analysis will recognize that this approach to physical-data types can be generalized to a very rich capability by adding additional exponents applying to mass, time, charge, and temperature. Such an approach allows elegant handling of mass properties (density, center of gravity, etc.) for example.

As suggested by the wikipedia citation, this may fit in with the current activity distinguishing affine points from vectors. The Siano orientation extension is new to me but looks intriguing. At a much simpler level, treating angular values as dimensioned (e.g. distinguishing radians from steradians) and integrating them into the units framework would provide a convenient, consistent way to support radians, degrees, and revolutions as alternative units of measure when converting to and from floats.

I know very little about Haskell but my impression is that this sort of data typing is right up its alley and could come out very elegantly.

Cheers, Chuck

bergey commented 11 years ago

There are several libraries for dimensioned values in haskell: http://www.haskell.org/haskellwiki/Physical_units

I haven't looked at them enough to evaluate them, much less thought through static vs. dynamic matching.