Hi,
The Back Story: I have a "units calculator" that lets the user do things like: (1 mi + 5300 ft - 7 yds + 12 in) / 20 min = 6 MPH [assuming I have done the arithmetic correctly tonight]
A consequence of this ability is the user can specify things like "4 ft 3 in" (instead of "4.25 ft").
My parser doesn't enforce particular rules on how the user specifies such values (though, obviously, the units must be similar -- no adding inches to candelas!). So, something like: "3 in 7 yd 5 ft" (!) is legitimate.
Issue: There are many places in the application where user
*stores* such data (i.e., where it must be "recall-able"). I currently do NOT "normalize" the data when re-presenting it to the user. I.e., the above example is regurgitated as "3 in 7 yd 5 ft" and *not* as "8 yd 2 ft 3 in" (nor as "26 ft 3 in", "26.25 ft", etc.).This recognizes the fact that the user had a reason for specifying it in a particular manner and silently converting it to some "normalized" form would only confuse him/her. ("Hmmmm... I thought I specified '3 in 7 yd 5 ft'... is that the same as '26.25 ft'?")
[the user can always have the data converted to whatever form he wants -- including something like "mm fur in"]However, I *do* process his/input to remove "superfluous" characters -- leading trailing zeroes, extra whitespace, etc.
This saves an insignificant amount of time in subsequent processing of the data. And, an even more insignificant amount of *space*. As such, it seems like my reasons for doing so are not really justifiable -- why not have the user ask for "pretty printed" data just like he would/could ask for it to have been converted to other arbitrary units??
Furthermore, there can be significance to some of that stuff that I am stripping off -- "2.000" is different from "2".
Comments?
Thx,
--don