▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Hi,
I've made a small 'twin-brother' of the WP34s TVM-solver which you can use directly on your (Windows) PC:
http://www.hpmuseum.org/guest/fhub/tvm_pc.zip
It is written in JavaScript within a HTML file and then compiled to CHM, so it is just used like any other CHM-helpfile.
It works almost exactly like the WP34s version (also finding 2 solutions!), so you can look at the WP34s file for a description of all parameters/variables.
The only 2 differences are for 'perpetual payments' and 'continuous compounding': in this PC-version you have to enter "inf" (for infinite) for the variables 'N' and 'NI' instead of the 'fake' value 0 on the WP34s.
Everything else should work like the WP34s version - of course much faster. ;-)
Maybe someone has use for this tiny TVM program ...
(BTW, there are 2 versions included, English and German)
Franz
Edited: 25 Dec 2012, 4:41 p.m.
▼
Posts: 464
Threads: 10
Joined: Jan 2005
Hello Franz,
Thank you very much for both your WP-34s TVM solver and the PC port.
I both use them frequently and really appreciate your work and dedication.
Your TVM is one of the many reasons I use and upgrade my 34s's.
Frohe Weinachten aus Frankreich.
Etienne
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Frohe Weinachten aus Frankreich.
Thanks Etienne, I wish you happy holidays too! :-)
Franz
Posts: 1,216
Threads: 75
Joined: Jun 2011
I've found a small error in one of my formulas (derivative of TVM for i=0), so I've updated all my TVM-files:
http://www.hpmuseum.org/guest/fhub/tvm_pc.zip
http://www.hpmuseum.org/guest/fhub/tvm.zip
Although this situation (i.e. i=0 when iterating for i) will almost never happen, it's a bug and a bug has to be fixed! ;-)
Franz
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
What is the difference between TVM.wp34s and TVM_emu.wp34s?
Which should go into the standard library? We haven't any current capability for putting different libraries into different versions and I'd kind of prefer to keep it this way.
- Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
What is the difference between TVM.wp34s and TVM_emu.wp34s?
TVM.wp34s displays 'Solving...' while the SLVer is iterating for the interest rate 'I'. Since this can take upto about 9 seconds on a real WP34s, Dieter suggested to show such a message.
TVM_emu.wp34s is intended for use on the emulator, it does NOT display this message because the emulator is so fast that this is not needed.
For the library the first one (TVM.wp34s as usual) is probably better, because the library is primarily made for a real calc, and even on the emulator this 'Solving...' message won't hurt - it goes away so fast that you can't really see it.
So this TVM_emu.wp34s is only necessary if anyone wants to save a few (6) steps on his emulator. ;-)
Franz
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Thanks for the explanation. I've included the one with the solving message. Haven't built a new image yet.
- Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
Haven't built a new image yet.
I'm now quite confused about the OLD vs. NEW Sourceforge repository for the WP34s project:
OLD version: http://wp34s.svn.sourceforge.net/viewvc/wp34s/
NEW version: http://sourceforge.net/p/wp34s/code/
All of Walter's last manual updates (more than 10!) have gone to the OLD version, which shows SVN 3349 st the moment.
Now I see that you've put my new TVM-file into the NEW version, which is at r3337 currently. And this NEW version contains even newer builds of wp34s.exe, wp34sgui.exe and all calc*.bin, but the manual is still the very old one of v2.2.
So what's now (and in the future) the up-to-date WP34s project page???
Can we now definitely forget the OLD and switch to the NEW version?
But then you should definitely update the manual in this NEW project page!
Franz
Edited: 26 Dec 2012, 7:46 a.m.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
Never change a winning team ;-)
Some weeks ago, SF told us they want to switch for reasons they know. Now, if I were SF, I'd shut down the whole system (or parts of it) for an appropiate time interval, migrate what I'd think has to be migrated and boot it again with the new UI set up, so after that date each and every commit (regarding that part) would go to the new environment. That shall be backed up by proper documentation of new user requirements if there are any. Unfortunately that's not the way SF seems to handle that switching.
Personally, I do my commits as I did all the time before. I don't care where SF puts them as long as there's a traceable history. The administration of that database is SF's job - it's not mine nor is it mine telling them. If - as you mentioned - there are two traces now, then it may be about time to congratulate those administrators for the brilliant job they've done and to wish them good luck for sorting it out and getting everything on track again.
Just my 20m€ as usual, of course.
d:-/
Edited: 26 Dec 2012, 8:36 a.m.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Walter, the new repository has a different interface so you simply can't commit to the new repository without checking it out once. I've migrated all my working copies to the new format and have abandoned the old format altogether. It would be helpful for a consistent state if you did the same. Pauli can then remove the old repository from SF.
Posts: 3,229
Threads: 42
Joined: Jul 2006
The NEW repository is the place to be.
As I mentioned earlier, this change was being forced upon us.
I might have jumped in a little earlier than strictly necessary, but the change had to occur.
At some point, Marcus or I will delete the old repository completely. Unless sourceforge beats us to it.
And yes, the manuals will need a (final) update.
- Pauli
Posts: 653
Threads: 26
Joined: Aug 2010
Quote:
Since this can take upto about 9 seconds on a real WP34s, (...)
That's not what I wrote. It was one particular example that required nine seconds for the solution. But that's not an upper limit. Other cases may require 12 or 15 seconds. That's why I think a message like "Solving..." should be added.
BTW, the current experimental Newton solver requires just a second for each of the two solutions. ;-)
Dieter
Edited: 26 Dec 2012, 9:47 a.m.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
That's not what I wrote. It was one particular example that required nine seconds for the solution. But that's not an upper limit. Other cases may require 12 or 15 seconds.
Well, then you should blame the implemented SLV routine for taking so long. If such a SLV is available in a calculator, then of course it's logical to use it (instead of writing own routines for each program that needs root-solving).
Quote:
That's why I think a message like "Solving..." should be added.
This message _is_ already implemented in the current version. :-)
Quote:
BTW, the current experimental Newton solver requires just a second for each of the two solutions. ;-)
Nice - but there's one big difference between your and my solver: mine is available! ;-)
Franz
Edited: 26 Dec 2012, 10:04 a.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: Well, then you should blame the implemented SLV routine for taking so long. If such a SLV is available in a calculator, then of course it's logical to use it (instead of writing own routines for each program that needs root-solving).
I wouldn't blame the internal solver, although I'm biased a bit here :-) Writing a completely general purpose function solver is provably impossible. The internal SLV routine tries & for the most part seems to do an okay job but it has its short comings as many of us are aware.
For specific tasks, there are often better solvers available -- the statistical routines e.g. avoid the internal solver completely and use Newton's and Halley's methods instead. This costs a bit of space but the results are improved.
Ideally, I'd like to provide a number of different function solvers and allow the user to specify which one they'd like to use based on the problem being attacked. In reality, this won't happen on the 34S and even if it did, it would likely cause more confusion than benefit.
- Pauli
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
I wouldn't blame the internal solver, although I'm biased a bit here :-)
Well, of course I didn't mean this seriously - in fact I'm quite satisfied with the internal SLV. One problem is that the TVM expression is rather complicated and over a wider range not very similar to a quadratic function (IIRC the SLV routine uses such a quadratic interpolation?). And the main problem is of course that the real WP34s is damned slow, at least compared to modern PCs.
For my PC-version of TVM (in JavaScript) I've even used the simple interval-bisection method (which is known to be not one of the fastest algorithms), but on a PC that's no problem at all: although I even bisect until 10^-9 on an interval ]-1,10], the solutions are provided 'immediately'.
It may indeed be that Dieter's Newton method is much faster than using SLV, but I definitely don't like to use this old TVM expression (that was used in the first TVM versions) for some reasons: it's not logical for me to divide the original/standard TVM expression by a term [(1+i)^n-1] and then still by k/i, and second the derivative TVM' becomes extremely complicated (many steps to program and also to calculate). Thus I've switched back to the standard form of the TVM expression (although maybe for this form it's not so easy to get lower and upper limits for the solutions).
Franz
|