> Now, 1/e is approximately 368/1000 and so I can calculate a power by
> making a macro in the assembler that multiplies that value times itself
> (at) times and then take that time 256 divided by 1000. The value (at)
> can not be more than 255/256 and probably will not be more than about
> 192/256.
>
> 368^192 exceeds 32 bits by a little tiny bit.
>
> I guess the question is: How does one calculate a fractional power to
> any degree of accuracy in 32 bit integer math?

>
> Thank you, Olin, for that informative response to a question I didn't ask.
>
> This is NOT about designing professional quality digital filters. Nor is
> it
> about embracing the digital realm.
>
> This is about educating people who understand analog systems and showing
> them that the same basic thing can be done in a digital system.
>
> How about we just stick to this question:
>
> How would you calculate e^(-at) in 32 bit integer math?
>
> ---
> James.
>
>
>

>
>
> First, congratulations on a great name.
>
> Now, that "!" in there is a factorial right? So I have to have one macro
> to
> calculate that...
> ...errr, hang on is that (X^2)/(2!) or (X^2/2)!?
>
> Then the power function x^2 then x^3 and so on. No problem.
>
> Now, x in this case is a negative number... So are we really calculating
>
> (1/e)^(x)
>
> ? And does that affect that series? Or do we just put in a negative number
> so that every other term of the series turns out negative?
>
> Finally, the input value is expressed as a fraction of 256. E.g. the value
> is 92 to represent 92/256 which is about .360 so what we really want to
> calculate is
> e^(-.36) which is supposed to come out to .697 or 179/256.
>
> is then
> =1-.36+(.36*.36/2)+(-.36*.36*.36/6)+(.36*.36*.36*.36/24) and so on?
> =1-.36+0.0648-0.007776+0.00069984
> =0.69772384
>
> Well, would you look at that! It works....
>
> Ok, so I answer my questions about negative exponents and about the
> factorial.
>
> But I can't put in 92 and get 179 out.
>
> ---
> James.

>
> James,
>
> I read your message - twice, and don't understand what your trying to
> achieve.
> Do you want to compute e^x with PIC code or do you want the assembler to
> do it? If you're using the PIC, then I'd consider a lookup table with
> first order interpolation or a CORDIC implementation. You'll have to
> normalize your input (or your 'at') so that a single table can accomodate
> a large range with a single table. However, for the series approximation
> you'll also need to perform some kind of normalization if you wish to keep
> just a few terms in the sum. I get suspicious when people claim they need
> 32-bits for a computation, and it sounds like this is what you're claiming
> here!
>
> Scott
>

>At 09:34 AM 10/15/2005 -0700, you wrote:
>> > How would you calculate e^(-at) in 32 bit integer math?
>> >
>> > Why does it need to be integer math?  From your previous post
>> > I got the impression this calculation was going to be done at
>> > assembly time.
>>
>>The assembler I'm using only supports integer math. No fractions. No
>>floating point. Just integers. So if you put in .36 it becomes 0. 92/256 =
>>0. Integer math.
>
>Okay so you imagine a radix point at an appropriate place. You can move
>it around after each intermediate calculation with shifts, provided you
>don't overflow. Unfortunately, you've got to deal with "C-like" integer
>math and don't have access to the full 64-bits of a multiply, only the
>least significant 32 bits.
>
>For example, 0.36 might be represented as 0x0002E14 (0.36 * 32768). The
>radix point is between the MS 2 bytes and the LS 2 bytes.
>
>>How do you calculate e^(-x) where x is between 1/256 and 192/256 using only
>>integer math.
>
>A Taylor series might do it acceptably well.

> at EQU 256* 360000/1000000
>         movlw at
> ;for a digital equivalent to an RC filter with a
> ;360kOhm resistor and a 1uF capacitor
>
> That puts 92 in w which is 92/256 = 0.360 = RC
>
> So that students may alter the R and C values somewhat and see the results.
> But I can't get it to calculate the second value e^(-at)
>
> Olin was exactly right in a previous post. You can't scale it by 256 (or any
> other constant) and then de-scale it by the same amount at the end.
>
> There may very well be more efficient ways to do this, but this way is
> directly derived from the diagram above and that diagram is very easily
> derived from the operation of the standard low pass RC filter circuit.
>

> Hi!
>
> On 10/16/05, James Newtons Massmind wrote:
> > >
> > > The values should be already scaled. Then, you plot your table
> > > as an X/Y plot and fit a polynomial function to the data. In
> > > excel, this is really easy (add tendency line, select
> > > "polynomial", and "show formula".
> >
> > Well, yes, that would get me a formula, but would the formula evaluate
> > correctly in integer only math?
>
> The formula would be like
>   a * x^2  + b * x + c
>
> As X is an integer (already scaled), X^2 is also an integer.
> Now, you can replace "a" and "b" by two fractions:
>  a = An / Ad
>  b = Bn / Bd
>
> So, you have the formula:
>   (An * X * X / Ad) + (Bn * X / Bd) +  C
>
> As you are rounding each of the terms, the largest error
> would be 0.5 + 0.5 + 0.5 = 1.5, less than 2.
>
> You need to make sure the multiplications are less than
> 2^31 = 2147483648 , to avoid overflow, this will restrict
> the values for "An" and "Bn" above.
>
> A better formula is possible using an approximation like:
>    (A1 * X * X + A2 * X + A3) / (B1 * X * X + B2 * X + B3)
>
> But I think that excel can't give you that kind of approximation
> (it's a rational function). A program like "gnuplot" can fit
> any formula to your data.
>
>      Daniel.
>

>
> Not the PIC. The Assembler. The assembler only supports integer math. It
> happens to be 32 bit.
>
> The problem is that I have to work with a fractional value. For example .360
> and it is represented as a fraction of 256. e.g. .360 = 92/256 so the value
> I have is 92 which means .36
>
> I need to calculate e^(-x)
>
> Even if I had a power function (and I don't) it goes wrong at the point that
> I put in 92/256. At that point the assembler returns a value of 0. In
> integer math, 92/256 is zero.
>
> So how do you calculate e^(-x) in integer math?
>
> ---
> James.

> > Let us take for example the Simple RC (resistor-capacitor)
> low pass filter.
> > This circuit passes frequencies in the input voltage that are lower
> > than some critical frequency (called the cutoff frequency)
> determined
> > by the resistor and capacitor values, while severely
> attenuating any
> > higher frequencies.
>
> Good so far.
>
> > The output voltage Vout, then, is simply a selectively
> reduced version
> > of Vin (input voltage). The resistor drops the output
> voltage, as does
> > the voltage that goes into charging C. At first, Vout = a *
> Vin (where
> > the constant a is the amount of attenuation caused by R and
> C). It can
> > be shown that a=1/RC (where R is in ohms and C is in farads).
>
> To quote Bob the Angry Flower,
> No! Wrong! Totally wrong! Where'd you learn this?
> -- http://www.angryflower.com/bobsqu.gif
>
> It's not even dimensionally consistent.
>
> For the very special case where we have been applying a sine
> wave to the input for a long time,
> Vout(t) = a * Vin(t-p) (where the constant a is the amount of
> attenuation, p is the phase lag), but that constant a depends
> on R, C,  *and* the frequency f of the sine wave.
> For any other input (square waves, triangle waves, white
> noise, etc.), the output is *not* a scaled version of the
> input, but a distorted
> ("rounded-off") version of the input.
>
> When we apply a slow square wave to the input (one far longer
> than 10 time constants), the output is *not* an attenuated
> square wave.
> When the input switches from Vhi to 0,
> I see that the output starts at
> Vout(0) = Vhi
> .
> and decays like
> Vout(t) =  Vhi * exp( -t / (R*C) ).
> until the output is practically 0.
>
> When the input switches from 0 to Vi,
> the output starts at
> Vout(0) = 0
> and rises like
> Vout(t) = Vhi *( 1 -  exp( -t / (R*C) ) ).
> until the output is practically the same as Vhi.
>
> (There are very small deviations from this theory caused by
> the non-ideal parasitic ESR of the capacitor, but the ESR
> (and the deviations which depend on it) cannot be calculated
> from R and C.)
>
> > The voltage change with time across a capacitor is an
> exponential function.
> > If the voltage at time zero is V, then the voltage at time
> t is given
> > by
> > Ve^(-at) (a is the Same constant as above).
>
> > I need to find e^(-at) given the value of at.
>
> I think someone has unnecessarily confused you.
>
> While the output voltage
> (while the input is zero)
> may decay like
> Vout(t) =  Vhi * exp( -t / (R*C) ),
> that is *because*
>
> * electrons are leaking out of one side of the capacitor,
> through the resistor, and back to the other side of the capacitor.
> * When there is a higher voltage across the resistor, the
> electrons flow faster.
> * When there is a lower voltage across the resistor, the
> electrons flow faster.
>
> No matter what the input voltage does, if use very small time
> steps h, and keep track of the number of the number of excess
> electrons Q across the capacitor, we can approximate the situation as
>
> Vout(t) = Q(t)/C ; output voltage
> i(t) = (Vin(t) - Vout(t) ) / R ; current through resistor
> into capacitor
> Q(t+h) = Q(t) + h*i(t) ; next count is the old count plus
> however many new electrons came in (or out) over that time increment.
>
> In C, one could write this as something like  const
> conductance = 1/R;  const reactance = 1/C;  for(;;){
>     Vin = get_next_input_voltage();
>     current = ( Vin - Vout )*conductance;
>     time = time + h;
>     charge = charge + h*current;
>     Vout = charge * reactance;
>     cout << "Output voltage at time" << time << "was" << Vout;  }
>
> Did you notice that there are no exponentials in this code?
>
> Some people would "optimize" the inner calculations of that loop into:
>  for(;;){
>     Vout = Vout + FF*( Vin - Vout ) ;
>     time = time + h;
>     cout << "Output voltage at time" << time << "was" << Vout;  }
>
> which is astonishingly similar to the very first response you
> got (from olin):
> FILT <-- FILT + FF * (NEW - FILT)
> .

> David's "tutorial" seems quite complete and succinct to me.
> No necessary steps and complications, and it goes directly to
> the target:
>
> > > Vout(t) = Q(t)/C ; output voltage
> > > i(t) = (Vin(t) - Vout(t) ) / R ; current through resistor into
> > > capacitor
> > > Q(t+h) = Q(t) + h*i(t) ; next count is the old count plus however
> > > many new electrons came in (or out) over that time increment.
>
> IMO this can be understood by everybody with minimal analog
> knowledge, as the basic concepts are simple: current through
> a resistor, and charge in a capacitor, and how these relate
> to the voltages across them. For me, that's close to perfect
> as an introduction. From here to a program is a very small
> step (as David also showed). This also can be very easily
> implemented in a spreadsheet, with the associated graphs.
> (FWIW, I'm sending one to you by
> email.)
>
> And since this is the "right" thing (IMO, of course :), it
> contains two hooks for further exploration:
> 1- proper modeling with derivative equations (that's possibly
> not the proper term...) and then solving these digitally, to
> increase the "depth"
> of understanding of this -- because it already presents one
> result of this more theoretical approach in a simplified form, and
> 2- the various forms of digital filter equations as they are
> being used, to increase the knowledge about digital filter
> applications -- because it ends up with one of the simplest
> of them in exactly the form it is being used in "real" applications.