FW: Re: Handling really large numbers, dynamic ranges....

-----Original Message-----
From: Gene Silvernail [mailto:genes_at_belhaven.com]
Sent: Tuesday, September 03, 2002 4:09 PM
To: 'Elizabeth D. Rather'
Subject: RE: [swiftx] Re: Handling really large numbers, dynamic
ranges....

The data is 24 bits, as stated. Actually 28 bit plus sign. The lower 4
bits I discard as sub-lsb bits. The noise as stated is +/- 10 or +/- .59
ppm. Good resolution not over sampling generated bits.

The solutions that I see are:

1. Do something like below, cleaning it up with Horner's method
2. Do it with table look up
3. Do it externally in floating point

This kludge handles 2nd degree polynomials but is not factored
: >DEG-F ( d1 -- d2 )
        2DUP
>R >R
        1 1000 m*/
        2DUP D>S 1 M*/
        2ND-COEF-X2 10000 M*/
        R> R>
        2ND-COEF-X1 1000 M*/
        D-
        135620000. \
        D+
        1 10000 M*/
         ;

-----Original Message-----
From: swiftx-bounce_at_forth.com [mailto:swiftx-bounce_at_forth.com] On Behalf
Of Elizabeth D. Rather
Sent: Tuesday, September 03, 2002 11:54 AM
To: Swiftx Listserve
Subject: [swiftx] Re: Handling really large numbers, dynamic ranges....

At 02:42 PM 9/3/02 -0400, Bill Hall wrote:

>hi
>First I must ask what is the expected domain of the resultant y ?
>I ran 12,000,000 thru the equation you gave, and y goes way past 32
bits,
>in the negative direction.
>
>One suggestion is to rearrange the equation as follows:
>
>y = (((a)x + b)x + c)x +d .
>
>Then evaluate it as follows
>[etc....]
>But a is so small that you will need to scale the result UP to
>obtain any
>integer effect from the a term. Which leads me back to the first
>question
>because it is the a term that causes the result to go beyond 32
bits
>negative.

What is the actual resolution of the data you're starting with? That
is ultimately the limiting factor on the _real_ resolution of any result
you get. It's a common fallacy to take, say, 12-bit data and process
it with 32 bits of accuracy; you end up with mostly noise bits.

>You may be able to pick a scaling denominator for the data and use */
,
>thinking of the data as a fraction of some "full scale" like 16777216.

Better still, use M*/ to multiply your 32-bit intermediate result by
a ratio of 16-bit numbers (w/ extended-precision intermediate
product).

Cheers,
Elizabeth

==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

----------------------------------------------------------------------
swiftx_at_forth.com The SwiftX programming discussion email list
To unsubscribe, send subject "unsubscribe swiftx" to listar_at_forth.com
For help with listar commands, send subject "help" to listar_at_forth.com
Archives are located at http://www.forth.com/swiftx -- check them out!
----------------------------------------------------------------------
THIS LIST IS NOT FOR BUG REPORTS! Send bug reports to
support_at_forth.com.

----------------------------------------------------------------------
swiftx_at_forth.com The SwiftX programming discussion email list
To unsubscribe, send subject "unsubscribe swiftx" to listar_at_forth.com
For help with listar commands, send subject "help" to listar_at_forth.com
Archives are located at http://www.forth.com/swiftx -- check them out!
----------------------------------------------------------------------
THIS LIST IS NOT FOR BUG REPORTS! Send bug reports to support_at_forth.com.
Received on Tue Sep 03 2002 - 17:10:44 PDT