In addition to the Pretty Print routine for algebraic expressions, the script includes a fraction display function, and math.eval routines that find roots for polynomials and evaluate numeric forms.
For example, suppose we also wanted to view the graph of our function fn? Then by storing it across in nspire, we could define f1(x) = expr(fn) and you will get the graph of whatever fn happens to be!Īll of these various routines and ideas have been used to create the attached document, pretty.tns. I prefer the more elegant approach, avoiding sending variables across the divide if possible unless we really need them over there for something else. Result = math.eval( "string(Factor(expr(fn),x))") Sorry, but this does make sense when you stick with it for a while. So we would need to "unstring" it so that factor can work with it, then turn it back into a string to send it back. ",x))")įinally, if we sent our function across to Nspire, it goes across as a string. So we make sure that what is sent back to Lua is a string: Similarly if we were using CAS and we wanted to factor an expression - the result would be an algebraic expression and Lua cannot handle that. Result = math.eval( "string(polyroots(".fn. We need to turn it into a string so that Lua can receive it. For our purposes here, suppose fn = "x^2-5". So suppose we wish to grab the result of a PolyRoots function applied to some function that we have defined: call it fn. AND it works for CAS - with an important proviso: Lua can only deal with variable types that it recognises: numbers and strings, but NOT lists, expressions or matrices. Originally, I thought that this was limited to native TI-Nspire functions, but actually it works for user-defined functions as well. We can get TI-Nspire to compute any legitimate command that it understands. Now stop and think about this and maybe see how potentially powerful this feature is. Since this does not involve sending any variables across the Lua/Nspire barrier. So the argument of the math.eval function (in quotes) is what gets sent to Nspire, which understands that command and sends the answer back to Lua. Study this carefully to see what is happening here. (No real problem with using the same name for the variables in both nspire and Lua since they will never actually, you know. The simplest option would probably be to store num and den across to Nspire: NOTE that I am trying to show the Nspire stuff in red to try and expose what is going on here. If so we would like to divide these out and present the simplest form for the fraction num."/".den. Suppose we have two numbers, call them num and den and we wish to know if they have any common factors. So while routines for things like finding the greatest common denominator (gcd) of two numbers are available out there on the Internet, should we not be able to reach across and use the GCD function that lives within TI-Nspire? This is where math.eval comes in. We are working within a really powerful and full-featured mathematical environment - TI-Nspire.
#POLYROOTS TI NSPIRE CX HOW TO#
I have been having a lot of fun (and more than a little bit of frustration at times!) learning how to use this wonderful, powerful command.Īfter all, we are not like the rest of the Lua scripters out there, working on a blank canvass in a vacuum. Texas Instruments TI-Nspire Scripting Support Page math.eval Scripting Tutorial - Lesson 17: Tips and Tricks Iĭownload supporting files for this tutorial Home ← TI-Nspire Authoring ← TI-Nspire Scripting HQ ← Scripting Tutorial - Lesson 17