No I must say I did not test my code. I was in a hurry I only had a short time to get stuff done for the day. Also the First part of the code worked, and was also decently fast. The last code was supposed to take the equation of the line of LDER1Y which was the first Derivative and fine that derivative, or the 2nd derivative of the original function.

I am sure their are optimizations, which I will work on later. I just need it to work for now. I will think about how to get that to work.

hhmm. This may be an epic flail but 2 possibilities that might work. The former might work better than the latter.


Code:

Ok I thought of something that should work, since nDeriv clearly will not.
This is with the entire code.


Code:

Removed the if/then statement and used ans for setting list dimensions.


Code:

Oh right. I knew that. I was mostly making sure it would work. Then Optimize it. Thanks though.

Well, does it work? You can test yourself by running it with a program where you know the first, second, and third derivative, and seeing what happens.

Let's take this polynomial:

Code:

We'll call the coefficients c_i and the exponents e_i:

Code:

See how that maps back to our first expression? (Pay close attention, now.) For any general set of coefficients and exponents, the derivative (with respect to x) of

Code:

is going to be

Code:

That is, each term will have its c_i multiplied by the respective e_i, together multiplied by x raised to the power of one less than the same e_i.

Applying this rule to our earlier set of c's and e's, we get:

Code:

=

Code:

=

Code:

Which is the correct derivative of our polynomial.

We already know the "x^" and "+" pieces are never going to change. If we were to write a program, we'd be more interested in those dynamic components, c_i and e_i. We'll dissect those outright and group them into lists:

Code:

Now, the challenge is to figure out the coefficients and exponents of the derivative using just these numbers. Again, we'll multiply each c_i and e_i together to form the new coefficient list, and we'll subtract one from each e_i to get the new exponents. From this, we should end up with the proper number components for our first derivative.

Here's the two-step process:

Code:

As proof, remember our derivative from earlier:

Code:

You may extend this to the nth derivative.

An excellent, well-written, and very thorough post, Weregoose, thanks for that. Aes_, you could then combine that with string manipulation functions to build yourself a symbolic Nth derivative, assuming that you haven't already been trying to do so.

I sort of tried talking him out of it. One would have to apply strong regulations on basically anything and everything that the user might type, including minus signs, square/cube signs, implicit X^1 and 1*X, and otherwise spurious instances of the variable. One might as well beg the user to provide the relevant digits apart from their polynomial forms. In terms of practicability, a string of "#X^#+#X^#+..." is as much as I'd ever want to work with.

Nonetheless, we're designing a program to do just that.

I did mention for him to continue down the long and winding road for the sake of practice, but the premise of the program sure doesn't have it as a requirement.

So I am working with sub( and trying some new (some would say simple) Things. and they are not working right. I am remaking my MathPack with some more complex code. One of which is this.


Code:


while working this, I may have just found my problem

Edit: nope I thought that having. L1(U)-L1(U-(U>1) would fix that, but it does not. I get a domain error right on the sub( line