It doesn't matter what people "think" or "say" - it matters what they write. You have to limit your syntax to a subset of possible expressions that can be written precisely and unambiguously, and which avoid surprises. People will /say/ things like "two foot six", "as long as my arm", "knee-high to a grasshopper". But you should only accept, for example, " " expressions.
Remember that the "smarter" you make the system, the more scope there is for getting it wrong and misinterpreting something that a user enters that you weren't expecting. It is better to give a syntax error message for entries that you /might/ have been able to incorporate in your program, than to incorrectly interpret other entries.
And you should decide if you are sticking to numbers, numbers and units, or more general expressions.
I agree here.
And it's not just the vertical space you lose. Even with horizontal spacing you lose information - with written expressions, there is a big difference between a small space and a large space. Then there are all the other things you can do with a pencil that you can't do with ASCII entry - proper "pi" symbols, wiggly lines, small numbers, raised and lowered positions, etc., etc. These all have to be replaced by ASCII symbols if you want straight ASCII input.
You are not making a person, you are making a program. There's a difference.
No, you write "2?" (if the unicode symbol for pi makes it through the Usenet and newsreader manglers...).
No, you write a full-size "2", then a "1" and a "2" that are smaller and are positioned with the "1" above and to the left of the "2", and with a line between them at an angle. You probably don't write the "1" directly above the "2", and you probably fit the fraction to the same height as the first "2". There is a fair amount of variation - but what you certainly /don't/ do by hand is use identical size and vertical positioning for the "1" and "2" as for the first "2".
As you can see, you can't write fractions clearly, neatly and naturally in simple ASCII. Whether you like it or not, you will have to compromise.
OK, I'll buy that line of reasoning -- especially for a calculator (where you are already encumbered with "2nd" functions, etc.)
Hmmm... "A b/c" I presume?
OK, given that is a (traditional) calculator, I can see how things like "space" wouldn't be available. And, it *probably* would be a stretch to suggest that it replace the first delimiter with a space when it encounters the second (i.e., "a b_c" instead of "a_b_c") -- cosmetics rarely being an issue in calculator land :> )
(I suspect it just uses a 7 segment display, as well, so even a proper slash is unavailable?)
But, I'm not sure that's the right sort of approach when the user isn't constrained by the I/O of a calculator :-/
From the context you put, I understand the syntax 2½ will be for the most ordinary fractions (IOW you'll not start accepting all the combinations of fractions of an inch ;-)
If the fractions are to be accepted (entered?) only via a keyboard or similar device (softkeys), I would suggest you have special ones for the usual fractions ¼, ½, and ¾.
If the data you're accepting comes from a stream I think that in the long run you should create a more 'strict' input language and have:
2*pi and not "2 pi" as 6.2831852...
2+1/2 and not "2 1/2" as 2.5 etc.
HTH
--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
Actually, I don't put any restrictions on the values entered. E.g., what makes "1/2" more special than "99/100"?
Note that I do rational decimal arithmetic. So, a value of "239872398472/239784676813183" is perfectly acceptable to me.
That -- coupled with your "FRACTIONS of an inch" (emphasis mine) comment above -- also makes it worth mentioning that fractions need not be "proper" fractions. E.g., "292384092840928/7" is likewise valid.
*And*, a number like "3 203498029842/5" would also be valid and acceptable; to do otherwise would imply that "1 yard 4 feet 87 in" would be "improper"/invalid.
The point here is to let users specify things in whatever way is most convenient to them and not enforce some arbitrary ARTIFICIAL constraint on the values presented.
For example, when measuring the house for ceramic tile, I would frequently have measurements like: "109 + 46 1/4" instead of "12 ft 11-1/4 in". I.e., I was standing "somewhere" and happened to mark a spot on the floor at the 109" mark on my measuring tape. Why 109 in instead of 108 (exactly 9 feet)? Why *not*?? Then, I repositioned the tape rule to the other side of the room and noted that the 109" mark coincided with the 46-1/4" mark. Why should *I* have to form the sum and/or convert to feet+inches when the calculator can do that for me?
That's an idea -- but, there is no way of knowing what the
*desired* fractions would be.
I want to be able to "cut and paste" from other applications without having the calculator dictate some "universal" set of rules for *all* numerics.
E.g., I made a batch of cookies last night. The recipe called for "2T + 2T" of almond extract. Why not "4T"? (Ans: because this is intended to stress that the 4T is used in two different places -- once in the dough, and again in the glaze). Elsewhere, it called for "10C + 4T" flour. Why not "10.25C"? (Ans: because the 4T varies depending on the moisture content of the particular batch of dough that you have in front of you -- something that is explicitly identified in the Rx. Expressing it as 4T gives you a clue as to how much "a little more" or "a little less" would likely be.)
It's interesting to watch how people *use* numbers in daily activities. It gives you an idea of how those people conceptualize the numbers they are using.
I will leave this question as a rhetoric one. . . otherwise this thread will go until 2038¹ ;-)
OK. Your spec.
Fair enough, you're attempting to be consistent.
Here lies the draggon: you have an ambiguity. Even humans will have trouble to grok exactly which number is being represented here and your rules don't help:
Is it "1.221e11" or is it "4.070e10"?
Which rule(s) would you use to unambiguously parse and give the answer?
As Hans wrote, I'm also educated in metric country and this kinds of units are just a curiosity for me, in no moment in my entire life (more than half a century by now) I've seen or heard this way of mentioning a length be it in professional or retail.
The measurement you mention above is 4.34 meters or if you need a excruciating level of precision it is possible to have 434,3 centimeters or even 4,343.4 millimeters.
All the "most convenient to them" ways are "ARTIFICIAL" constraints they got used to and in the socio environment they live it's accepted practice.
Imagine a foreigner which had a 'half baked' training in the imperial system and attempts to say he wants a "half stone of flour" to make bread, or that his dog got fat by 30C, would you say it is acceptable?
This whole anecdote is amusing! Do your tape rules have the metric meter and centimeters on the other side so you can stop having to live in this mayhem?
Yup. Given the specs you creating.
You will not be able to elide the dictation of a set of rules, if you want to reduce the space for errors in your application.
Which brings the issue right to the spot: the recipe puts context in the figures, a thing your app will not have, and due this you have to create a set of rules to be sure the data is being entered in the correct way.
For a counter example, you do _know_ that 'drop' is a unit of measure of volume, don't you? :-)
Then, if some volume is written as "7 drops", your app will happily accept the 'copy/cut and paste' and store what volume?
Perhaps 350 microliters? Or is it 583 1/3 microliters, or even 693 microliters?
Yes, but I think you're being diverted by these observations from your objective. Your app is not an object to mimic people using numbers, but rather an auxiliary device to help them to do certain thing faster and reliably, isn't it?
OTOH, lets think aloud: would your system accept the unit length of I beams in ounces or some exotic combination of units like: " 1/4 cwt 100 qtr 10³ drc"?
In your app which mass would be stored for "1.43 t"? Are "2 cwt" == "100 lb" or not?
Will your system accept all the Imperial units, like "chain" and "furlong" or there will be a 'limit'?
You just scratched the surface! In other cultures, they name numbers differently depending on the objects being counted!
Which brings to a small digression: until Leonardo Fibonacci introduced the Hindu-Arabic numerals in Europe in the start of XIII century via its book Liber Abaci, all the mundane calculations (even small change in the stores) used to be computed using abacuses, as the Roman numerals were awkward, after the popularization of the Hindu-Arabic numerals, most computations went to paper and pencil...
HTH
--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
As input, maybe. But never as output. It just doesn't make sense to present that number as-is.
If _that_ is not invalid by some rule everyone brought up in the imperial "system" of units gets taught in elementary school, it absolutely has to be. That nonsense alone IMHO would be reason enough to abolish that abomination of a system of units right here and now. Countries have been bombed for smaller offenses against common sense.
There's nothing artificial about requesting at least a minimum level of sanity in your inputs, and applying more of the same to your outputs.
A fraction can be either "improper" (counter larger than denominator), or it can be mixed (i.e. in 2 1/2). But not both.
You're comparing apples and oranges there. The first is not one measurement. It's an expression consisting of two measurements.
Yes, that's different from what your calculator's _output_ of the result should look like.
It's part of the calculator's job to sanitize those inputs, and present the resulting value in a sane way. 153 1/4 inches, e.g., would not be sane. At least not in that imperial contraption you guys use instead of a proper system of units of measurements, that is.
I guess you need to make up your mind what it is you're going to build: a desktop publishing system, or a calculator. Right now you're trying to shoe-horn requirements applicable the former into what you say is a a case of the latter. That won't work.
[pr>>> From the context you put, I understand the syntax 2½ will be for the
I look at it as me not forcing users to do things the way *I* want but, rather, deferring to their needs and preferences.
As consistent as 7023 mm would be.
*They* chose to specify the value in this (bizarre) format.
*Knowing* that " " is interpreted as " + ". All I can do is faithfully apply the rules.
If I rule out improper fractions as s, then do I also rule out expressions like "3 ft" when used alongside "2 yards"?
I can play nanny and try to force people to sip their tea with their pinky airborn... or, I can let them guzzle it out of a coffee mug with their fist wrapped around the ear. I think the latter is the more correct approach (especially since I can't foresee every possible application domain that could be in play).
See above.
I am not claiming this to be "common practice". But, what rules would you have me ARBITRARILY force users to adhere to -- just to make *my* life easier (?) ? What do I gain by forcing them to always normalize values to some "standard" that I "imposed at compile time"?
I always chuckle when I hear folks complain about this wacky system of arbitrary units. As if SI was the holy grail. Makes you wonder how folks can deal with such ugly numbers like "7", "23.996" and the dreaded "42"! ;-)
None of the fundamental constants are nice numbers. Time is definitely non-decimal. Months have varying numbers of days in them -- some change every four years (except when they *don't*!) Why isn't there an "outrage" advocating metric time? Heck, we created this arbitrary unit called a "meter", we can just as easily create an arbitrary unit called a "fizzbuggle" (as the basic unit of time).
[yes, you heard it here, first, folks! The Fizzbuggle! :> ]
And, why do we need to have leap years? So what if winter happens in June 700 years hence? And those pesky leap seconds... what makes "AM" synonomous with "morning" (it just means "before midday"... why does "the sun directly overhead" have to constitute midday?)? Who cares if "noon" ends up creeping into the middle of the night in a few millenia (?)
Why would you ever need to express more than 1,000 mm? Isn't that like me talking about 24 inches (instead of "2 feet")?
People use the units of measure that they are comfortable with. Do you give directions as "go 250 meters down the road and turn left" -- or "go one quarter of a klick down the road and turn left" -- or, "take a left after the big red factory"? How you express things varies based on context, needed accuracy (and precision), audience, etc.
Of course! All language (and, therefore, terminology) is an artificial human construct. Why is "red" red and "blue" blue? Why don't we refer to colors by wavelength (or frequency)? Surely this would be much more useful than "sky blue", "mignight blue", "indigo", etc.
Why do we have "months"? Why don't we use Julian dates for everything? Imagine all the CPU cycles wasted converting to/from these arbitrary names associated with mythical *gods*, etc. Look how much easier it would be to get your bank statement "every 10th day" (instead of "on the 10th of the month -- what happens if that's a Sunday?)
And what's up with these 7 day weeks?
Why do we track "birthdays"? What is the significance of counting the number of times we've been 'round the Sun? Wouldn't it be easier to count *days*?
People like to organize information/data in their heads in ways that they can relate to. Often, using some "system" that a predecessor ARBITRARILY created. (my favorite chuckle is part numbering systems -- as people *hope* they can somehow use those numbers to impose *an* order on items that don't really have or need an "order".
Horses are measured in "hands". Sheesh! How convenient is *that* as a unit of measure -- hoping the horse stands still while you count how many hand-lengths to his shoulder? How is the "shoulder" defined?? :< But, it *works* for that application domain. Is there some reason they should be "forced" to abandon it? Just because someone outside that "world" thinks it silly? Or, is troubled by having to remember a bizarre conversion factor?
I would chuckle in much the way I chuckle when I hear any other grammatical error, etc. And, would correct them in the same spirit that I would hopefully find a "foreigner" correcting me if I was in his land.
Instead of complaining that we (US) "park" in our "DRIVEways" and "drive" on our "PARKways", I smile and think it an amusing anecdote. Commit it to memory. Then, move on to more pressing things. (I once heard a Brit give a reason for driving on the "wrong" side of the rode and relating it to cavalry warfare or somesuch... "Um, OK. Where are we eating dinner, tonight?")
Why do we write right-to-left, top-to-bottom (except, of course, those folks who *don't*)? All these are just historical conventions that we continue to follow because it is easier (or cheaper) than changing them.
The reason for the "109 + 46-1/4" has more to do with the fact that I may have been using a 12 ft "tape" at the time. Or, perhaps there was something in the way that would have prevented me from spanning the entire distance in a single measurement (e.g., try measuring a spot on the ceiling *from* a wall -- very few tapes will remain rigid over spans that long). Had I been raised on the other side of the pond, I might have expressed it as "305 cm + 587mm".
A carpenter probably would have recorded it as "112 + 43-1/4" as "112" would have been a "sweet" number, to him.
The point is, I recorded the measurement in the way that was most CONVENIENT for me (at the time). Why should I have been forced to record it in some manner preordained by a piece of software?
As to support for metric measurements on tapes: yes, *some* tapes/scales will have one side devoted to imperial/english units and the other metric (by side, I mean "edge", not "surface").
But, most (residential) buildings are *built* with imperial measurements. E.g., lumber sizes, stud spacing, roof load calculations, etc. are all done with this basis. I'd be annoyed to have to measure "406.4 mm" when placing studs in a wall (Q: are your studs on 0.4m centers? Or, something similar?).
E.g., roof pitch is typically expressed as fractional inches per foot run (in this part of the country). Should it, instead, be expressed as a dimensionless constant?
As many tradesmen will tell you, there are lots of hidden secrets to be found in their tools -- things that aren't immediately obvious or explicitly mentioned. E.g., the length of a claw hammer's handle is (usually) a handy measure for citing electric outlets (above the floor). And, a seasoned carpenter can teach you all sorts of tricks about using a "square"! If you've ever used a Hickey, there are a variety of "tricks" embedded in it's markings, etc.
I can *force* people to always use "proper fractions". I can even force them to use pure decimals! But, all that does is impose constraints on them for no *real* gain (well, maybe it makes my parsing a little easier?).
The more "unconstrained" I make input tolerances, the less I can *enforce* those constraints in an attempt to detect "data errors" (on input). That's just a fact of life. However, that doesn't affect the "quality" of *my* computations, etc. (GIGO)
No, the application wrapped *around* the calculator puts meaning to the data. The calculator is just a "service" -- in much the same way that "+" and "-" operators are TO YOUR CODE. (i.e., my applications rely on the "calculator" to handle their math and conversion needs)
So, an application can install a preprocessor to filter input passed to the calculator. This is necessary since, for example, the particular "units" in play will vary with the application (this has consequences to how abbreviations are interpreted, etc.).
For example, I have a database of papersizes. The table itself is dimensionless -- I don't express paper sizes in inches *or* millimeters. Rather, the data type is "length" (i.e., the values therein are expected to represent "lengths"). So, "8.5" is not a valid datum. But, "8.5 in" is. As would be "85/120 ft" -- but I have no idea why anyone would ever chose to express a paper dimension in that way!
So would "210 mm".
This allows my barcode printing application to fetch "dimensions" (lengths) from the database, pass them to the calculator along with any arithmetic operations that it needs performed (e.g., if a sheet has 3 labels across it's width, then "/ 3" is probably going to appear in the calculations, somewhere! :> ) and request the result in whatever units it *needs* (perhaps
300ths of an inch -- if it's a 300dpi printer?).
This approach lets me defer resolution of quantities until I absolutely *must*. The alternative is to pick one measurement system and one unit of measure (mm? in?) and convert everything to that (arbitrary!) "standard" at compile time. Then, hope that I don't need to massage the resulting data to some other system later (e.g., had I stored mm-dimensioned paper sizes and ultimately had to convert them back to "300 dpi pixels", there would be a "25.4" somewhere in the application... something that it shouldn't HAVE to care about!)
It boils down to design philosophy. One approach is to implement a very rigid syntax for input to the calculator. Then, everything passing data to the calculator assumes the responsibility for ensuring that all data meets these criteria. This forces the applications to implement permissive *and* restrictive behaviors as they see fit -- and then "normalize" data before it is passed to the calculator.
Another approach is to implement a *tolerant* syntax for the calculator and let applications *restrict* input from the user as they see fit.
As I see most applications being permissive in the range of data they accept, it makes for less work to let the application simply act as a "clean pipe" to the calculator -- enforcing only those things that are critical to it (e.g., a GIS app would ensure '/" are interpreted as min/sec when geographical coordinates are expected; feet/inches when distances are involved; etc.)
Does your calculator prevent you from specifying 361 degrees as an angular measure? Or, is it "smart enough" to realize the equivalence of 361 and 1? (assuming the parameter of interest can be confined to 2pi).
As are the pinch and dash (I actually have "pinch" and "dash" measuring spoons -- and refer to them in my Rx's :>)
"7 drops"
What *type* of drop will depend on context -- just like what
*type* of "ounce" (mass) you are dealing with (e.g., an ounce of gold DOES weigh more than an ounce of feathers!). But, it's still "7 drops" (while it is inside the calculator)
How do you (I) know that the next thing entered won't be:
"* 2" (yielding "14 drops")
or:
"+ 4 drops" (yielding the value "11 drops")
or:
"/ 1 oz" (yielding the scalar "7/360")
You (I) can't convert "7 drops" to liters until you know what context it is intended (assuming the input was "7 drops =")
No. It's a service that applications can use to crunch numbers and units. It relies on those "external agents" (whether they are bits of code or human beings) to provide the data and guidance on how the data is to be used/processed/displayed. It imposes as little restrictions as possible on the data. E.g., you can't "divide by zero" and expect a finite result. Nor can you express a volume and expect an *area* as an answer. etc.
Yes. Should I, instead, force all lengths to be expressed in meters? What if I'm computing the trajectory of a spacecraft leaving the solar system? Would meters be silly units? Or wouldn't they? Why does a *calculator* care about what you choose to feed it? If the first value you enter is in meters, should the calculator force the second one to also be in meters (i.e., force you to express "27 km" as "27,000 m")?
If you wanted to used mixed units (e.g., compute area where one unit is imperial measure and the other metric), should it *force* you to convert one measurement to "the other" measurement system *before* it lets you combine them? (isn't this just a wasted step? especially when the calculator will be called upon to perform that conversion?)
As above, it depends on the context -- the units of measure selected for application, at the time.
If I pass "10" + "100" to the calculator, should it yield a value of "110.0", "6.0" or "72.0"?
I have a database of units of measure. Each defines a relationship between the unit in question and some other unit(s) of measure. E.g., I have several (conflicting!) definitions of an "ounce" (mass). Or "points". As well as several *different* definitions of a "meter".
[Recall, all of these are artificial. So, most have temporal aspects associated with their definitions as the whims of Man change. Thus, "context" can have temporal aspects as well.]
Driving the calculator thusly lets me easily add support for anything I want (in terms of "units"). Imposing rules on "what" can be combined with "what else" and *how* just unduly complicates things. That belongs as the province of the application itself. Additive operators need "like" units (e.g., length, time, angular measure, volume, scalars, etc.). Multiplicative operators can mix units.
E.g., if you want to multiply seconds by feet... why should the calculator care? As long as it knows that the result has units of "feet-seconds", it should be content to use that in *further* calculations (quick, what's "2 ft-sec * 3 N-M / blue"? :> )
Yes, but that's not my market. :>
The abacus is a remarkable (simple!) device. And, watching someone skilled in its use *defies* analysis -- things move too fast and in nonintuitive (though perfectly rational) ways. I thought an excellent hack would be an "automated abacus"... beads driven across the rack by cams, etc.
But, it would have limited geek value. I much prefer the motorized sundial concept... :> I'll work on that after I figure out how to make tubular chimes.
You don't have "3 hours 27 minutes and 13 seconds"? With those silly "units of 60"? (not to mention *12* months, each with a different, sometimes variable, number of days; leap seconds, etc.). How do you express geographic coordinates? Do you buy eggs in "boxes of 10"? How many rolls come in a package of hot dog buns?
I figure my skillset includes more things than just "moving a decimal point" -- else I'd have real trouble computing things like the terminal velocity of a steel ball dropped from a height of 50 inches... :>
Have you ever had to "double a recipe"? Or, do you just make the same recipe *twice*?? (what if you need 150%... do you bake the cake recipe one and a half times? :> )
Here, we use "college ruled" paper. Usually four lines per inch. Not "quadrille" pads. If you want to express a fraction, you write the numbers on the "ruled line", separated by a slash. Trying to raise the numerator and slip a line *under* it would result in the numerator shrinking to an illegible size for all but trivial fractions (e.g., 1/2, 1/4). Some folks will use a "shallow slope" slash to try to make it look like the first (leftmost) number is "atop" the second. But, you just can't fit one atop the other (in the "gradeschool" sense) and still fit inside the 1/4" line spacing.
(imagine all those homework assignments *you* saw confined to fit within those 5mm cells)
No, it's *a* way of representing things unambiguously given a USASCII character set with an electronic storage/transmission medium. Are you claiming everything that predated computers was "ambiguous"? E.g., all measurement systems predate the modern computer...
It seems like the exact opposite is the goal, now. To allow machines to be more flexible in interacting with human beings. To allow the machines to adapt to their users instead of forcing their users to adapt to them. Haptic/gesture input, speech I/O, etc. I.e., the machine is bearing the cost of adapting to the user instead of forcing the user to adapt to the limitations of the machine. The days of simple, stupid, uninspired user interfaces are quickly becoming things of memory... ("Enter '997' to invoke calibration mode. Press '3' to reset the system gain followed by..."). The trick is coming up with smart interfaces that can infer the user's intent without pestering them with lots of silly or unnecessary "clarification".
*Anyone* can parse input like: convert(2.305 metric_foot, SI_meter) The trick is knowing when to use a metric_foot, international_foot, standard_foot, -- or any of the other various "foot"s (as well as
*which* "meter") -- without pestering the user for clarification. A device that pushes all this back onto the user is backward thinking and uninspired in today's world.
30 inches. It's 2 feet 6 inches.
It can only be 2 feet, squared. Square feet aren't represented by "'^2" just like cubic feet aren't represented by "'^3".
In your metric world, is "2mm^2" really "2 square millimeters" or "2 mm * 2 mm"? Would "2mm ^ 2" be interpreted differently??
Sure. But rarely, if ever, in calculations outside special fields.
Yes, calendars are nasty. Always have been, and will remain so until somebody finally gets off their lazy behinds and adjusts the celestial bodies' rotations to get sensible numbers. I.e. 10^5 seconds per day,
3*10^6 seconds per month, 3*10^7 seconds per year.
But nobody in their right minds does any _calculations_ in calendar dates and times, except to convert them to something saner. You pretty much always convert to a sane system, do the calculation there. Then it's up to the user to decide which system the result is presented in: the sane one, or the traditional one.
In decimal fractions of degrees, or in seconds.
Of course!
How the heck would I know --- no such thing in stores round here.
We were talking about written representation. Do you routinely write up the scaled version of a recipe? And if so --- do you fell yourself slavishly bound to the input representation, or do you do the maths in your head, then represent the result whichever way you see fit? E.g. if it's 2/3 cups of something in the recipe, and you double it: do you write 4/3, or 1 1/3?
That's roughly the same height as the 5 mm square grid, then. Ruled paper for text-only usage is usually a good deal coarser, though: 9 or
10 millimeters, usually.
Some people do that for prose, but 5 mm is really too small to fit any maths into without spills. There just wouldn't be any room for indices, exponents, much less stuff like integrals or size-ordered parentheses.
No. But as discussed before, they did use visual means that simply aren't available in a strictly linear representation to avoid ambiguity: size, vertical placement, different alphabets (Greek and Hebrew mostly). So unless you're prepared to build an OCR engine to decipher hand-written mathematical expressions, you're stuck with what people can actually enter. And believe me: they don't want to use an actual formula editor.
Let's not forget it was you who ruled out UNICODE right at the start of this discussion.
That's not a trick --- it's obviously impossible. Oh, and there's really only one meter.
That's not answering the question I asked. I asked how you decide, not what the final decision is.
So if I wanted to multiply 2 feet by 6 inches, you're telling me I can't do it? How silly is that?
Why the heck not? What's used instead?
The former. One number, one unit, and mm^2 is the unit. If you want to express 2 millimeters squared, you write (2 mm)^2. In speech the two are distinguished as "two square millimeters" vs. "two millimeters, squared".
Many of our "measuring devices" are fractions of each other. E.g., in baking (sorry, that's on my mind as I've been making cookies for the holidays) you have half (i.e., gill), quarter and third Cup measuring cups (typically -- some sets have additional sizes); teaspoon and tablespoon (the former being a third of the latter; the latter being a quarter of a quarter cup; neither to be confused with the flatware of the same names); quarter and half teaspoons, etc. A farmer would sell apples in pecks or bushels (the former a quarter of the latter; I rarely see "buckets" used); etc.
For any of these things, trying to measure, for example, 0.4C would be an exercise in futility (convert to mass and use a scale) Similarly, saying 1.375T would only create problems for the typical user ("What's 0.375?").
Exactly! That's how we (US) deal with this insane set of units. You *pick* one, do all of your math in it, then convert to whatever is most appropriate for final presentation.
Just like converting time to hours/minutes/seconds or lat-lon to deg/min/sec.
Yikes! That alone tells me it will be 100+ years for the US to *ever* "go metric"! Dozens are ingrained in our culture (dozen donuts, etc.).
Sorry, that was intended as a chuckle to folks reading over your shoulder. (hot dogs are packaged in a different quantity -- typ 10 -- than the rolls they fit in -- typ 8).
Actually, I would prefer to have it *printed* for me. Recipes are typically annotated with "serves N". So, unless you have N that you want to serve, you're always scaling up/down to fit your particular "N".
That depends on the rest of the recipe. If, for example, some "wet" ingredient is present in multiples of a cup, I would opt for 4/3 (to signal "four 1/3 measures"). This allows the
1C measuring cup to "remain unwashed" (and undried!) after its use with the liquid measurement while I use the 1/3 measuring cup, repeatedly, in this other case.
Otherwise, I would opt for a mixed fraction to save me the trouble of gauging the magnitude of the quantity.
In no case would I say "1.33". Nor would I say "2.5" (since I think of "1/2" not "0.5" when it comes to measurements)
I.e., adopting a uniform scheme of expressing values (to three decimals?) *imposed* arbitrarily would be less than ideal.
Exactly. You learn not to use vertical space lest you end up having to "abandon" the line above or below to accommodate it.
Yes. It seems ridiculous to have to burden a "calculator" with that rich of a character set.
It's not impossible. You need to look at the context to make your decision. If you can't -- and there is a big chance that your "default" could be wrong -- *then* you ask.
As I stated in a previous post, ::= A series of is implicitly joined with additive operators. This is consistent with how people speak/write: 2 feet 6 inches.
2 ft * 6 in
You would expect to find a division operator between these two (e.g., 2 ft / 6 in = 4) so what is so unusual about finding a multiplication operator? The same is true for differences (sums are "special" because that's how we speak/interpret things like this... "6 hours 5 minutes" "4 years 3 months", etc.)
sq ft
Aside from scientific usage, you won't see ft^2, yd^2, in^3, etc. Area is measured in sq ft (sq yd for carpeting; acres for land; squares for roofing; etc.). Volume (when not using one of the predefined liquid/dry measures) is cu ft (cu in for legacy engine displacements).
I can arbitrarily create an abbreviation "ft^2". But, that leaves open the ambiguity of "ft ^2", "ft ^ 2", etc.
Yes. Here it would be as I described: "2 feet, squared" or "2 square feet" (sq ft).
Otherwise you would be allowing the "^2" to bind more tightly to the "unit" than the unit binds to the number (i.e., the is the common currency of the application; operators act on s.
That's the same in the metric system. The difference being that in the metric system those fractions are consistently one tenth or powers of that, instead of picking a seemingly random number ever step down (or up).
So you can by sets of half-cup cups, third-cup cups, and cup-sized cups. And you wonder why people on the outside looking in would consider that system insane?
Only because you assume absence of proper tools. Sane people have a _graded_ measurement cup. Transparent, with a scale on the side. Two, actually: one holding a liter, graded to tenths or twentieths of that, the other a good deal smaller, for very small quantities.
Better still, just specify the recipes in masses directly, and just do all the measurements right there on the kitchen scales.
Well, why then do you worry so much about sticking to whatever strange format your users _input_ their numbers in?
You're a good deal beyond 100+ years already. You're well into the second century of refusal.
[...]
Hmmm... don't you think you just rather conclusively contradicted yourself?
Which begs the question why they're not just specified as "serves 1" to start with, so you'll have to scale in one direction only. OTOH, that would become difficult where the smallest unit of something on sale is a whole turkey that serves 8.
No. You learn you need two rows of squares anyway unless your handwriting is _really_ tiny by nature, so might as well use two or three for maths. At least where actual maths is being written up, not just cookie recipes.
Instead, you wish to burden it (and your users) with yet another completely unusual way of writing down non-integer numbers --- it'll have to be either that, or ambiguity.
At the least, UNICODE would have let people use an actual Greek \pi instead of people worrying whether "pi" is "p times i" or \pi. Who knows, maybe UNICODE even has a "special mixed fraction blank" you could use to indicate the break between "2" and "1/2".
What context could that possibly be? Are you telling me your calculator will need GPS or a network connection to determine which type of "foot" is locally applicable? Or, while we're at it, why not go right ahead and fit it with a mind-reading device?
You said it was possible without pestering the user. Now you plan on pestering them.
Or somebody might say "2 feet" with hands horizontal from each other, then say "6 inches" after having moved their hand on top of each other. Like I said, by the time you arrive at a linear written representation, you've lost a lot of information you can't do without, so it has to be replaced by something else, even if that feels less than natural or obvious to the first-time user.
It's unusual to ever actually write down multiplication operators in hand-written maths. You write and say 2i??t, not 2*i*pi*nu*t. It's so unusual indeed that nobody even thought of putting the proper operator characters, ? or ×, into ASCII, so we have to make do with '*'.
Of course it does. Exponentiation binds stronger than just about anything.
You obviously don't bake. I suppose you can consider this to be a specialized field, but if you've ever tried to use a 1 cup measuring cup to get a level 1/2 of a cup of flour, you'd understand immediately why these devices come in the range of sizes they do.
In metric, do they not provide multiple size measuring cups?
o,
You are not a cook, likely not even an amateur. Cooking is likely not a very good application to discuss the advantages of measuring systems. Measurements in cooking are designed to facilitate convenience to the cook and to deal with the different properties of food.
Yes, why not ask some of the famous chefs why they do what they do and maybe you will learn something...
Yes. Graduated measures are OK for low and medium viscosity fluids, but worthless for dry or pasty ingredients.
They do, although exactly what size they are varies by local custom. And they're often still called cups. Some parts of the world have settled on a 250ml "cup," although it's not universal - in Japan, a "cup" is 200ml.
Even more oddly by American standards, in much of Europe recipes tend to specify measures of flour and sugar in grams, and you have measures calibrated to grams of different ingredients. IOW, you can find
*volume* measuring devices calibrated in grams of flour, sugar, rice...
In the US, yes! Depending the country (and language) the comfortable way of pronouncing my first name changes, and having past my first half century of existence I can live with all the variations :-)
In this pursuit your are being prey of a mistake which is very common in Requirements Engineering: what seems to be 'users needs and preferences' before your solution/system/application entered in they world is a completely different thing on what they would need and prefer _after_ your solution/system/application is in steady state.
The way of exiting this conundrum is to do some pilot user surveys or better (but expensive) usability laboratory.
I do that for living, so believe me, in the long run, it saves you money and headaches.
No, you're dazzled by your concept and trying to fit square pegs into round holes. There is nothing improper in 7023 mm, this is a way the person quoting a measurement to inform the accuracy of the figure is down to nearest millimeter (in fact in error theory it's accepted to say nearest to ±0.5mm).
No, this is a convention which has to be used within context (which as Hans also is trying to advise you) requires too much CPU and algorithmic power to do properly without (IMNHO) good ROI.
This seems to be the most logical thing to do, or at least, 'accept' the input but echoing immediately 3 yards or 9 feet (hope I got the conversions correct, if not bear with me as hypothetical correct answer ;-)
Very colored and figurative way of saying you already made your mind?
Yes you cannot foresee, and due this, the embrace all possibilities will always have to solve ambiguities which using a more strict, using your words, the former way, will avoid in bud.
Sorry, you gave an answer as authoritative, but I could not find an algorithmic (closed) solution to the problem.
The gain is avoiding ambiguity and simplifying the implementation of your SW.
I wonder if there is some non written rule in the Imperial system which would not find logical the writing of a measurement be done in decreasing multiples, so above measurement be always written as "3 yd 2 ft 3 in" (again bear with me about the conversions...).
I cannot grok what are trying to bring to discussion, sorry!
Hans, already explained you SI (a.k.a. 'metrics') is just a system where we got rid of synonymy of measurement units and a rational way of dealing with the fractions of them.
Nice, you brought this to discussion! So your calculator will accept 15 past four as entry for hours?
Are also putting all machinery needed only to be able to enter "next Friday"?
As I already wrote above, this has to do with the accuracy of the measurement.
No, they use units of measure to convey information with a degree of accuracy sufficient to communicate in the socio economic environment they live and interact with.
"Comfort" and "custom" are words which have a too large semantic extension and can lead you to wrong conclusions.
It depends: have you checked recently how Google maps gives directions?
Do you have any study showing problems of usability on the format they output?
Have you ever traveled to a place where you don't have command of the local language?
How would you like to have the directions given to you?
Yes! So please accept this tiny piece of wisdom Hans and myself are giving you (think Christmas ;-) the context you have now is your application, forget about attempting to emulate the World inside it.
Our eyes aren't adequate to it. So this is non sequitur.
If you need that degree of accuracy, yes. For the ordinary people, even the difference between the tones of blue may be only a curiosity.
I'm sure you know the answer: historical reasons.
Same.
Same. Although I've to warn you that certain world-views and/or religions forbid it.
Most of the persons only 'relate to' because they were educated in it.
Never heard about this. Hint, I live at walking distance of a Horse Club, and used to ride horses... maybe in the US?
Which brings down your calculator is only being prepared to accept _what_ *you* think is acceptable...
You've get back to question begging all time: do a usability survey.
Humm... this is something is explained in the primary school here, at least in Catholic schools. The reason is (now) historic, but consequence of the ancient technology (OK, plus some Middle Ages superstition which foreboded left handed people of using they favorite hand):
As people started to use paper and ink (and a feather), due the fact the right hand was used it was faster to write left to right so ink still wet would not blur by a passing hand over, same reasoning to come from top to bottom.
In the Orient, where the use of small brush or straw which could be used without support in the surface allowed them to write top bottom, left to write.
My boy and my broter are architects and this has been eliminated completely by using ultrasonic ranges....
Because it will in the long run be more accurate to check, more efficient to store in your SW, and easier to explain the rules of use of it.
OK if in the 'surveying' it was quicker and dirtier to note down the number as "112 + 43-1/4" [whatever units], but why keep with this madness?
Would the bill of lading of the materials to applied in the job have the stuff written that way or will the software of the warehouse put in the multiple proper fractions format?
Electronic ranges do the computation for you, if you need to.
By the way, how to electronic ranges in the US report measurements?
All the measurements in Civil Engineering in this country are in metrics units. When some stuff is made by an American company and they measurements used to be in imperial system, they are converted. For example 'half inch' conduit tubing in this country is 13 mm conduit.
Why not? For convenience. i.e., you'll find centimeters by meter here, because in the end of the day, you have to measure it.
Most of these 'secrets' come exactly of the cumbersome system of units you folks 'are comfortable with'. The only handy measure we need here is a tape measure, which we mark the places according local/national code.
Same reasoning. See my earlier post about the abacuses going in disuse after Hindu-Arabic numerals got in full use in Europe.
And avoiding ambiguity, showing the way you're storing actually the numbers, otherwise you'll be forced to store all input as text, right!?
So you accept the errors get further down the chain... THIS is fact of life...
Indeed it affects, and affects also the easier of checking them.
[snipped]
Yes.
210 mm is not a paper size. It is at most one of the widths of a sheet of paper, which could be an A4 or A5 sheet.
So for a person versed in the ISO way of thinking this info is ambiguous to start with.
Probably much more complicated than that (I'm saying ex cathedra, I wrote software to print labels once in a time), the labels would have some tiny margins around them, themselves some outer margin, etc. In the long run, you'll do as every sane person in World does, and use a database of the label sheets themselves...
You deluded here. Once you entered the quantities the resolution is set until you change it by editing.
Yes, this is what OOD techniques would suggest. You use a single internal representation and use expropriate output formats.
As I wrote earlier, you're mixing two concepts here. If an application has to deal with paper sizes and sub units of it (labels) the 25.4 in between is the least of your problems.
You THINK you'll not have to care about, and then will be caring (without paying attention to) in several places, leaving space to make mistakes due redundant code...
The correct one.
Yes.
Your project will be finished in the Humanity history :-D
Which is a different approach than what you are describing, perhaps your philosophical rambling have stretched to a point where the actual implementation will be less ambitious and more down to earth, so the above paragraph makes sense, but your general spec not?
No calculator I'm aware of prevents me to enter 361 or 1440 degrees of an angle, but all the results come back normalized, which is nothing to do with 'being smart enough', just plain arithmetics.
If you have to store an angle as (say) 1440° because it is the result of some operation or to show the number of turns of some object, as soon you attempt to do an operation with it (sin, cos, etc.) and try to get the inverse back, you'll have a normalized number.
OK, fair enough, and where will your amazing piece of software get the context?
Which is what we're saying all the time: what will be the mechanism to get the 'external agents' guidance if you accept ambiguous input?
This has nothing to do with imposing restrictions on the data. These are rules on how to operate in the data.
About imposing restrictions would be something like this: the length data can go negative or not?
In Civil Engineering and Surveying, as well in Oceanic Sciences is commonplace to have such kind of figures.
No, but you should select a single unified way of echoing back the input, and yes I suggest you store internally in meters ;-)
No, meters are as good units as spacecraft as you go, while we keep in Newtonian movement.
Because in the end of entry it has to store the thing in a machine tractable way.
This question is somewhat like if the first value was square meters (for the area of a house) should the calculator force the second one to Euros (for the price of the house).
The grammar is correct, but the meaning is nil.
It is a non question.
Well are you storing the area as a string using the "mixed units" or will store as an area? for former is a wasted (but just postponed) step, for the second, a necessary one, indeed.
And context will passed to via a second (computer) language, right.
I cannot see how a calculator will come with anything numerically different that 110 for the input you've placed in the quote marks.
The output format could obviously be: 0x6E, 0156, 1101110b, or CX...
This last phrase puzzles me (and apparently Hans as well) how come you have "different" definitions of the "meter" as there is a single one (except if you put in the table historical superseded ones) the one in force is a single, and BTW very accurate one.
Which does not change the needs to have an unambiguous way of entering storing and outputting the data...
You probably are mislead on this. You're mixing two concepts:
1) You WILL impose rules on "what" can be combined: you said already (and makes a lot of sense) that you'll not allow mixing areas with lengths, for example);
2) You have a desire of accepting the broadest way of representing these units and for such you believe you're doing a good service accepting ambiguous entries and putting a burden in your app to figure it out.
So. Simplify: accept all the units your database is capable of, but normalize it and echo it back normalized so the user can check it (when human to machine interaction).
Yes, why?
"feet seconds" or "seconds feet", or rather "time·length? It may represent different things!
It is 'non intuitive' for people don't know to use it. Search in your area for 'soroban' training (can be done in a weekend) and you'll see how intuitive it is.
:-D
--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
The Japanese "1-cup" measure in my Zojirushi rice cooker is 180ml.
formatting link
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Didn't know about the G=C5=8D. Apparently the Japanese use both the "modern" 200ml cup and the traditional ~180ml G=C5=8D, the latter particularly for rice and sake.
formatting link
So if my Japanese recipe calls for a cup of flour and a cup of rice...? Ugh. My head hurts. Makes me wonder if sake is sold in fifths=E2=80=A6 (But seriously, in the US sake is sold in the usual 750ml bottles).
And 750 ml is the largest "round" metric size that is less than a fifth of a gallon. When they converted from US gallons to liters they didn't want to make any of the new sizes larger than the ones they replaced... more profit! Most of the sizes are pretty durn close to the old. 750 ml is 0.9906660763177 times a fifth!
Bad even for liquids (unless sized "comparable" to the measurement being made). E.g., measure 1 tsp (~5ml) -- common for flavorings -- in something like a graduated 1C cup (~200ml?) and you wonder why things don't always taste as they should (flavorings tend to be pretty intense)
Wonderful. See above. :-/
Ah, so while we have one consistent "measurement unit", we have INGREDIENT SPECIFIC measures?? And the "english" system is considered wonky??? ;-)
[I recall posting a question a while back regarding the size of a "packet" of vanilla...]
Cooking is chemistry. Everything is about ratios. I can start almost any recipe (of a given "type") "from memory" -- because they all have the same basic ratios of baking soda (or powder if you need double acting), salt, sugar, flour and butter, etc. E.g., baking soda is almost always 2:1 wrt salt.
So, being able to measure "3" and "7" at the same time is useless -- "3.2" even more so.
We don't have *sets* of "half cups" and *sets* of "quarter-cups". You purchase *a* set of measuring cups: typically 1/4C, 1/3C, 1/2C and 1C (some sets will include things like 3/4C & 2/3C for lazy folks but they are almost never needed). The same is true of measuring
*spoons*: 1/4t, 1/2t, 1t, 1T. Again, some sets are more exhaustive (the set I just purchased has 3/4t -- i.e., 1/4T -- for which I fail to see the need :< ). However, I *have* found it worthwhile to include smidgen, pinch and dash spoons in my set (dash = 2 pinch = 4 smidgen; 2 dash is 1/4t). If you look at the entire set, you can see how the factor of 2 is prevalent.
Sure! I have *two* of those. We use them to fill the hummingbird feeder (they are useless, otherwise). One is 2C (roughly half of your liter) and the other 1C (i.e., a quarter of a liter).
For liquid measures, either *could* be used (though you would have to use some care reading the meniscus accurately). For dry measures, both would be abysmal! How do you ensure the top surface of the dry solid is level across the entire container *and* at the proper height (as indicated by lines painted/etched on the glass)?
[when baking, the majority of the ingredients are "dry" -- even those *called* "wet" (sugar is considered a wet ingredient despite being "dry"). I've seldom used more than a cup of anything "liquid" in a recipe (eggs are measured by *count*, not mass/volume). Liquids like vanilla extract (none of my Rx use more than 2T of it -- and that's for a large batch) And, for small quantities, both would be useless for dry or wet measures. Let's see.... 1/2t is 1/96 C. Can you resolve that bit of a solid substance with *your* eyes ACCURATELY? (So, a smidgen would be 1/16 of that... I'm *sure* you couldn't resolve that in a 1C container -- 1 part in 1536. You'd be hard pressed to do so in 1T container -- 1 VERY SMALL part in 96!)]
So, now I have to cover the scale with a sterile bit of (something disposable). Tare it. Then, slowly dump stuff onto it while watching the indicator -- hoping to stop *just* as it reaches the desired amount. If I overshoot, I'll have to scoop some off and try again. (We'll assume the scale is critically damped and responds instantly)
And that scale will be able to resolve a smidgen. As well as
10C (I'm just a consumer so my Rx's never get much bigger than
10C of any one ingredient). We just figured a smidgen was
1/1536th of a cup. So, the scale needs a precision of about
14 bits (assuming *my* 10C is "full scale") just to *notice* the smidgen.
And this device will be as inexpensive and robust as a $10 set of cups/spoons (which could probably be purchased, in cheap plastic versions, for $1 -- I just dislike plastic! :> ). I suppose it could be solar powered to eliminate the "power cord" and/or cost of replacing batteries. Or, better yet, a triple beam balance requiring nothing more than patience! :>
And it will be "wipe clean" (since I doubt it will be immersible) so I don't have to spend lots of time cleaning all the spilled ingredients off of it when I am done?
Measuring cups/spoons are a huge expedient for *accurate* measurements. The cup/spoon is deliberately overfilled (i.e., unceremoniously shoved into the bulk foodstuff container) then scraped "level" with the non-business edge of a knife (or similar) with the excess ingredients falling back into the bulk container. Lather-rinse-repeat. Some ingredient containers (notoriously baking powder) deliberately have a "square" (straight) edge across their opening so the overfilled measuring spoon (typically a teaspoon) can be drawn against that edge as it is withdrawn from the container thereby scraping the excess back into the container in one smooth motion.
[Hint: save old baking powder containers, fill them with, for example, baking soda, cream of tartar, cayenne pepper, etc. and just *tape* the label from the original soda/tartar/pepper/etc. container *over* the "baking powder" label to avail yourself of this ability on those "small quantity" ingredients. My next such container is slated for repurposing as a "(popcorn) salt container"!]
An experienced cook/baker also learns how to use the measuring cups/spoons for fast *liquid* measures: e.g., hold spoon/cup over your "mixing bowl"; pour liquid ingredient into spoon/cup until it is *just* getting ready to overflow; quickly tip spoon/cup to empty contents into mixing bowl *while* still pouring, returning the spoon/cup to it's upright orientation for the *next* "unit quantity".
Finally, those same "measuring containers" are used to dispense measured quantities of the final batter/dough into (or onto) whatever will carry it into the oven to be baked/cooked. E.g., I often use the "measured teaspoon" to define the "dough quantum" (gee, almost sounds like SCIENCE!) used when making cookies. The dough is invariably *very* viscous. E.g., a "cookie quantum" of dough would hold its shape for tens of minutes (in the absence of heat). So, trying to measure that substance in a "graduated container" would be a fool's errand (it wouldn't "flow" to fill the container evenly). Doing ~25 dozens (er, "30 'tens'"?) of these at a time means you look for shortcuts -- save 3 *seconds* on each cookie and you're done 15 minutes sooner)
Also, the dough/batter is often *sticky*. So, getting it in and out of the "measuring container" is a chore. E.g., I use the "measured tablespoon" to portion out pizzelle batter as I can wipe the batter out of the (smooth, hemispherical) measuring spoon quickly and efficiently (when baking pizzelles in a "two up" iron, you have literally a few seconds to dispense the first portion of batter before you *must* dispense the second one and close the iron lest the first "blob" get cooked while awaiting the second -- a pizzelle takes ~30 seconds to cook).
The annoying aspect of measuring spoons/cups is that you tend to only get one use out of each before it must be washed (and usually
*dried*) for the NEXT use. So, you learn to pre-measure all dry ingredients (cleaning a spoon/cup that has been used on dry ingredients is easily done -- by *wiping* it inside and out) BEFORE you tackle the (liquid) wet measurements. [note that you can reuse a spoon/cup that had been used for a liquid measurement on *another* liquid measurement as any residual liquid from the first ingredient just comingles with the second ingredient. This is not true if the second is *dry*]. And, as I mentioned earlier, you write your recipe to *suggest* which spoons/cups you should use in those measurements (4/3 vs. 1-1/3) so that you don't have to be insanely pedantic in your description of *how* to make the item ("Use the XXXX spoon to measure YYYY amount of ZZZZ. Then, use the AAAA spoon to ...")
Sorry, I didn't intend this to digress into a discussion about baking (but, I've spent close to 100 hours in the past month doing "holiday baking" so it is "near and dear?" to me... :< ). However, the same sorts of things apply elsewhere in daily living.
For example, the pesticides, fertilizers, herbicides, detergents we use are often mixed 1:128, 3:256, etc. (concentrate:water). (the 128 being a magical number related to ounces per gallon). Sure, those could be reformulated in a metric world (to 1:100,
3:200, etc.). But, they can likewise be reformulated in a NON-metric world to give us those nice round numbers!
[i.e., all these "insane units" don't bother people in their day-to-day life *or* professional lives. We work with whatever is appropriate for our needs AT THE TIME]
Because *they* have picked a format that is right for their particular needs (e.g., this instance of this application). For me to arbitrarily convert those to something that I decide AT COMPILE TIME is "right" would only coincide with their choice BY CHANCE.
E.g., if someone wanted to specify "4/3" instead of "1 1/3" then they presumably have a reason for that decision. The fact that they *didn't* specify "1.333" is telling.
No. I am pointing out a "fact of life". Are you advocating we should *legislate* bakers to bake "hot dog buns" in the same quantity that hot dog producers package their products? What would the penalty be for baking, e.g, *7* buns in a package? Would it be more or less than *5* in a package??
If I felt the need to "crusade" on something as big as this, I would rather spend my time reducing world hunger, pursuing a cure for cancer, or genetically engineering a strain of tomatoes that grows as "jars of tomato paste" (think of all the energy that could be saved from processing raw tomatoes!) instead of something this mundane.
We (US) live with all sorts of insane leftovers that are largely consequential of our FOREIGN ANCESTORS! :> Language, currency, systems of measurement, cultural issues, religious differences... fretting over "moving a decimal point" is nothing by comparison! :>
Consider how many languages, cultures, monetary systems (until VERY recently), legal systems, political systems, etc. Europeans have to deal with in a land mass smaller than the US. At least
*we* all drive on the *same* side of the street, have the same currency, speak the *same* language AND SHARE THE SAME SET OF INSANE UNITS! :> One could argue that europeans are "a good deal beyond 100+ years" late in "fixing" those problems...
What would the recipe be for *one* cookie? Let's see, the "yellow cookies" that I just made use, on the one hand, 10C flour, 2C sugar,
8 eggs, 1 lb butter, etc. And, at the other extreme, 1 tsp (!) of salt. For ~300 cookies.
So, a cookie would be 1/30C flour (lets call that 1 1/2t -- actually
1.6 but we can't measure 0.6t), about 1/3t (0.32) sugar (I don't have 1/3t measuring spoons but I suspect they might exist), 0.0266 egg (no idea how you would measure that... AFTER scrambling it, of course), about 1/3t butter (hey! I guess there'll be a market for that 1/3t spoon after all!) and, of course, 1/300t salt.
Of course, using these unit of measure for such a ridiculous quantity (bake *one* cookie?) is nonsense. Yet, expressing them as decimals EVEN IN METRIC UNITS is equally ridiculous!
Each Rx is different. Even if you're just making "drop cookies" (where you are unconstrained by size or quantity), you just wouldn't make huge quantities of certain types of recipes. E.g., making more than 4 or 5 dozen macaroons would require you to have lined up some serious "coconut addicts" to eat them! OTOH, 25 dozen "yellow cookies" will have two families regretting how quickly they "disappeared".
And, some things are made in specific containers. Those containers dictate/limit the size of the recipe that "fills" them. E.g., my cheesecake Rx can't use more than 1 1/2 pounds of cream cheese lest it not fit in the baking dish. Anything *less* than 1 1/2 pounds would require finding a smaller dish (otherwise the result isn't thick enough for the right "mouth-feel").
Someone who bakes (puts roofs on houses, cuts timber, frames houses, etc.) *knows* what he/she needs for that activity (application). Just like an EE knows about amps and watts (but probably not about wind-sheer loads on a steel structure; or how many minutes-per-pound to cook a turkey).
Newcomers to any "field" have a learning curve. Handing them several tomes and expecting dozens/hundreds of hours of "learning" won't gratefully be offset by "Ah, but all you need to do is shift a decimal point (after you have done the rest of the math)!" :-/
To a person writing cookie recipes, "maths" aren't of interest. Just like wind chill factors and temperature humidity indices aren't of interest to folks living in this part of the country (where we rarely see "cold" temperatures or any significant humidity).
Forcing people to consider *a* thing (style, technique, etc.) as *artificially* important imposes a prejudice on that "thing" that could be meaningless to them. Each industry, application, user-base, etc. adopts things (conventions, etc.) that are appropriate to it. They don't, then, crusade that all others recognize, acknowledge and adopt *their* "wisdom". A machinist concerns himself with "smoothness of finished surface". A guy laying asphalt worries about the pitch of the road and the relative height of the crown. Each picks a unit that is pertinent to their needs. (In one application, the units of measure were "scoops of aluminum grit". "Um, how big a scoop? How fine a grit?" "*This* scoop. *This* bag of grit." Not "scientific"? Sure, it may have been hard to convert to some other units of measure... but, it was accurate and reproducible FOR THE APPLICATION)
What's so "completely unusual" about "1 1/3"? What's so *ambiguous* about it?
Instead, you want me to *force* people to express values in some consistent manner that MAKES MY LIFE EASIER. Gee, I am touched by your concern... ;-)
Hmmm, you're an "engineering professional" -- yet *you* don't know if such a thing exists. Or, what it *is* if it does exist! Yet, you expect Joe User to have that knowledge INTUITIVELY? Just so he doesn't have to write "2 1/2"? Hmmm... I don't see the "favor" you are doing him...
No, it's not *always* possible. But, if the user is adding "feet" to "nautical miles", I can be ALMOST POSITIVE that he isn't talking about the archaic "metric_foot".
No, I only ask if I *must*. Your approach is "burden the user with telling me everything unambiguously EVEN IF THAT ISN'T NECESSARY".
E.g., what do I care *which* "foot" is being referenced if the user says "5 ft / 3 ft"? The answer is "5/3". (e.g., if I am trying to decide how many studs I will need for a 12 foot long wall: "12 ft / 16 in" leads me to the answer "10".)
When you "start a session" with my calculator, you pass it an initial environment in which to work. It needs to know things like how precise you want your answers, what range of resources you are willing to commit to its use (etc.) -- and, what set of units (and abbreviations) you want it to recognize. This is done by issuing a query against the main "units" database to isolate those units of interest. (there are some predefined VIEWs that act as shorthands for common usages).
You can be pretty sure a "baking application" won't be interested in watts, ergs, acres, siemens, furlongs, AU's, inverse seconds, etc. :> So, you only provide those units that the application will need.
Similarly, a "barcode printing application" won't need cups, teaspoons, liters (unless it tracks ink usage?), mhos, etc. OTOH, it probably would need support for english and metric units ranging from fractional inches/mm to feet/meters.
So, at any given time, the range of units that a user (via an application) will typically need is severely constrained.
*AND*, it allows the user (presumably conversant *in* that application/application domain) to use the units that are INTUITIVELY APPROPRIATE for that application without being burdened with formally specify EXACTLY the unit in question.
Huh? I can't figure out what you mean, here... :< How does "2 ft" differ when hands are "horizontal from each other" vs. "on top of each other"? (I can't see the imagery intended)
You keep thinking like an engineer. Go ask a (commercial) fisherman how he writes "4 times 5". Do you expect him to write "(4)(5)"? Or, "(16 cod - 3 trout) * 2 fishermen / 120 gallons fuel = ..."?
Exponentiation has a higher *precedence* AMONG (traditional) OPERATORS. Which "operator" is it binding more tightly than in the above example -- the "" (i.e., "absent space") operator?
You're *requiring* the use of a superscript (and, therefore, some means of representing it in an alternative form when superscripts aren't available -- e.g., ASCII) to represent something that we already have a means of representing (e.g., "sq/cu in/ft/yd/mi").
The water bill came today. Units of "Ccfs" (hundreds of cubic feet). Do I *care* how many "gallons" that is? Will it matter to me if the price is $6.23/Ccf instead of $62.30/Kcf? Will it change my actual *bill*?? Obviously, when measuring household water consumption on a monthly basis, someone realized that "hundreds of cubic feet" are precise enough to give good resolution to the bill without providing superfluous detail
("Gee, look, Bob! We used 10,321 gallons of water last month -- up 500 from the month before! Allowing for the extra day in this month, we seem to be using 5 more gallons PER DAY than last month!" "Yes, Lucinda, but we gave the dogs -- BOTH dogs -- baths this month so that probably accounts for 40 or 50 gallons. And, rainfall was down by 0.05 inches so we had to water the artichokes from the garden hose -- which might account for another
50 gallons over the course of the month...")
Our (natural) gas is measured in cubic feet. Yet, we are billed in therms (as we pay for the *energy* content of the gas separately from the transportation/delivery costs). So the "cost per therm" is related to "cu ft" by some (bizarre) formula -- which varies monthly. Aside from the total cost, all we really care is what the trends in consumption are. The units are unimportant (as I suspect most folks know *neither* that their usage is measured in cu ft *nor* how that relates to a therm -- they just know they used more or less this month than the month before... "and it's still SUMMER")
The point of all this rambling is that we have lots of units. That we don't lose much sleep over all these different units. And, that they don't materially change the "cost of doing business/living"!
Making tools that *fit* with their existing practices is one less obstacle to their adoption of those tools.
(sigh) None of this is adding to a resolution of my original post. Yes, I "get it". You are intimidated by all our insane units. Fine. You don't have to deal with them.
*We* already do "deal with them". And, I suspect it won't be in the lifetime of any of the folks reading this (today) that these issues "go away". That's why I have a mechanism to let my applications accurately deal with all these units (and, moving to/from MKS is literally just a handful of entries in the database!) -- instead of littering lots of source code with ad hoc conversions (which present innumerable opportunities for error).
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.