Weblogs Forum - Representing Units of Measure

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Representing Units of Measure

15 replies on 2 pages. Most recent reply: Sep 27, 2005 1:30 PM by Max Lybbert

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 15 replies on 2 pages [ 1 2 | » ]

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Representing Units of Measure (View in Weblogs)

Posted: Sep 23, 2005 6:59 AM

Summary
Various musings about how to deal with units of measure in the Heron graphics library.

I am [hopefully] laying the foundation for the standard graphical library for Heron and I have been learning about Scalable Vector Graphics (SVG). I am trying to keep my fingers on the pulses of various technologies in order to ensure easy interoperability. For instance, it would be nice if the various primitive drawing functions could be done just as easily to a bitmap, as to an SVG file.

Anyway, that said, one thing I notice about SVG, HTML, CSS, etc., is that they usually support multiple units of measure: pixels, cm, inches, points, and percent. Most library API's I am familiar with only give one option: pixels. This raises some of the following questions:

Is it truly desirable to support multiple units of measure?
Is it reasonable to expect units of measure to be mixed: i.e. point(pixels(24), percent(50))
Should I introduce new types for each unit of measure?
Should I try and modify the language grammar so that syntax like: point(24 pixels, 50 percent) was legal?
If I did allow units of measure in a natural syntax would that mean the expression: value unit means unit(value)?
In the above example is unit a type or a function (or both)?
If value type meant type(value), wouldn't it be logical to completely remove type(value) type-casting syntax to avoid confusion?

I am only scratching the surface of the topic of units of measure. In physics units of measure are a very big deal. For those interested in further exploring the topic of units of measure as types, here are some related links:

Andrew Kennedy: Publications on Units of Measure, specifically his introduction is intriguing.
Representing Dimensions, discusses a Template Metaprogramming approach to the problem of units of measure in C++.
Frink is a programming language which specializes in dealing with units of measure.
Measure Twice, Cut Once - Discusses the basic concepts and issues pertaining to representing units of measure in code

As usual, any ideas or suggestions are most welcome.

Michel Parisien

Posts: 25
Nickname: kriggs
Registered: Jul, 2005

Re: Representing Units of Measure

Posted: Sep 23, 2005 7:49 AM

> Is it truly desirable to support multiple units of measure?
Yes. Pixel for screens, point for printers, percentage for resizeability. The other units are just aliases for these.

> Is it reasonable to expect units of measure to be mixed: i.e. point(pixels(24), percent(50))
Yes. I would take it a step further, because this only shows part of it's application. I would suggest you be able to mix pixels and percent in a single dimension, such as point(pixel(24)+percent(50), pixel(0)). Not sure if SVG is a big fan of that though. It makes it so resizing isn't only about zooming in and out, but is more flexible. If you don't see why you might want that, I'm willing to talk more about it.

> Should I try and modify the language grammar so that syntax like: point(24 pixels, 50 percent) was legal?
Depends on philosophy, but I don't think this is something that would be terribly worth it if you haven't compromized language grammar similarly until now. Personally, I do not find point(24 pixels, 50 percent) any more readable than point(pixel(24), percent(50)). And modifying the syntax would force people to learn a new language exception, and we all know about examples such as Perl where everything has its own syntax. Good language, but not the fastest to pick up.

Morel Xavier

Posts: 73
Nickname: masklinn
Registered: Sep, 2005

Re: Representing Units of Measure

Posted: Sep 23, 2005 12:43 PM

> <li>Is it truly desirable to support multiple units of
> measure?</li>
Yes, if only because you do not know who will use heron.

> <li>Is it reasonable to expect units of measure to be
> mixed: i.e. <tt>point(pixels(24), percent(50))</tt></li>
Yes, and don't forget things like "em" and "ex". I'd suggest doing some talking with designers and typographs for they may -- after all -- be the one to use the library.

> <li>Should I introduce new types for each unit of
> measure?</li>
What do you mean by "type"?
Is a heron type a mere object or something more deeply rooted into the core of the language (such as what Python's types once were).

If it's a mere object, i'd say yes, and make them inherit from a base measurement, and allow the user to convert between the units within a given graphing context

> <li>Should I try and modify the language grammar so that
> syntax like: <tt>point(24 pixels, 50 percent)</tt> was
> legal?</li>
I really doubt it. It sure looks somewhat nicer, but I don't quite see the point, except that it'd add complexity to Heron and would probably make people wish that this syntax would be extended to each and every type of the language, and before you'll know it you'll be wondering how the hell you could use multiple arguments with that horrid piece of syntactic sugar

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Representing Units of Measure

Posted: Sep 23, 2005 3:38 PM

I personally don't see much value in using pixels for measurement (other than when working w/ icons of a particular pixel size), since pixels no longer mean any particular unit of measure (they were once 1/72 in "square" [because they're rectangular, not square]).

But I do see value in mixing units of measure, as it makes placing something 1 in left of center much easier. Or "right justifying" several lines anywhere other than the right margin.

However, the "right" way to do that would be to use Model-View-[Controller], and then you'd have to choose a canonical unit.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Representing Units of Measure

Posted: Sep 23, 2005 4:02 PM

> > <li>Is it truly desirable to support multiple units of
> > measure?</li>
> Yes, if only because you do not know who will use heron.
>
> > <li>Is it reasonable to expect units of measure to be
> > mixed: i.e. <tt>point(pixels(24),
> percent(50))</tt></li>
> Yes, and don't forget things like "em" and "ex". I'd
> suggest doing some talking with designers and typographs
> for they may -- after all -- be the one to use the
> library.

Yes. There a couple more as well: point (1/72 inch) and pica (1/6 inch). I figure I will follow suit with the css standard: http://www.w3schools.com/css/css_units.asp

> What do you mean by "type"?
> Is a heron type a mere object or something more deeply
> rooted into the core of the language (such as what
> Python's types once were).

A heron type is a class, an interface, or one of the built-in literal types (_int, _float, _char, _string, _bool).

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Representing Units of Measure

Posted: Sep 23, 2005 4:06 PM

> I personally don't see much value in using pixels for
> measurement (other than when working w/ icons of a
> particular pixel size), since pixels no longer mean any
> particular unit of measure (they were once 1/72 in
> "square" [because they're rectangular, not square]).

For efficient drawing to bitmaps and to hardware it makes sense to use the pixel.

> However, the "right" way to do that would be to use
> Model-View-[Controller], and then you'd have to choose a
> canonical unit.

How specifically would use MVC pattern to model the graphics? Also what do you mean by a canonical unit?

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Representing Units of Measure

Posted: Sep 23, 2005 5:08 PM

> > I personally don't see much value in using pixels for
> > measurement (other than when working w/ icons of a
> > particular pixel size), since pixels no longer mean any
> > particular unit of measure (they were once 1/72 in
> > "square" [because they're rectangular, not square]).
>
> For efficient drawing to bitmaps and to hardware it makes
> sense to use the pixel.

OK, you're right. Although I will say that many web designers should have their pixel-using priveleges revoked (http://esr.ibiblio.org/?p=212).

> How specifically would use MVC pattern to model the
> graphics? Also what do you mean by a canonical unit?

Not so much the graphics as keeping track of the size of any particular widget.

Simply put, if I start with a 5 px object and add 2 in. to it, you're going to have to store the new size of the object somewhere. You could have several fields, one for each unit of size, and then keep them updated whenever the size changed. But then you'd have to remember to keep them all updated. You'd also have the problem of rounding errors on screens where an inch was not exactly 72 (or 94, or whatever) pixels long (eg., if an inch was really 72.25 pixels). That error may not amount to much, but it would exist.

So the solution is to pick a single unit of measure that will be the Gospel Truth, and all other units will be calculated based on the Gospel Truth (or canon -- Greek for "rule, measure, standard", http://essenes.net/odict.htm but you have to scroll), and rounded as needed. The Gospel Truth value would be the model, the other values would all be the views, and anything that changed the Gospel Truth and updated the others would be the controller.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Representing Units of Measure

Posted: Sep 23, 2005 10:03 PM

> OK, you're right. Although I will say that many web
> designers should have their pixel-using priveleges revoked
> (http://esr.ibiblio.org/?p=212).

I can't disagree with that.

> > How specifically would use MVC pattern to model the
> > graphics? Also what do you mean by a canonical unit?
>
> Not so much the graphics as keeping track of the size of
> any particular widget.
>
> Simply put, if I start with a 5 px object and add 2 in. to
> it, you're going to have to store the new size of the
> object somewhere. You could have several fields, one for
> each unit of size, and then keep them updated whenever the
> size changed. But then you'd have to remember to keep
> them all updated. You'd also have the problem of rounding
> errors on screens where an inch was not exactly 72 (or 94,
> or whatever) pixels long (eg., if an inch was really 72.25
> pixels). That error may not amount to much, but it would
> exist.
>
> So the solution is to pick a single unit of measure that
> will be the Gospel Truth, and all other units will be
> calculated based on the Gospel Truth (or canon -- Greek
> for "rule, measure, standard",
> http://essenes.net/odict.htm but you have to scroll), and
> rounded as needed. The Gospel Truth value would be the
> model, the other values would all be the views, and
> anything that changed the Gospel Truth and updated the
> others would be the controller.

That is indeed one solution, but is not the the only one, nor neccessarily the "right" one as you stated earlier. It also does not solve the rounding error problem. With an MVC approach is that you are always continually converting, and accumulating error. 12 cm + 12 cm != 24 cm if the underlying model is inches.

I believe the better solution is to store the unit value, and use the type of the object to represent the unit of measure. This way 12 cm + 12 cm == 24 cm, and 12 in + 12 == 24 inches.

Tim LS

Posts: 37
Nickname: parchandri
Registered: Jul, 2005

Re: Representing Units of Measure

Posted: Sep 23, 2005 10:47 PM

RE: Should I try and modify the language grammar so that syntax like: point(24 pixels, 50 percent) was legal?

I like it! Seriously, this would make coding graphical stuff much simpler to do.

Morel Xavier

Posts: 73
Nickname: masklinn
Registered: Sep, 2005

Re: Representing Units of Measure

Posted: Sep 23, 2005 11:32 PM

> I believe the better solution is to store the unit value,
> and use the type of the object to represent the unit of
> measure. This way 12 cm + 12 cm == 24 cm, and 12 in + 12
> == 24 inches.

You could use the same object for every unit (the only difference being instanciation and "base unit", that is the unit your object/variable was created for), store every value exactly in an associative array or something like that, and only convert (using the informations of the context your measure is associated to and the base unit used) to your result through a virtual property.

For example, val = 12 cm
val += 5 in + 13 mm

Would yield an object along the lines of

* base_unit: cm
* * metrics: 133 # Automatic conversion of multiples (km, m, cm, mm) to a base chosen one
* * imperial: 5
* property length (or something), readonly, that would convert everything to base_unit, and several converting methods for the others (or a single one asking for a type argument?)

And adding a unitless value (regular int/float) would make the language assume the usage of base_value.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Representing Units of Measure

Posted: Sep 24, 2005 7:59 AM

> converting, and accumulating error. 12 cm + 12 cm != 24 cm
> if the underlying model is inches.

That is a particularly bad example I chose.

This one works better =

Using google for my calculations:
100 cm to inches == 39.3700787
99 cm to inches == 38.976378
1 cm to inch == 0.393700787 != (39.3700787 - 38.976378)

My point still holds, I believe it is better to store values in their native units as long as possible. I am currently working on a polymorphic unit type, which should facilitate calculations and representations.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Representing Units of Measure

Posted: Sep 24, 2005 8:22 AM

> RE: Should I try and modify the language grammar so that
> syntax like: point(24 pixels, 50 percent) was legal?
>
> I like it! Seriously, this would make coding graphical
> stuff much simpler to do.

I agree it is very elegant, but there are some side-effects that concern me. Just so we are on the same page you are saying that:

canvas.line_to(24 inches, 12 pixels)

is significantly easier than:

canvas.line_to(inches(24), pixels(12))

?

If I did allow the first form, I feel I could only justify it as a postfix form of type cast. What I have to consider is the potential for this feature to be abused, and creation of obfuscated code.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Representing Units of Measure

Posted: Sep 25, 2005 5:11 AM

> > RE: Should I try and modify the language grammar so
> that
> > syntax like: point(24 pixels, 50 percent) was legal?
> >
> > I like it! Seriously, this would make coding graphical
> > stuff much simpler to do.

You know I think I am being overly cautious. The advantages of this kind of notation would be clear for physicists and engineers as well as people working with graphics. I thought about how in C++ there are more than a half-dozen methods to accomplish a cast so, relatively speaking, having two in heron is not so bad.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Representing Units of Measure

Posted: Sep 26, 2005 3:53 PM

/* That is indeed one solution, but is not the the only one, nor neccessarily the "right" one as you stated earlier.
*/

Conceded.

/* It also does not solve the rounding error problem. With an MVC approach is that you are always continually converting, and accumulating error. 12 cm + 12 cm != 24 cm if the underlying model is inches.
*/

Partly conceded. There is an accumulated error, but it would likely be "hidden" in the sense that the widget's size would never disagree with itself. But I have to concede that it would be perfectly acceptable to keep several slots and add them up to determine the widget's size, and that any rounding error in that system would be no worse than in mine.

And, since I was complaining about rounding errors on the order of 1/288 in. (from simple manufacturing margins of error/tolerances), it's pretty hard to defend my original post's elitism.

/* I believe the better solution is to store the unit value, and use the type of the object to represent the unit of measure. This way 12 cm + 12 cm == 24 cm, and 12 in + 12 == 24 inches.
*/

This makes sense, although I understood the question to be about when different units were used in defining the size or placement of a widget.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Representing Units of Measure

Posted: Sep 27, 2005 10:49 AM

Well it is done. The latest HeronScript now supports postfix type casts, and basic line drawing primitives.

> Partly conceded. There is an accumulated error, but it
> would likely be "hidden" in the sense that the widget's
> size would never disagree with itself.

You are right.

> And, since I was complaining about rounding errors on the
> order of 1/288 in. (from simple manufacturing margins of
> error/tolerances), it's pretty hard to defend my original
> post's elitism.

Nothing wrong with being elitist. I want to produce something of very high quality.

> This makes sense, although I understood the question to be
> about when different units were used in defining the size
> or placement of a widget.

What I failed to communicate is that I want to be able to write:

window_variable.move_to(25 percent, 25 percent) 
window_variable.line_rel(12 pixels, 42 cm)

But to disallow:

12 pixels + 24 percent

My rationale, jumbled as it may be, is that 12 pixels + 42 cm is an expression with an indeterminate type. In order to allow the expression of a path with different types, I decided to create a polymorphic type "_unit" which accepts any one of the seven graphical unit types. This way only one definition of "line_to", "move_to", "line_rel", "move_rel" is needed.

The reason for this approach is that something like cm or percent is only meaningful when given a device context (like a screen or bitmap or printer). So only when you actually draw it, can you convert it to some kind of universal type. One of my requirements is that I want to be able to store paths as variables, independant of the context. This way when the context changes (for instance when the window is resized) I can simply go back and redraw the path.

In the HeronScript implementation every window has a "path" which represents a series of vector commands. What is cool about this approach, is that I can convert it to another format (XML, SVG, Bitmap, Metafile) very easily, or zoom in, or rotate or whatever, while still using the same core set of drawing operations.

Flat View: This topic has 15 replies on 2 pages [ 1 2 | » ]

Previous Topic

Next Topic