Re: Table length reduction

Chris Rokusek wrote:
>
> D.C.,
>
> Understood. I see that what you're doing seems to be fairly independent of
> the choice of spline. Although the choice of spline would definately change
> the answer it seems that since you're not introducing any new points it does
> not introduce an error (just perhaps removes different points).
>
> Could you describe the error function in more depth (I don't trust my
> Icon-ese)? Does it work well for small values near 0.0?

The first time through I used relative error, but on reflection (!) I
decided that people weren't using IBIS for noise analysis in the time
before a transition. So instead, I just took the absolute difference
between the input point and the interpolated value and called it good.

In order to compare typ/min/max on more or less equal footing, the
errors for each are normalized to the largest absolute value in each
column. The largest error term for each row is used to sort the
rows, and the (table length)/(2n+1) smallest error rows are
candidates for culling. For a cubic, this means that 20% of the
table could be culled in each pass.

To answer the direct question, near zero isn't special.

> > -----Original Message-----
> > From: dsession@isis.vlsi.com [mailto:dsession@isis.vlsi.com]On Behalf Of
> > D. C. Sessions
> > Sent: Monday, May 08, 2000 12:48 PM
> > To: IBIS Mailing list
> > Cc: Chris Rokusek
> > Subject: Re: Table length reduction
> >
> >
> > Chris Rokusek wrote:
> > >
> > > D.C.,
> > >
> > > A Natural cubic spline will often introduce non-monotonicity
> > resulting in
> > > simulation instability or inaccuracies especially on diode
> > curves. You will
> > > need to use a different spline.
> > >
> > > Don't believe me? Try
> > >
> > > http://www.glue.umd.edu/~tvp/interp.html
> > >
> > > and draw a monotonic diode curve.
> >
> > Chris, I'm not doing interpolation. I'm using interpolation to cull
> > redundant points. The algorithm works by calculating a spline from
> > the four points adjacent to a subject point and interpolating to
> > that point. Those points with minimal discrepancy from the interpolation
> > are candidates for removal and their immediate neighbors are kept until
> > the next pass.
> >
> > Then again, one of the things I love about Icon is that prototyping
> > is awesomely fast. By all means try a different algorithm...
> >
> > > > -----Original Message-----
> > > > From: dsession@isis.vlsi.com
> > [mailto:dsession@isis.vlsi.com]On Behalf Of
> > > > D. C. Sessions
> > > > Sent: Monday, May 08, 2000 10:30 AM
> > > > To: IBIS Mailing list
> > > > Subject: Table length reduction
> > > >
> > > >
> > > > OK, I said I'd have a go at a program to intelligently
> > > > reduce the size of IBIS tables so that we can have high
> > > > resolution where needed and still keep below the 100-point
> > > > limit. Here is is, attached. The language will look
> > > > very, very strange to most of you; it's Icon, an academic
> > > > language that's sort of a cross between C and Prolog.
> > > > You can get documentation and a copy for most any platform at
> > > > http://www.cs.arizona.edu/icon/
> > > >
> > > > The program as written is pretty crude. It takes JUST the
> > > > table data and thins it out using a cubic interpolation.
> > > > Command-line syntax is
> > > >
> > > > decimate <pts> <file>
> > > >
> > > > Where <pts> is the maximum number of points in the output,
> > > > and <file> is the source. Output is to standard output, and
> > > > if no input file is specified it defaults to standard input.
> > > > It expects each line to have the same number of fields (and
> > > > will barf if they don't match). For unjustifiable reasons it
> > > > does NOT accept scientific notation in; it does accept 'munp'
> > > > suffixes. The output is scientific. If I'd been more awake
> > > > I'd have done both in scientific and left formatting up to a
> > > > perl or awk script.
> > > >
> > > > That said, I've experimented it several data sets and it seems
> > > > to produce reasonable results. Feedback, improvements, or a
> > > > complete rewrite to C welcome.
> > > >
> > > > --
> > > > D. C. Sessions
> > > > dc.sessions@vlsi.com
> >
> > --
> > D. C. Sessions
> > dc.sessions@vlsi.com
> >

-- 
D. C. Sessions
dc.sessions@vlsi.com