Buddha Buck wrote: > Jon Lang wrote: >> Here's my proposal for how to handle dimensionality in Perl 6: >> >> Create a "units" trait that is designed to attach to any Numeric >> object. Dimensional information gets stored as a baggy object - that >> is, something that works just like a Bag, except that the count can >> go negative. (I don't know if the count should be a signed integer or >> a Num; what happens in dimensional analysis when you try to take the >> square root of two inches?) Overload the Numeric operators to >> properly track the units as well as performing their normal >> activities. Add one or two methods that allow you to easily extract >> the raw number and/or the units. > > An added complication is "dimensionality". ergs, joules, btu and eV > are all units of energy, and it isn't unreasonable to want to add or > subtract energies of different units (my house used (100 therm + > 8000kWh) of energy last month, for example). However, it is incorrect > to add ergs and Newtons, since they are of different dimensionality.
Right. And in the basic package, it would be the programmer's responsibility to convert therms to kWh, or vice versa, before the addition takes place. And just like Perl 6 implements Instant without reference to a specific calendar system, leaving that to be implemented by appropriate modules, dimensionality would leave the implementation of specific systems of measurement to appropriate modules. With that in mind, your further suggestions would work well for the purpose of defining such a module: > The more robust units/dimensional analysis packages I've seen might > not allow one to add therms and kWh, but they do know that therms and > kWh are both [ML^2/T^2], I believe at the time I was looking at > JScience's work on JSR-275. In this setup, when units are registered, > they are given a dimensionality (essentially, a "baggy" of > dimensions), and values are given a "baggy" of units (and thus an > implicit "baggy" of dimensions, the union of the dimensions of the > units). I was using "Baggy" to describe an as-yet-hypothetical role that is to Bags and Sets as Numeric is to Num, Rat, Int, Complex, and so on. The actual type for units would probably best be called an "SBag", where the S stands for "Signed" (meaning that its count can be negative as well as positive). That said, it might need to be a RatBag, or possibly even a NumBag, if we want to leave open the possibility of fractal dimensions. Still, I'm thinking that an SBag would be good enough to start with. Your idea of having a registered unit be associated with an SBag of dimensions (e.g., ML^2T^-2) would be good for allowing more intelligent exceptions, and would cover what I was talking about in terms of defining what kind of value a unit measures. > I don't think a Num is necessary, but I could see a Rat. As is, is Duration implemented by means of a Num, or a Rat? Whichever it is, that's the type that the difference of two Instances would return (properly tagged with seconds, of course). -- Jonathan "Dataweaver" Lang
