I want to use finance variables in my program, because they are much faster than normal variables. However, my program isn't working now. I don't know if I just made a mistake while typing, or if there's something I'm doing wrong.
What is wrong with your program? What error are are you getting, if any? What finance variable are you using? How are you using it?
As per the System Variables page, there is a limitation. The finance variables cannot be used as the variable in the For( loop.
Electromagnet8 is correct; finance variables can be used for neither For loop indices nor seq( indices nor IS>( commands. As an alternative, try the sequence variable n found under [CATALOG] [N], which is about the same speed as finance variables but without the restrictions.
:P/Y-(N=24 and not(pxl-Test(C/Y,P/Y-1)))+(N=26 and not(pxl-Test(C/Y,P/Y+1)))→P/Y
:C/Y-(N=25 and not(pxl-Test(C/Y-1,P/Y)))+2(N=33 and not(pxl-Test(C/Y+2,P/Y)))-2(N=23 and not(pxl-Test(C/Y-2,P/Y)))→C/Y
N, C/Y, P/Y, FV, and PV are all finance variables
N is getkey
P/Y is the X coordinate
C/Y is Y
PV and FV are old X and Y values for erasing the pixel at the previous position
The pixel displayed on the screen SHOULD fall straight down when no buttons are pressed, but instead it just moves up and down really fast.
When pressing left, the pixel should move left, but it moves up and left. When you press right, it moves down and right.
I tried removing all lines that alter the Y coordinate (C/Y), but the right/left glitch still happens, so somehow, something is changing C/Y.
Anyway, the program IS running a LOT faster, so hopefully I just made some stupid mistake…
If what you say is true that you removed all of the code that changed C/Y (coupons per year) and the code works without the use of finance variables, then there is something that is changing C/Y in the background. The finance variables are used in a TVM Solver. It might be possible that the solver is updating the C/Y.
I would think that it would slow down the program a lot if the TVM solver was running, so I don't think that's what it is. But I do agree that SOMETHING outside the program is updating it, because I tried replacing it with another variable (C), and it worked fine. I'll try using a different finance variable.
Anyway, finance variables are really under-appreciated. I don't know why so few people use them, though I expect it's because they're in a weird menu (inside APPS), and because they seem complicated.
Oh, I forgot about this: Whenever you set the value of P/Y, the calculator changes C/Y to the same value, making C/Y unsuitable for most applications of finance variables. I ran into this problem myself when trying to code SQUFOF factoring with finance variables.
Just use I% or n instead.
There should be something on the wiki about using finance variables, and the differences between each one.
Ok, I started a page in the optimization category, if anyone has any more information, feel free to add it.
I tested the difference. User variables are obviously slower :/
The table I made is a bit confusing, so if you can figure out a better way of doing it then that would be appreciated.
I did some testing too, and here are my results:
(test format: _→X, so it would work with Ans)
0.0051 seconds (this might be useful for programs that don't use point commands)
0.0083 seconds (much faster than list…)
0.0142 seconds (soooo slow!)
But of course, none of this matters because only normal variables can be used with DS<( and IS>(, so all other types are useless.
I made an amazing discovery!!! After doing 200000 tests, I have found that Ans is in fact NOT faster than real variables!!
With 100000 iterations, timed with checkTmr(, when A=Ans=858993459, and with n as the index of the loop, using an 84+ 2.55MP, :A took 2.57 ms, while :Ans took 2.51 ms. Not a large difference, but it's something.
Tested a second time after archiving my programs, clearing RAM only, and then unarchiving a few that total to around 400 bytes. The flash shouldn't make a difference. 2.39 ms for Ans versus 2.42 for A, so it looks like the difference increases with the amount of RAM used, reaching zero with zero RAM use.
For some reason the archive does make a difference in speed. I have two identical calculators, one of which has many programs in the archive. The same prime sieving program takes 71 seconds on the calculator with many archived programs, and 46 seconds on the calculator with few things in the archive. Both are TI-84+SE running 2.55MP, and are switched to CLASSIC mode.
Tested a third time, this time with all but 1441 bytes of RAM taken by 99x25 matrix [A]. Ans takes 2.40 ms, whereas A takes… 2.42 ms? This should be studied further, because it looks like both the amount of time taken, and the difference between Ans and A, decrease when RAM is cleared, but do not depend directly on free RAM.
I think the speed is based on location in the memory. Ans is always the first (or second?) variable used (after clearing memory), so maybe that's why it's faster, since the calculator only has to search through a small amount of memory before it finds it.
However, I don't really know much about this stuff…