How to evaluate A Taylor series at a specific value

[parisse]

| is evaluated more like a program, where x would be like an argument. taylor(sin(x))|x=0.5 will evaluate sin(x) to sin(0.5) before taylor is called.
It's hard to evaluate |. You don't want to get sin(1) for sin(x)|x=2 if x:=1; has been run, yet you want to get sin(6) for sin(a*x)|x=2 if a:=3.
I don't like this notation, I prefer subst.

[Han]

(08-22-2018 06:56 PM)Albert Chan Wrote:  This is a bug.
Evaluate a taylor series while carrying the O[x] term is meaningless.
This is how Mathematica hande it:

In[1]:= taylor = Series[Sin[x], {x, 0, 5}]
Out[1]= x - x^3/6 + x^5/120 + O[x]^6

In[2]:= taylor /. x -> 0.5
SeriesData::ssdn: Attempt to evaluate a series at the number 0.5; returning Indeterminate.
Out[2]= Indeterminate

In[3]:=Normal[taylor] /. x -> 0.5 (* Drop the O[x] term, then substitute *)
Out[3]= 0.479427

BTW, Mathematica (v 4.0) had the bug too, if x had Pi in it.

In[4]:= taylor /. x-> 1/2 + Pi/10^10 // N
Out[4]= 1. 0.5 - 0.166667 0.125 + .00833333 0.03125 + O[0.5]^6

In[5]:= % // Normal (* above should be Indeterminate too ! *)
Out[5]= 0.479427

BTW, you can test evaluation order with this: (x/x) |x = 0
For Mathematica, it is evaluation before substitution, result = 1, not 0/0

Why would the evaluate of a function that contains an error term magically drop the error term? Just because a certain piece of software has decided to follow a particular convention does not mean that it is necessarily universal -- or even mathematically correct. (x/x) | x=0 is indeterminate. The expression x/x is undefined at 0. Even if one were to "evaluate first", the expression x/x only evaluates to 1 when x is non-zero.

[Albert Chan]

(08-22-2018 08:50 PM)Han Wrote:  Why would the evaluate of a function that contains an error term magically drop the error term?

Exactly !

Taylor series that carried the error term should not be evaluable, at any x.
The fact that taylor(sin(x)) | x=0.5 can return anything is not right. Unless ... (see below)

Quote:(x/x) | x=0 is indeterminate. The expression x/x is undefined at 0.
Even if one were to "evaluate first", the expression x/x only evaluates to 1 when x is non-zero.

It were meant to test the CAS order of evaluation.
If CAS does evaluation before substitution, x/x simplied as 1

But, if CAS return 0/0, taylor(sin(x)) | x=0.5 return sin(0.5) make sense.

[Albert Chan]

(08-22-2018 07:52 PM)parisse Wrote:  | is evaluated more like a program, where x would be like an argument.
taylor(sin(x))|x=0.5 will evaluate sin(x) to sin(0.5) before taylor is called.

It's hard to evaluate |. You don't want to get sin(1) for sin(x)|x=2 if x:=1; has been run

If "|" is like running a program with argument x:

taylor(sin(x))|x=0.5 ==> (lambda x: taylor(sin(x))) (0.5) ==> taylor(sin(0.5)) ==> sin(0.5)

sin(x)|x=2 ==> (lambda x: sin(x))(2) ==> sin(2)

Why does "|" hard to evaluate ?
Why previous run of x := 1 affect it ?

Maybe "|" is simply "evaluate at" ?
However, that imply taylor had a bug (post #23)

[Tim Wessman]

It is hard to evaluate because there are equally many cases where the "correct" behavior is substituting before, vs substituting after. You can't know which is "correct" programmatically.

[Han]

(08-23-2018 02:30 PM)Albert Chan Wrote:  

(08-22-2018 07:52 PM)parisse Wrote:  | is evaluated more like a program, where x would be like an argument.
taylor(sin(x))|x=0.5 will evaluate sin(x) to sin(0.5) before taylor is called.

It's hard to evaluate |. You don't want to get sin(1) for sin(x)|x=2 if x:=1; has been run

If "|" is like running a program with argument x:

taylor(sin(x))|x=0.5 ==> (lambda x: taylor(sin(x))) (0.5) ==> taylor(sin(0.5)) ==> sin(0.5)

sin(x)|x=2 ==> (lambda x: sin(x))(2) ==> sin(2)

Why does "|" hard to evaluate ?
Why previous run of x := 1 affect it ?

Maybe "|" is simply "evaluate at" ?
However, that imply taylor had a bug (post #23)

Consider the expression a*x^2. Suppose 'x' is left undefined and we execute:

a:=3;
a*x^2;

Most people would expect the second expression to return 3*x^2 and not a*x^2. Now suppose the parameter 'a' were removed and apply the same thought process to 'x' within an expression using the | operator. Do you see where this could be ambiguous? (pun optional)

[Albert Chan]

(08-24-2018 12:08 AM)Han Wrote:  Most people would expect the second expression to return 3*x^2 and not a*x^2.
Now suppose the parameter 'a' were removed and apply the same thought process to 'x' within an expression using the | operator.
Do you see where this could be ambiguous? (pun optional)

Thanks Han.

From the user side, yes ... this is ambiguous.
But, from CAS, there is no ambiguity, once order of evaluation is defined.

It is like 1 + 2 * 3, if multiply before add, it is 7; without the precedence, it is 9

Since parisse (post #21) said that x:=1, followed by sin(x) |x=2, will return sin(1),
this suggest CAS is doing the expression first, before substitution.

So, the trick is to think like CAS, and the ambiguity is gone.

Just an example, my Casio evaluate 1/ABC as 1/(ABC), instead of expected 1/A*B*C
So, ..., I just think like the calculator (especially important if it is RPN)

Edit:
my conclusion was wrong (as parisse later pointed out, the result is sin(2), not sin(1))
Going straight to hp50g reference manual, "|" is the "where" command

[parisse]

This is wrong: x:=1 followed by sin(x)|x=2 returns sin(2), and that's not easy to evaluate, you must have a "local" value of x (2) that takes precedence over the global value of x (1).

[Albert Chan]

(08-22-2018 07:52 PM)parisse Wrote:  It's hard to evaluate |. You don't want to get sin(1) for sin(x)|x=2 if x:=1; has been run,

(08-24-2018 06:21 AM)parisse Wrote:  This is wrong: x:=1 followed by sin(x)|x=2 returns sin(2), and that's not easy to evaluate

I am confused.

What situation will sin(x)|x=2 return sin(1) ?

Edit: Sorry for the noise. Above expression always return sin(2)

[ijabbott]

(08-24-2018 06:21 AM)parisse Wrote:  This is wrong: x:=1 followed by sin(x)|x=2 returns sin(2), and that's not easy to evaluate, you must have a "local" value of x (2) that takes precedence over the global value of x (1).

It would be nice if you could use the "where" operator "|" to temporarily undefine variables. For example: x:=1 followed by sin(x)|x=? (I'm not sure what the syntax ought to be here, but basically mark x as undefined) would return sin(x), ignoring the value assigned to x.

[parisse]

You can already run expression|x=x

[ijabbott]

(08-24-2018 06:58 PM)parisse Wrote:  You can already run expression|x=x

That's a handy trick to know, thanks, although the semantics of that notation seems a little dodgy!

[Aries]

(08-21-2018 04:47 PM)parisse Wrote:  But a Taylor expansion has two parts: the polynomial part and the remainder term. Unfortunately students tend to forget the remainder term, and that will not help if the calculator ignores it as well. That's why you have taylor(.) and taylor(.,polynom) on the HP. And if you don't remind the polynom trick, you can still run f:=taylor(sin(x),x=0,5) then f|x=0.5 and ignore the order_size term.
:-)

Good point, parisse, I've implemented Lagrange remainder and Peano remainder (little-o notation) on the Nspire for the students.
Thanks for reminding me
Best,

Aries

[Wes Loewer]

(08-22-2018 07:52 PM)parisse Wrote:  | is evaluated more like a program, where x would be like an argument. taylor(sin(x))|x=0.5 will evaluate sin(x) to sin(0.5) before taylor is called.
It's hard to evaluate |.

I see the difficulty in determining whether the |x=0.5 should be evaluated before or after.

Since taylor(sin(x))|x=0.5 is evaluated before, but ∂(sin(x),x)|x = 0.5 is evaluated after, I assume there is some way in the source code to indicate which functions are "before" and which are "after." Or is ∂() a special case?

[parisse]

Indeed. There are special evaluation rules for derivative and a few other functions but it's a nightmare to support non standard evaluation rules. That's why taylor or commands that are used by more advanced students follow standard rules.

[Albert Chan]

(08-27-2018 02:33 PM)Wes Loewer Wrote:  I see the difficulty in determining whether the |x=0.5 should be evaluated before or after.

Since taylor(sin(x))|x=0.5 is evaluated before, but ∂(sin(x),x)|x = 0.5 is evaluated after, I assume there is some way in the source code to indicate which functions are "before" and which are "after." Or is ∂() a special case?

It seems evaluation order is context based.
This is my guess ...

Differentiation had the dx, notifying the ∂(...) what to differentiate against.
Variable x thus off limit for where substitution, until expression differentiated.
In other words, where substitution is delayed. (same for integration)

Regular expressions, there is no need to delay where replacement.
We can think of where as running code with argument x, like parisse described earlier:

f(x)|x=a => (lambda x: f(x))(x=a) => f(a)

taylor(sin(x))|x=0.5, however, is inconsistent with above logic.
It should be treated like ∂(...), since it had an off limit x, to "taylor" against.

Perhaps implied x does not count ?
What is the result of taylor(sin(x), x=0, 5)|x=0.5 ?