|
I expect you know that a milliHelen is the amount of beauty required to launch one ship.
|
|
|
|
|
The micro-fortnight: about 1.2 seconds.
Used as a time unit in some Unix systems, IIRC.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
The nano-fortnight (1.2mS+) was used as a unit by Control Data field engineers in the 1960s and 70s.
They used 3000-series processors as I/O channels for the 6600 etc.
There was a fixed slice timesharing setup on the channel, and it got round to each device in a nanofortnight.
I'm not sure if it was ever documented as such, but the unit was certainly well-known (in the right circles).
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Peter_in_2780 wrote: The nano-fortnight (1.2mS+)
Milli-Sievert? What does ionizing radiation have to do with fortnights? 
(For those who haven't noticed yet: SI units are case sensitive.)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
We build commercial inkjet printing systems, so measuring distances precisely is important. Our internal measurement unit for length is the micro-inch. We use this rather than the metric micron unit because some of our physical properties like resolution (600 dpi) are expressed in English units.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: expressed in English units.
Being an oldie I still use them. However, the next few generations have grown up using mainly metric, so the old Imperial measurements should probably be renamed American units.
|
|
|
|
|
Richard MacCutchan wrote: the old Imperial measurements should probably be renamed American units
This is an example a problem I deal with all of the time as our UI developer. Our industry has been around since the late 1970's, with many generations of products. On a larger scale we are part of the commercial printing industry. The end result is that we have a complicated vocabulary sprinkled with many terms that are to one degree or another synonymous. For the time being, "English" and "metric" seem to be the most prevalent terms for Imperial and SI units, respectively.
The good news is that I retire in four years, so it will soon be someone else's problem  .
Software Zen: delete this;
|
|
|
|
|
Have you noticed that for many years, inch (and foot, yard and all other inch-derived units) are derived from metric units? Inch is defined as 25.4 mm, so a micro-inch are defined a 25.4 nm.
Obviously, if your tools work in steps of 25.4 nm, µin will give you integral measurement values. Still, it is a measurement, so in a computer program, I would prefer to use float rather than integers. When teaching programming to beginners, I do not use the terms integer and float, but counting values and measurement values. Distances are characteristic measurement values. But you may want the exact measurement value to have a zero decimal fraction, so it could make sense to represent the measurements in 25.4 nm units.
I have been surprised by how many newer (30-40 years old or less) engineering products are really defined in metric units in the standards, but referenced/described in the US marked in approximate English units (such as a CD being described as a 5 in disk). We do it the other way, too: If you ask for "4 toms" (4 in) planks, or "to tom fir" (two by four) you get the 98 mm width, or 98×48 mm, with hesitation.
Some years ago, the Sun-Maid Californian raisin packs started appearing in Norwegian grocery shelves with a yellow banner across the top left corner: "Now in metric pack". That was no lie: The pack size was no longer half a pound, but 227 grams. It took a year or two before they adjusted it to 250 grams, but then they removed the "Now in metric pack" banner.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: I would prefer to use float rather than integer
In our case many of our computations have more predictable behavior when performed using integral values.
Of course, we convert things to double's with the appropriate scaling for desired units when they're shown to the user.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: In our case many of our computations have more predictable behavior when performed using integral values.
Just use picometers (pm) then and only allow multiple of 25400.
So if someone writes "5pm" they could be referring to a very small distance rather than a time of day.
And 1000000am = 1pm!
|
|
|
|
|
Gary Wheeler wrote: In our case many of our computations have more predictable behavior when performed using integral values.
Sure, handling counts may be more predictable.
But you are handling counts of 25.4 nm units. Not measurements. I find that conceptually wrong. And your count is not able to handle measurements that is not a whole number of your counting unit.
Another thing that surprises me is that you in the English system use a decimal scaling factor. Long time ago, around 1981-82 I was working on an office automation system. We were introducing varying-width typefaces to the document formatting. Relevant printer models had a resolution of 72 dpi, 96 dpi, 144 dpi, 300 dpi, ... So we did all positioning in a grid with a resolution of 1/86400 in. (You had to be one of the insiders to know why this unit was called 'AH' - it was the initials of the guy devising it ) Even though an AH has less precision than a micro-inch, it was exact for all the relevant printers, and all the common resolutions came out as a 'round' number of AHs.
Yes, we did handle it as an integer value. It wasn't a measurement, it was an index position (or the number of index positions filled) in a virtual point grid on the printing surface. It didn't relate to any hardware measurement. When the document was printed, it was reduced to a smaller resolution value, according to the printer's number of dots per inch. That implied a physical size, but from the software point of view, it was a count/index of a dot position, not a measurement.
At that time, I had not developed as strong an awareness about measurements and counts as I have today; that came as a result of a few years of teaching beginner courses in programming, learning how difficult it is for students to grasp the difference between integer and float. When I started referring to them as counts and measurements, the students handled it with much more ease. I have stuck to that since. If it really is a measurement, I represent it as a measurement. If it is e.g. a position index that does not imply a specific measurement value (say, a position on a chess board, which may be small or large), it is a count.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: you are handling counts of 25.4 nm units. Not measurements. I find that conceptually wrong
Toe-may-toe, tow-mah-tow  .
Our internal distance unit scales integrally with external physical units. External refers to dimensions of our inkjet array (the aforementioned 600 dpi), the tachometer used on the press to measure distance (1/1800ths of an inch), and many other values. This notion works well on a practical level despite its conceptual incorrectness.
Software Zen: delete this;
|
|
|
|
|
Count/measure abstraction works until you start falling between the cracks. Float is just another form of digital (discontinuous) number. It just happens to be designed to have high resolution in the 'general use' range.
Digital is still just integers however you slice it, and in fact, measurements are also 'just' integers since any measurement is limited by the resolution of the instrument (and likely further hobbled by variations in resolution over the instruments range). Aside, it is interesting to note; (nearly) every 'analog' clock is also digital, being limited by the resolution of the escapement.
The use of an 'AH' value is a perfectly acceptable, and common, use of the 'lowest common denominator' to reduce a real world measurement domain to integers suitable for computing. Anyone reading the code or using the system 'simply' has to be made sufficiently aware of the number systems in use and consequences there-of.
And there's the rub. The number of humans involved in being computer 'literate' grows exponentially year on year. The task of keeping them on the same conceptual and taxonomic pages has grown similarly to the point that, in my observation, it is now usually the biggest problem of all. Long-winded discourse on simple paradigms being required to 'bring everyone along'.
modified 9-Aug-24 8:33am.
|
|
|
|
|
You can't seriously argue that because measurement values have a limited precision (they do when written down on paper, too!), the there is no conceptual conceptual difference between a count and a measurement value.
They are conceptually different, even if a given measurement technology does not have infinite precision.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Sure I can and I do, for the simple reason that, the computer cannot represent real numbers (your notion of a 'measurement') as anything other than integers. The the earlier a developer realizes that, the simpler it is to conceptualize and manage the (many) translations and transforms between the multitudinous real number (measurement or other) domains and integers.
modified 10-Aug-24 10:06am.
|
|
|
|
|
I like the TÅ or Tera-Ångstrom, 100m in other words.
|
|
|
|
|
Have you ever seen that used in practice?
(Also note that Ångstrøm is not an SI unit, even though it is a ten-factor of an SI-unit.)
I was surprised to see astronomers referring to the mass of astronomical object in Tg, teragrams. That was clearly a dead serious unit, not meant as any sort of joke, and definitely within SI, just as much as kg. But we tend to use 'ton' rather than Mg (as we really ought to!) and kiloton rather than Gg. I honestly prefer Tg to "thousand kilotons".
Student humor is full of 'funny' derived units. Such as "square liter": The floor area covered by beer if you tip over two full glasses.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Never used it in practice, it was something a teacher at school came up with as an alternative name for an athletics event.
|
|
|
|
|
I have seen a lot of times the "k" for 1000 instead for 1024 or the "M" for "10^6" instead of "1048576"
Specially when speaking about money.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
k (lowercase) is kilo, 1000. (K (uppercase) is Kelvin.)
M (uppercase) is Mega, 1,000,000.
m (lowercase) is milli, 1/1000.
G (uppercase) is giga, 1,000,000,000. (g (lowecase) is gram).
Ki (Upper-lowercase) is kibi, 1024.
Mi (Upper-lowercase) is mebi, 1,048,576.
Gi (upper-lowercase) is gibi, 1,073,741,824.
The prefixes are valid for any unit, but you often see incorrect use: In economy, you often see KUSD, for 1000 US Dollars, which literally means Kelvin-US-Dollars. The correct use is kUSD.
I never saw binary prefixes (Ki, Mi, Gi, ...) used with money. Actually, I never saw them anywhere outside computer contexts. On the other hand, I saw a lot of decimal prefixes in computer contexts - almost all of it incorrect. You frequently see abuse of SI units, e.g. size of data object given in kB. What does sound pressure have to do with object size? (and: 1000 Bel is a sound pressure that would shake your house to gravel.) Maybe the size is even given in Kelvin-Bel, to suggest 1024 (Bel??) rather than 1000.
Note that networking people always used decimal prefixes. Besides, they count bits, not bytes. A 64 kbps line is 64,000 bits, not 65536 bits - and far from 65536 bytes! (When phone lines were digitized in the late 1980s in Norway, lots of computer enthusiasts complained to the telco when the didn't get 64 Ki bytes through the line, but only a little over 7.5.)
Also - particular attention to the youngsters among you: A byte being 8 bits, and that is final!, is a new phenomenon. I have been working with 6 bit bytes (Univac 1100 series), 7 bytes (DEC-10, DEC-20), 8 bytes (quite a few machines) and 9 bits (also Univac 1100 series). When I got my ham license, the only permitted "digital" (modem signal) format was using 5 bit bytes (Baudot code); I never used that myself. The classical definition of "byte" was the space required to store one printable character. When networking people talk about data sizes (e.g. in protocol definitions), if they are not talking about bits, they use octets to make perfectly sure that there is no confusion. I have seen protocol standards using 'byte' - a clear indication that the standard development has been dominated by young software people rather than by experienced networking people.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
one that annoys me is the use of mc instead of µ such as on tablets - "contains 5mcg" rather than "contains 5µg".
|
|
|
|
|
Units in SPICE (analog design software) can cause some really big mistakes:
m = 10^-3
M = 10^-3
MEG = 10^6
meg = 10^6
Kevin
|
|
|
|
|
Once there was a Codproject member, with such a name. But I cannot recall who…
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
once I understood what any of this meant, I spiralled into why the Mega Drive was called the Mega Drive
7.6 MEGA hertz cpu
16 MEGA bytes ram
upto 5 MEGA herts external bus
it was Mega
yeah, now I want a Tera Station
|
|
|
|
|
Since it requires a micro-scope to see a mega-karocyte, do I need a micro-micro-scope to see a micro-megakaryocyte ?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
