Use program parameters for graph drawing - TI92+ - variables

I have a problem with a program on my TI92+.
It does work without a problem on a TI92, though.
I want to draw a graph, that I enter as a program argument, e.g. test(x^2)
Program goes like this:
test(var1)
Prgm
var1->k
k->y1(x)
ZoomStd
setMode("split 1 app","graph"):Pause
EndPrgm
On the TI92 it shows me a simple x^2 function, on the TI92+ I get "Undefined Variable" as an error message. Interestingly enough, when I enter "k" on the home screen, I get x^2 as an output. So the variable is there.
I am in the main folder and this happens with a reset calculator as well.
I understand that TI changed something about the variables between TI92 and TI92+, you can have local variables, but this is no local variable.
And finally: this is just a test program I am using to demonstrate my problem, of course I know I could just type x^2 into the y= editor and hey presto. But a program I have written years ago doesn't work and I would like to know, why and where I have to change something.

If you look at the Y= Editor, does it display y1=k? On my TI-89 Titanium (which I understand uses similar software), k→y1(x) literally stores k to y1. This is a problem since it tries to substitute all instances of x in y1 (of which there are none) with the value passed to y1. Then, since k is an expression type, not a number, the calculator refuses to graph it. I'm still trying to find a work around for this.

Related

X and Y inputs in LabVIEW

I am new to LabVIEW and I am trying to read a code written in LabVIEW. The block diagram is this:
This is the program to input x and y functions into the voltage input. It is meant to give an input voltage in different forms (sine, heartshape , etc.) into the fast-steering mirror or galvano mirror x and y axises.
x and y function controls are for inputting a formula for a function, and then we use "evaluation single value" function to input into a daq assistant.
I understand that { 2*(|-Mpi|)/N }*i + -Mpi*pi goes into the x value. However, I dont understand why we use this kind of formula. Why we need to assign a negative value and then do the absolute value of -M*pi. Also, I don`t understand why we need to divide to N and then multiply by i. And finally, why need to add -Mpi again? If you provide any hints about this I would really appreciate it.
This is just a complicated way to write the code/formula. Given what the code looks like (unnecessary wire bends, duplicate loop-input-tunnels, hidden wires, unnecessary coercion dots, failure to use appropriate built-in 'negate' function) not much care has been given in writing it. So while it probably yields the correct results you should not expect it to do so in the most readable way.
To answer you specific questions:
Why we need to assign a negative value and then do the absolute value
We don't. We can just move the negation immediately before the last addition or change that to a subtraction:
{ 2*(|Mpi|)/N }*i - Mpi*pi
And as #yair pointed out: We are not assigning a value here, we are basically flipping the sign of whatever value the user entered.
Why we need to divide to N and then multiply by i
This gives you a fraction between 0 and 1, no matter how many steps you do in your for-loop. Think of N as a sampling rate. I.e. your mirrors will always do the same movement, but a larger N just produces more steps in between.
Why need to add -Mpi again
I would strongly assume this is some kind of quick-and-dirty workaround for a bug that has not been fixed properly. Looking at the code it seems this +Mpi*pi has been added later on in the development process. And while I don't know what the expected values are I would believe that multiplying only one of the summands by Pi is probably wrong.

Function iMA is returning different return value from expected (MQL5)

I'm using MQL5 (my first code).
I want to use a script that uses MA, but first, I wanted to confirm the value to verify I'm doing correctly. Using a very basic code into script:
double x=0;
x = iMA(Symbol(),Period(),100,0,MODE_SMA,PRICE_CLOSE);
Alert("The actual MA from last 100 points of EURUSD actually is: " + x;
The expected value is near the actual price... 1.23456, but this function is returning 10.00000 or 11.0000.
I believe I'm missing something, and https://www.mql5.com/es/docs/indicators/ima helplink is not quite clear enough.
I already saw another similar function: MA[0] which seems to bring the moving average from specific candle, but, I don't know how to manage the Period range (100) or if is related to Close/Open variables on it. I didn't find any specific helplink to review.
Any ideas are very appreciated!!!
x should be int, it is a handler of the MA. So each indicator when created in MT5 receives its handler, and you can use it later to get what you need. If you need several MA's - create several handlers and give each of them different names (x1, x2 or add some sense). Expert advisors in the default build of MT5 are good examples on what to do.
The iMA function Returns the handle of a specified technical indicator, not the "moving average" value.
For example, to get the value of the Moving average you can use this (in MQ4):
EMA34Handler = iMA(NULL,0,34,0,MODE_EMA,PRICE_CLOSE);
EMA34Value = CopyBuffer(EMA34Handler, 0,0);

Weird behavior of the input command in Scilab

I want my students to program a little game with Scilab like this one :
a=ceil(100*rand())
disp("I think of a number between 1 and 100. Which one ?")
guess=0
while(guess<>a) do
guess= input("Guess :")
if (a>guess) then
disp("+")
elseif (a<guess) then
disp("-")
end
end
disp("You got it")
But there are some weird behavior with the first inputs and the lasts. Just after the first input, sometimes I don't have an answer (but sometimes I do), I am asked "Guess" again, but this time with a usual prompt --> on the console. I can put anything, it doesn't seem to matter for the program. But the program is not over though, just after it returns to the expected behavior.
At the end, after the "You got it", there seems to be some inputs around. I got one or two prompts before I got the --> again.
Here is what the console may look like :
Guess :
50
Guess :
--> 50
Guess :
50
+
Guess :
75
-
Guess :
I can't figure out why Scilab react like this.
I've experienced that a lot, and this is a known bug in input() of Scilab 6.0.0:
http://bugzilla.scilab.org/show_bug.cgi?id=15069
http://bugzilla.scilab.org/show_bug.cgi?id=14376
http://bugzilla.scilab.org/show_bug.cgi?id=14424
The first link also presents a workaround, but I wouldn't say it is suitable for students. As #Desire couldn't reproduce that error, I recommend that you downgrade you Scilab to version 5.5.1, and also tell your students to do it too.

How to store several variable names in Stata?

I want to store a list of variable names in a new local variable, such that I do not have to type a long list of variable names for each regression. I am using Stata 14.
E.g., I have the following 5 independent variables: a b c d e and one dependent variable: f
I don't want:
regress f a b c d e
But I want something like:
regress f allvar
How can I generate allvar?
Unfortunately, this does not work
local allvar a b c d e
The following works fine.
clear
set more off
sysuse auto
// first regressions
regress price mpg rep78 weight
// second regression
local allvars mpg rep78 weight
regress price `allvars'
Unless you show us something reproducible and/or more explicit, it's difficult to see what the problem is. A report only mentioning "does not work" is usually useless.
See also the keyword _all in help varlist.
You are using a local macro. If you are running the code by parts, then don't. You need to run the whole code, all at once. Read [P] macro, for details. An excerpt:
Local macros exist solely within the program or do-file in which they
are defined. If that program or do-file calls another program or
do-file, the local macros previously defined temporarily cease to
exist, and their existence is reestablished when the calling program
regains control. When a program or do-file ends, its local macros are
permanently deleted.
A common reason why your command sometimes "does not work" is that you ran your do-file line by line, rather than all in one go. A local macro is local to a session (hence the name). So if you ran the line local allvar a b c d e, then that will create that local macro and let it disapear as soon as Stata finished running that section of your .do file. There are two solutions:
You can get into the habit of running the definition of local macros and their use in one go. It is actually good practice to make many small .do files and make each .do file self-contained (see for example this excellent book), so you can easily just run the entire .do file each time you want to check or change something.
Alternatively, you can use global macros. These continue to exist after a session. As someone that programs in Stata, using global macros hurts my eyes, but I guess that if you use Stata only to analyse data it does little harm.
As an asside, allvar does not seem like a right name for that local macro: it does not contain all variables as it excludes the variable f. This sounds pedantic (and it is), but it is good practice to use names that accurately describe its content. In a real project we tend to come back to it after some time. A common scenarion is that you submitted a paper to a journal, it took half a year or more for the reviews to come in, and now you need to "read" your own .do-file to understand what you did half a year ago. At that point you are very happy that you were pedantic when writing the .do file...
As a further asside, assuming that a b c d e f are indeed all the variables in your dataset you can also create your local using:
ds f, not
local rhs `r(varlist)' // rhs short for right-hand side

Creating robust real-time monitors for variables

We can create a real-time monitor for a variable like this:
CreatePalette#Panel#Row[{"x = ", Dynamic[x]}]
(This is more interesting and useful if x happens to be something like $Assumptions. It's so easy to set a value and then forget about it.)
Unfortunately this stops working if the kernel is re-launched (Quit[], then evaluate something). The palette won't show changes in the value of x any more.
Is there a way to do this so it keeps working even across kernel sessions? I find myself restarting the kernel quite often. (If the resulting palette causes the kernel to be automatically started after Quit that's fine.)
Update: As mentioned in the comments, it turns out that the palette ceases working only if we quit by evaluating Quit[]. When using Evaluation -> Quit Kernel -> Local, it will keep working.
Link to same question on MathGroup.
I can only guess, because on my Ubuntu here the situations seems buggy. The trick with the Quit from the menu like Leonid suggested did not work here. Another one is: on a fresh Mathematica session with only one notebook open:
Dynamic[x]
x = 1
Dynamic[x]
x = 2
gives as expected
2
1
2
2
Typing in the next line Quit, evaluating and typing then x=3 updates only the first of the Dynamic[x].
Nevertheless, have you checked the command
Internal`GetTrackedSymbols[]
This gives not only the tracked symbols but additionally some kind of ID where the dynamic content belongs. If you can find out, what exactly these numbers are and investigate in the other functions you find in the Internal context, you may be able to add your palette Dynamic-content manually after restarting the kernel.
I thought I had something like that with
Internal`SetValueTrackExtra
but I'm currently not able to reproduce the behavior.
#halirutan's answer jarred my memory...
Have you ever come across: Experimental/ref/ValueFunction? (documentation address)
Although the documentation contains no examples, the 'more information' section provides the following tidbit:
The assignment ValueFunction[symb] = f specifies that whenever
symb gets a new value val, the expression f[symb,val] should be
evaluated.