Re: Storing trailing zeros in mantissa

Comments below

<ctcgag_at_hotmail.com> wrote in message
news:20030801122021.888$dk_at_newsreader.com...
> "Jim Kennedy" <kennedy-down_with_spammers_at_no-spam.comcast.net> wrote:
> > Noons is correct. Jeff, the difference is purely one of display and not
> > one of actual percision.
>
> You and Norm clearly are not scientists! The difference between
> 10.2 and 1.02e1 is purely one of display, the difference between
> 10.2 and 10.20 is not, they differ in the number of significant
> digits. The fact that Oracle (nor any other RDBMS or programming
> language I'm aware) does not support this does not mean it isn't
> real. We're left with the options of either storing them
> as varchar2 (Ugh ugh), or using two columns, one for the number
> and one for the precision (Ugh) (or, one for the number in numeric
> form, and one the number in string form).
See below for a third option. It wasn't clear to me that you needed to know what percision the number was that you obtained. I have dealt with "manager" types that thought that just adding zeros to something meant it was more precise. eg 10% vs 10.000 % (even thought the percentage was a swag).

>
>
> > If you are using an interface (eg oci, odbc,
> > etc.) tp retrieve this data it will come back as a number and the added
0
> > wouldn't make sense.
>
> Wouldn't make sense to whom, to oci and odbc, or to the end user?
> It would make sense to me!

It comes back as a number not as a string representation of a number. So to do math on it (eg select mynumber*100 from mytable produces the same result regardless of how the number was entered.) It is in a memory location represented by a series of bits not a string representation typed in some font on a screen.

What you should do is store the number as a number and have another column to store the attribute of how percise that number is. (eg .01 or .05 or 1 or 5 or 300 whatever the percision is. ) Then you could do:

select 'this observation is in the range of '|| mynumber+(mynumber*percision)||' to '||mynumber-(mynumber*percision) from myTable;

or

select mynumber||' is somewhaere around '|| mynumber+(mynumber*percision)||' to '||mynumber-(mynumber*percision) from myTable;

That would be a much better system that models the real world. (You would be expressing the results of the experiment correctly.) Jim

>
> 10.2 is somewhere around 10.15 to 10.25, whereas
> 10.20 is somwhere around 10.195 to 10.205 and
> 10.2000 is somewhere around 10.19995 to 10.20005
> (of course, the last wouldn't be allowed with the given
> column definition.)
>
>
> > (it is a number) In sqlplus you will see it
> > depending upon how you have set your formatting to be, but that has
> > nothing to do with what the number is.(eg put in a number 10.12345432123
> > and you will probably get back a displayed number that displays less
> > percision, but if you use oci etc. you will retrieve the full percision
> > of the number. You can have the display display more decimals if you
set
> > the numeric format to be larger.) In short, if your other program wants
> > strings (and not numbers) then I would still store the number as a
> > number, but just do a to_char(myColumn,formatMask) to get it to "look
> > right".
>
> The problem is that what "looks right" is the number of decimals that
> were there, including trailing zeros, when the number was stored. Unless
> that information is stored, then there is no way to reconstruct what
> "looks right". If every value stored in a column has the same
> real-world precision, then it can be hard-coded as you suggest. But
> if each row can have a different number of sig figs beyond the decimal,
> which seems to be the case, then that information needs to be stored in
> some auxilliary manner.
>
>
>
> Xho
>
> --
> -------------------- http://NewsReader.Com/ --------------------
> Usenet Newsgroup Service New Rate! $9.95/Month 50GB
Received on Sat Aug 02 2003 - 01:31:42 CDT