Re: "normalizing" data
- From: "J.A. Legris" <jalegris@xxxxxxxxxxxx>
- Date: Sun, 28 Nov 2010 06:06:32 -0800 (PST)
On Nov 27, 6:33 pm, D Yuniskis <not.going.to...@xxxxxxxx> wrote:
J.A. Legris wrote:
On Nov 26, 11:33 am, D Yuniskis <not.going.to...@xxxxxxxx> wrote:
On Nov 26, 12:38 am, D Yuniskis <not.going.to...@xxxxxxxx> wrote:Exactly.
Furthermore, there can be significance to some of that stuffThere's that whole significant digits thing... Without further
that I am stripping off -- "2.000" is different from "2".
qualification, a measured value recorded as "2," implies that theYes. Fyziks questions are always best answered with one of the
actual value is in the range 1.5..2.5. "2.000" implies that the
actual value is between 1.9995 and 2.0005. The issue being the
(always finite) precision of your measuring device.
Any student in first semester physics who added "1.23 meters" and "3"
meters, and answered "4.23 meters" on an exam would be marked wrong.
- "a bright orange flame" (often qualified with "and a loud noise");
- "for sufficiently small values of (insert favorite quantity here)"; or
- any equation with a 'c' in it.
OTOH, I don't see any "significance" to the *actual* whitespace
used -- nor to *leading* zeroes.
OTOOH, I can't read the user's mind -- and I don't see any *huge*
downside to leaving all this cruft in place (i.e., if the user
thought it worthwhile to *enter* it that way... <shrug>)
There's one downside: the user might want to be sure that the data had
been properly interpreted and stored. We all make typos. Don't you
prefer to be informed of them as soon as possible?
Yes, that is the reason for not "reducing/normalizing" the data
(as I said in my original post). If the user wanted to specify
"2 ft 39.27 in" (!) then, presumably, there is a *reason* he opted
for that form instead of "5 ft 3.27 in".
*But*, is there any reason why I should *literally* preserve
" 00000002 \t \t feet 0039.270000000000 in "?
Would it "confuse" the user that much if he later saw it
as "2 ft 39.27 in"? I guess I just can't see where the
extra fluff becomes significant (unless it had to do with
formatting in the application that feeds the data to me).
You've interpreted my post exactly the opposite of what I meant. Read
If your programming is as sloppy as your reading, you've just
suggested yet another reason to normalize - there are probably a few
bugs in your code that will misinterpret some strings. The user needs
feedback that indicates exactly how the machine has interpreted the
- Re: "normalizing" data
- From: D Yuniskis
- Re: "normalizing" data
- Prev by Date: Re: "normalizing" data
- Next by Date: Pandaboard
- Previous by thread: Re: "normalizing" data
- Next by thread: Re: "normalizing" data