Subject: Re: Number of Significant Digits
From: Al Davis (aldavis@ieee.org)
Date: Thu Feb 28 2002 - 13:47:42 PST
On Thursday 28 February 2002 12:55 pm, AC wrote:
> "With more digits, you need more data points. With more
> data points, you need more significant digits...."
>
> I don't follow the correlation indicated above, at least without
> some more
> explanation. I always thought that the more significant digits you
> used, the better,
> as long as the additional digits represent a closer approximation
> to the actual datapoint (not just noise). (Numerical or other noise
> which does not represent actual physics being modeled does need to
> be cleaned up when the model is created).
I did not express that point clearly. Let me try again.
It is not the number of printed digits, per se, that matters but
granularity. Like you say, chopping off digits is just like making
them all zero. Suppose a measurement is accurate to "one third", so
you might have values like 3.33333, -2.666667, and so on. The fact
that you print the extra 3's and 6's is not what I was referring to.
Although it is meaningless, there is no harm in doing so. Sometimes
it may be of benefit to appear to carry extra decimal digits because
the true grains are not decimal. In this example, just saying 3.3
and 2.7 might appear to introduce additional jitter. As another
example, consider a grain size of one eighth. The values in decimal
would be .125, .25, .375, .5, and so on. Although it gives the
appearance that you are specifying to 3 digits, you are not. You are
specifying to less than one. I agree that just saying .1, .3, .4, .5
would be less accurate. Ideally, the data would covey that the
accuracy is one eighth. Remember also that the accuracy of your
measurement of an output is no better than your setting of the input.
What is needed is not just a chopping of digits but a proper
smoothing algorithm, which may give the appearance of adding extra
digits.
The issue is that you have a 2-dimensional graph, expressed in table
form. If you make one axis very high resolution and the other very
low resolution, a lot of what is passed on the high resolution axis
is noise.
The biggest issue in IBIS files comes up with high precision on the
input (time or voltage) axis, and low precision on the dependent
axis. I have never seen the other case. The nature of how models
are generated prevents it.
Let me answer your case specifically:
> The problem I've had when building models with tool-provided data
> (SPICE) of limited precision is that when the tool truncates or
> rounds successive values, it makes them either closer to the same
> value than they really were, or further apart, adding an additional
> source of numerical noise for no good reason. Sometimes the data
> says the values were identical (e.g. to 4 digits) when this is
> clearly not the case, so the model builder gets to decide which of
> two identical points to include and which to throw out.
In this case the original "Y" data is already of insufficient
accuracy to correspond with the "X" data. The tool further truncates
the "Y" data making the problem worse.
What you are saying actually supports my statement. You have a case
where there is insufficient accuracy in "Y" (to properly compute the
derivative), given the granularity in "X". When you say "the model
builder gets to decide which point to throw out", you are
appropriately reducing the granularity in "X" to correspond with the
low accuracy you have in "Y".
You support my statement in another way, too. You have values close
together. Take the derivative. If rounding caused values to be
identical, you have lost all information. What may have appeared to
be 6 significant digits may be only one in the derivative. The
number of digits needed is mostly determined by the need for accuracy
of the derivative. If the extra digits were noise, you have filtered
out the noise. By allowing the many noisy digits of "Y" to pass, you
may not be aware that they are in fact noise, and that you should use
fewer points in "X".
This archive was generated by hypermail 2b28 : Thu Feb 28 2002 - 14:07:03 PST