LabVIEW 2021 – Help with Taylor Expansion of e^x Without Built-In Functions

[GradTA]

Last year, I asked for help writing a code to calculate the Taylor expansion of e^x without using built-in functions like summation or the direct e^x function.

Now that the new year has started, I’ve picked the project back up but ran into some problems. One issue I’m stuck on is how to correctly sum the iterations together. My current idea is to try implementing an array, but I’m not sure if that’s the best approach.

I’ll attach the code my fellow student and I have written so far so you can see what we’ve managed to work through.

PS: This is not an assignment - I’m genuinely just trying to get this working at this point.

Note: This is being done in LabVIEW 2021, since that’s the version available in our lab (I don’t have control over upgrading it)

[altenbach]

---

@GradTA wrote:

Last year, I asked for help writing a code to calculate the Taylor expansion of e^x without using built-in functions like summation or the direct e^x function.

---

Do you have a link to the old discussion?

(maybe have a look here...)

(It is still super annoying if the front panel and diagram is maximized to the screen!)

[Kyle97330]

Well my initial question to ask would be how aware of the different data types you are?  You are currently mixing orange (floating point) wires with blue (integer) wires.  The default blue wires are limited to ±2.1 billion (32 bits, including one sign bit).  That caps out after 12!.

Two options present themselves.

First, if you switch to using more "orange" wires, you can technically get up to 10^308 before it can't go any higher, but you have to be aware that the higher the number gets the more accuracy you lose.  I believe that it's around 2^53rd power that it starts incrementing by a minimum of 2 at once, so it starts treating (2^53)+2 and (2^53)+3 as the same number.

In addition, if you want to use more bits, you can right-click and select "representation" and change the DBL values to EXT, which allows much higher numbers to be used (up to 10^4932) as well as much more precision on very low numbers.  It does take longer to process, but that's not really noticeable unless you're running thousands or millions of iterations.

Second, you can adjust your algorithm.  Since you're just trying to divide by n!, that means that if you instead just divide by 1, then divide by 2, then 3, all the way to n, you don't actually need the factorial itself, you just need to divide by the first n integers, one at a time.  There might be other clever things you can do besides this.

[GradTA]

https://forums.ni.com/t5/LabVIEW/Taylor-expansion-of-e-x/td-p/4405739

Sorry about the panels being that way. I work with dual screens so i'm use to it.

[altenbach]

Kyle already explained your issues with numeric representations. Most wires and diagram constants should be orange! Only items relating to iterations should be blue.

Here are a few more comments:

• What's the purpose of the "exponent base" input and why is the default zero?
• Why do you think you need to calculate e+(base) many times, even thought e result never changes? That can be done once before the loops!
• None of your inner loops should be needed because most calculations are repeated with every iteration of the outer loop.

Did you look at my example? try to understand it!

 

[GradTA]

I only use it when I'm in a specific research lab room. So, I'm not aware of the meaning behind things such as colors of line or data types. I was only given maybe a 10-15 minute introduction to LabVIEW when I started. 

Thanks you for explaining the difference between DBL and EXT by the way, I appreciate it.

[Bob_Schor]

"Simple", I thought, "Just use the Maclaurin expansion e^x = 1 + x + x^2/2! + x^3/3!... until it converges."  Hah!  it turned out to be something of an interesting challenge.  I stumbled around until I got it to go with a While Loop having three shift registers, one divide, one multiply, one add, and one increment.  My test for convergence was that the increment being added to the final (Maclaurin) sum is less than or equal to the Machine "epsilon" (an interesting constant found on the numeric palette).

I had enough fun with this self-challenge that I'm going to wait a few days before posting it to give @GradTA a chance.  I will say (for what it is worth) that there are no Arrays in my code.

Bob Schor

[altenbach]

---

@Bob_Schor wrote:

I stumbled around until I got it to go with a While Loop having three shift registers, one divide, one multiply, one add, and one increment. 

---

I used four shift registers, but arguably one is just (i+1) in DBL.... 😄

[Bob_Schor]

I should have known, Christian, that you not only came up with a solution very similar to mine, but did it almost 1.5 decades ago.  No need to show what I came up with -- very similar to the others shown here.  Just for fun, I timed it with the High Resolution Relative Seconds stopwatch -- about a microsecond for e^1 and two to three microseconds for e^100.

Bob Schor

[GradTA]

1. The “exponent base” was my attempt to follow the professor’s request that the inputs be adjustable independently. He wanted x, n, and the numbers of terms to be able to be changed independently I thought adding a base input would let me extend from e^x to a more general a^x. Now that you've pointed it out, it's not necessary for the assignment considering the base of e^x the base is always e. Also, I mistakenly left the default at 0 when saving the file, which isn't meaningful and I know can cause errors. Going forward I may just remove that control entirely. 

2. You’re right, repeated constant calculation isn’t efficient. At the time, I thought keeping it inside the loop was necessary so that each of the inputs (x, n, terms) could be adjusted independently, as the professor had requested. But I now understand that constants (like $\ln (a)$ if we generalize to a^x) don’t depend on the iteration counter, so they can be computed once before entering the loop.

3. You're right, in my first approach, I used inner loops to explicitly compute powers (x^n) and factorials ($n!$) each time. I did this because I was thinking literally in terms of the Taylor series formula, and I wanted the ability to adjust x, n, and terms independently, just as my professor requested. But that design repeats a lot of unnecessary work. 

I've noticed something about your code after making it myself. You've combined the value of "n" and the numbers of terms. In the first term n=0. Another way I can explain is that if I set the terms at 5, and the x value to 2, I should get a summed value of 7.000. Your code gives the value for the first 6 terms in the series summed. and if you look at your expected value, it's closer to the first 16 terms summed. This is why I wanted independent controls for x, n, and the number of terms. 

I do appreciate you pointing out some issues in my code.