34s: TVM problem?



#48

I can get the TVM example in the manual to work to solve for a payment, but I can't get it to work solving for the interest rate.

I don't see any disclaimer about the interest rate being a special case... ?

Here's what I did:

-800 STO 80

90000 STO 81

0 STO 82

0 STO 83

360 STO 84

Then set up a program for:

LBL IYR

SLV 01

NOP

RTN

LBL 01

STO 83

XEQ TVM

RTN

and I get positive infinity as the result seemingly regardless of the initial guess.

The answer should be about 0.85 (or 0.0085 since it does not use the x100 view).

Help?

Gene


#49

What happens if you XEQ 01 with your estimated solution in X?


#50

I single-stepped to LBL 01.

Keyed in 0.008 and pressed R/S. I saw -36.6560 in the display.


#51

If your assumption is correct, the result should be near zero. Maybe you didn't get the signs of the parameters right?


#52

The result actually is close to zero - for i = 0,008 it's just 36,66 "money units", which is close to nothing compared to the other values. The correct interest rate (0,00846072 to six significant places) returns a value less than 0,0003.

Gene's problem most probably is the TVM routine not handling zero interest rates combined with the requirement of two non-zero initial guesses. See my other post below.

Dieter

#53

The 12c give 0.85 as the answer to this problem so there is an issue with the TVM routine in XROM. I couldn't be bothered fixing a financial function though :-)


The TVM code is exactly:

	LBL'TVM'
RCL 80
RCL 81
RCL+ 82
1
RCL+ 83
RCL 84
y[^x]
DEC X
/
RCL+ 81
RCL[times] 83
FC? 80
SKIP 03
RCL 83
INC X
/
+
RTN

Anyone care to try fixing the equation?


The solver also makes mistakes from time to time...but that doesn't seem to be the issue here.


- Pauli


#54

Perhaps I'm mistaken, but the formula shown in the manual is "PMT-"..., not "PMT+"... so I'd expect the second from last step to be a "-", not a "+". Yes?


#55

I think the + is correct.

If you set the initial bounds to .8 and .9 the solver finds the root in about ten iterations: 0.008460723396753903.

Some other bounds I tried failed. So this is more like the solver going awry.


- Pauli


#56

Hi Pauli,

I think that Jim is correct. I compared the program with the formula in the manual and based on that the last instruction before RTN should be "-", if I am not mistaken.

Salut,

Miguel


#57

The solver gets the correct answer with a plus and not with a minus but I'll verify the formula this evening.

- Pauli

#58

I checked this and I am fairly confident the function is correct.

I don't know where Walter got the equation in the manual from but the one being solved is:

PMT + I/k (PV + (PV + FV) / ( (1 + I)^n - 1 ) = 0

This is a rearangement of the PMT = equation in the manual.

I don't see where people are coming from saying the first + should be a -.


- Pauli


#59

Hi,

Yes, you are right. The equation in the manual should then read "PMT +" and so on and not as it is now.

Thanks,

Miguel

TVM


Edited: 29 July 2011, 1:28 a.m.


#60

IMHO the top equation on page 76 of the manual is just a rearrangement of the equation for PMT in the next row.

Walter


#61

Editions of the manual from at least 1.4 up to Edition 2.0 released with build 1107, p72 has the formula incorrect.
Later Edition 2.0 (again) of the manual released with build 1173, p73 has the formula corrected.

Suggestions:
Walter:
Better version numbering (many changes were made to the manual released as version 2.0) - perhaps add an alphabetical letter to it?
Forumers:
Use the lateast version of the manual (latest I can find is version 2.1 released with build 1344)

Note: these are observations and suggestions, I am not telling anyone what to do. Please take it in the spirit of trying to help.


#62

Thank you Bart for pointing to the lastest version of the manual.

By the way, I would like to thank Pauli, Walter and Marcus fos this amazing development of a calculator. This is an awesome work what you are doing here, guys!

Regards,

Miguel

#63

Bart,

Quote:
Editions of the manual from at least 1.4 up to Edition 2.0 released with build 1107, p72 has the formula incorrect.
Later Edition 2.0 (again) of the manual released with build 1173, p73 has the formula corrected.

Suggestions:
Walter:
Better version numbering (many changes were made to the manual released as version 2.0) - perhaps add an alphabetical letter to it?
Forumers:
Use the lateast version of the manual (latest I can find is version 2.1 released with build 1344)

Thanks for your report and suggestions. No need for excuses - we've proven we can take whatever comes, but you have to take our response as well ;-) That said, let's start:
  • Edition 1.4 didn't contain TVM at all.
  • Please note you are closely watching a development project. Almost everything we do is reflected in SourceForge. I don't know any other calculator development being so open to the community. OTOH you may see a lot of errors, features coming and going again. If you don't want to cope with that, please wait for the official release.
  • With respect to edition counting: You may have noticed we update our files frequently. If each and every little change or correction would get a new number, the editions would run up to hilarious values IMHO. So we refrain from doing this.
  • But help is near: SourceForge does the counting for us :-) And you find a screen shot of a recent build on the title page of each manual - this may give you some idea what's covered.
  • Real bugs are still found - thanks to the community for reporting them.
  • IF you want to see the latest committed edition of the manual, look here: http://wp34s.svn.sourceforge.net/viewvc/wp34s/doc/ and choose the file "Manual_wp_34s_...". Again, this may be full of errors still - TIA to everybody reading it and reporting to me whatever (s)he thinks is wrong / misleading / arcane / annoying / whatever ... There will happen nothing worse than you get an answer thanking you (see above) etc. ;-)
Disclaimer: This is written to advance understanding, no offence intended.

HTH,

Walter


#64

    Quote:
  • Edition 1.4 didn't contain TVM at all.
You are right, it was another version 2.0 I was looking at, released with a build in June (I don't think there was ever a 1.4 released?)

    Quote:
  • Please note you are closely watching a development project.
Yes, my last sentence intended to convey that these are observations, not criticisms. As I commented in this thread I hold you all in high regard and am very thankful for the effort and time spent on this project.

    Quote:
  • With respect to edition counting: You may have noticed we update our files frequently. If each and every little change or correction would get a new number, the editions would run up to hilarious values IMHO. So we refrain from doing this.
The TVM section changed from one formula to four formulas, which I personally think is quite a major change.
However:
    Quote:
  • But help is near: SourceForge does the counting for us :-) ...
Indeed, we can always reference a manual together with the sourceforge no. i.e. "edition 2.1 - 1327" ;-)

Thank you again for all the effort,
Bart

#65

Quote:
I don't think there was ever a 1.4 released?
None that you could see :-)
Quote:
As I commented in this thread I hold you all in high regard and am very thankful for the effort and time spent on this project.
Thank you for your kind words in other posts as well. Generally, however, my response goes just to the post I'm answering. I apologize for not taking into account all of your publications ;-)
Quote:
The TVM section changed from one formula to four formulas, which I personally think is quite a major change.
Three more formulas in a 80 page paper, well ... YMMV :-)

Walter


#66

For Walter:

Looking in the manual for S.L and S.R I found a small bug:

The statements about multiplication or division with a factor 10^n are correct, but not the decimal point/comma is shifted left or right (for S.L or S.R) but the number itself, i.e. its digits are shifted as the function name suggests - the radix is in fact shifted exactly in the opposite direction as the function name says.

Franz


Edited: 30 July 2011, 10:10 a.m.


#67

Franz, you're right. Maybe we shall swap the command names.

Walter


#68

Quote:
Franz, you're right. Maybe we shall swap the command names.

But then it won't correspond anymore with the shifting functions of binary integers. I would just say you should simply explain it in the manual as "shifting the numbers/digits left or right" instead of the radix, which is also the usual understanding for binaries.

Franz


#69

Well, the commands were called S.L / S.R on purpose ;-) But we may as well call them SDL / SDR :-)

Walter


#70

Quote:
But we may as well call them SDL / SDR :-)

Indeed not a bad idea! This dot in the mid seemed always a bit 'suspicious' to me. :-)

#71

SDL and SDR would nicely translate to Shift Decimal (or Digit) Left / Right.

In the various binary modes the commands could even be context sensitive shifting the digits depending on the base.

Edited: 30 July 2011, 6:24 p.m.


#72

Quote:
SDL and SDR would nicely translate to Shift Decimal (or Digit) Left / Right.

Yes, that was exactly my idea too.
Quote:
In the various binary modes the commands could even be context sensitive shifting the digits depending on the base.

Oh, I think this would give a problem when you use this command in a program - running it in different base modes would then give different results. :-(
#73

We're those two my initial suggestions? Or at least quite like to them? Just checked -- I used SLD and SRD :-)

I'd prefer not making these commands available in integer mode if I can help it. They are provided to make breaking a real number into and out of digit fields quick and easy -- they operate by incrementing or decrementing the real's exponent field directly. Combine them with IP and FP and a lot of steps are saved in addition to executing faster.

In integer mode, they'll correspond to multiplication or division by a power of the base (which can be any value 2 through 16). There is no way to simplify the operation into shifts and adds and all the overflow and underflow conditions will have to be detected and handled. More effort than it is worth for a specialised function.

- Pauli

Edited: 30 July 2011, 7:39 p.m.


#74

FYI, SDL and SDR are now in and documented.

Walter

#75

Quote:
    Quote:
  • But help is near: SourceForge does the counting for us :-) ...
Indeed, we can always reference a manual together with the sourceforge no. i.e. "edition 2.1 - 1327" ;-)

I forgot: We also have a date in the very last row of the release notes - on the last page of the manual. So belt and braces ... :-)

Walter

#76

I haven't checked the formula, but there is one thing I would strongly recommend: Please avoid coding the TVM-formula literally, i.e. do not write it as (1+i)^n - 1. We should be glad to have ln1+x and e^x-1 on the 34s, so please, please use it and write this term as e^x-1(n*ln1+x(i)):

     ...
RCL 83
LN1+x
RCLx 84
e^x-1
...
It's shorter and, most important, provides exact results even for low interest rates. If you're not convinced, please see the example in the 15C Advanced Functions Handbook p. 173 and 180ff.

I also do not know what initial guesses for the interest rate are used for the 34s solver routine. The standard pac of the 34C with its included TVM program might be a useful source here.

Dieter


#77

Dieter, thanks for that. I can't believe I missed this improvement :-(

The 34S doesn't provide any initial guesses, the user gets to do that.


- Pauli

#78

Gene, you will get an +/- infinity error because the TVM routine cannot handle zero interest rates - in this case it tries to divide by zero. You can see this if you enter values very close to zero (0.0001, 1E-10, 1E-15...) followed by XEQ 01 and the results will approach -550, while i = 0 returns the mentioned error. This would not happen if the TVM equation was programmed so that it can handle this case as well.

                 (1+i)^n - 1
i -> 0 => ----------- -> n
i

Instead, the TVM routine tries do divide by (1+0)^n - 1 = 0 and therefore throws an error. Due to the limited precision of the current implementation this is the case for i < 1E-15 (results first lose precision and finally the error message appears).

The Solver does not provide any intial guess for the interest rate, so it's up to you to set two estimates in X and Y. If X or Y are zero the mentioned error will abort the calculation. If there are two good guesses before invoking SLV 01 (say: 0,001 ENTER 1), the 34s will return the correct result. I tried this on the emulator (an old version, 2.0 1054) and it returned the correct result 0,00846072 or 0,846%.

So, the problem occured because of two ...special features of the TVM routine: First, it does not provide any intial guess - it's up to you to set guess1 ENTER guess 2. And second, the TVM equation is unable to handle i = 0. It should be rewritten to do so.

So your approach was fine - and you will get the correct result if (and only if) you provide two non-zero guesses for the interest reate.

Dieter

Edited: 29 July 2011, 9:56 a.m.


#79

Hi Dieter,

it seems I'm not the only 'financial interested guy' here. ;-)

Here's my TVM routine which handles also i=0 correctly, and I've also rearranged the equation a bit to make the code shorter (except the new i=0 handling of course):

LBL 'TVM'
RCL 83
x!=0?
SKIP 03
RCL+ 84
RCL* 80
SKIP 10
1/x
FS? 80
INC X
RCL* 80
RCL+ 81
RCL 83
ln1+x
RCL* 84
e^x-1
*
RCL+ 81
RCL+ 82
RTN
-------
20 steps

I've tested it with the above mentioned values and it works perfectly, almost any initial guesses (except complete nonsense values of course) now give the correct solution, and the first guess may even be 0 now. :-)

But the problem that most users forget to give 2 initial guesses still exists - and I'd really prefer if the values for I would have to be entered in % (and not as interest 'rate', i.e. divided by 100), because this is much more usual for us humans (and also easier to input).

Franz

PS: my rearranged TVM formulas:

i=0: n*PMT+PV+FV=0

i!=0: ((1/i+k)*PMT+PV)*((1+i)^n-1)+PV+FV=0
with k=0 for END payments and k=1 for BEG payments

And if the interest value "I" is given in %, then TVM looks like this:

LBL 'TVM'
RCL 83
x!=0?
SKIP 03
RCL+ 84
RCL* 80
SKIP 13
1
%
STO Y
1/x
FS? 80
INC X
RCL* 80
RCL+ 81
x<->y
ln1+x
RCL* 84
e^x-1
*
RCL+ 81
RCL+ 82
RTN
-------
23 steps

Edited: 29 July 2011, 1:19 p.m. after one or more responses were posted


#80

Here's a comment from the math library that might interest you:

//PSI =  w^(N-1)+w^(N-2)+...w+1;   w=1+i
//Two Cases depending on the value of i:
// | i=0 | i#0 |
// PSI | N | [w^N - 1]/i |
// w^N | 1 | (1+i)^N |
// Algorithm: For 0 # |i|<<1 accuracy is preserved by using
// the functions: E(x)=e^x-1 & L(x)=Ln(1+x).
// PSI=[(1+i)^N-1]/i = E{N*L(i)}/i

TW

Edited: 29 July 2011, 11:38 a.m.


#81

Quote:
Here's a comment from the math library that might interest you:

Thanks Tim!

'math library' of which calculator?

Maybe I can find some other interesting things there ... ;-)

Franz


#82

That code comment is from the Saturn Math library. I imagine you want more info about the Napier math library though.

Napier is a platform independent C recreation of the saturn math library developed using the Saturn ASM from several units. Developed as part of the 20b and since used in the 30b, 10bII+, 12cp iphone app, some other software calculators (like what comes with the calcpad), and will be used in things moving forward.

That is why the solver in the 30b gets exact results as the 48 series, and the forensics are identical.

TW

Edited: 29 July 2011, 2:48 p.m.

#83

Ah thanks. I did not see a reference that two guesses were required in the manual.

But, hey... my question may lead to a better TVM routine in the unit. Woohoo.


#84

In fact we now got a proposal for a better TVM routine in the 34s. Maybe there's an even better solution - let me think one step further:

Mathematically, the TVM equation usually does not require any guesses at all to solve for one of their variables. This is because for PV, FV, PMT and N there are more or less simple closed form solutions that do not require any guessing - if you want to know the value for an annual payment, simply calculate it directly. The interest rate is the only exception here - for this case there is no explicit solution, so the Solver is required for an iterative approach. This leads to the Solver numerically solving the TVM equation for the interest rate i, which in turn requires two guesses given by the user.

In other words, providing a TVM equation is only useful for this single case, i.e. when the interest rate is unknown. This is where the 34s differs from the way other HPs work:

The 35s, for example, also can store such an equation in order to solve for any of its variables. The essential point here is the ability of the 35s to solve for all variables (except i) without any interaction of the user. No initial guesses are required as the user wants to solve for PMT, FV or other values, and the result shows up immediately because it is calculated directly by the 35s. The solver built into this device is able to realize that every variable (except i) shows up only once in the TVM equation, so that it can solve directly for this variable by rearranging the equation. No guesses required. Only if it's the interest rate that has to be solved for, it has to rely on an iterative approach, requiring two guesses.

This is what makes the difference between a "sophisticated solver" like the one in the 35s and a purely numeric solver like the one in the 34s (and 34C, 15C etc.). The more "intelligent" version like the one in the 35s is a nice example for using the solver with not more than just one single equation, even in cases where an explicit solution exists - the calculator will return this explicit solution without any initial guesses or more or less time-consuming iterations.

On devices where such a solution is not possible, I think it's much better to code the direct solution for every single variable. So does the TVM program in the HP-41 standard pac: variables like PV, FV, PMT and N are evaluated directly, while the interest rate is calculated by iteration. A first estimate is set by the program, the user does not have to care about this.

So, what's the use of an TVM equation in the 34s? It is nice for determining the interest rate, using the built-in solver, after the user has provided two initial guesses. Simply because there is no other way to solve for this variable. For all other cases a simple direct solution exists - but since the current approach uses the iterative solver in these cases as well, the user has to enter two estimates for each and every variable - and hope that they are good enough to lead to the correct result.

That's why I think the TVM equation does not make much sense in the 34s. As opposed to calculators with more sophisticated solvers like the 35s. For other devices, I think four routines with the explicit solutions of the four variables are a far better solution. So I would recommend to either omit the TVM equation completely, or, if this functionality is really required, provide the four direct solutions. If you dislike both suggestions, at least there should be a clear hint in the manual and the given example, pointing out that using the TVM equation does not only require calling the solver but also two initial guesses. No, I do not think that "this is obvious because it applies to every call of the solver anyway". Just to be sure. ;-)

Dieter


#85

Quote:
So I would recommend to either omit the TVM equation completely, or, if this functionality is really required, provide the four direct solutions.

Well, of course your 2nd suggestion would be the best solution, but there's just not enough space for all 4 formulas, and financial calculations are simply not of high priority in the WP34s project (I know what I'm talking about - I made some experiences in the past here with my suggestions about this issue ;-)).

But I definitely don't agree with your 1st suggestion - although the method with the solver is not optimal, but why should then this TVM equation be completely removed now that my improved version above works so much better and it uses just a few bytes?

With the same argument you could remove the whole solver because it can't solve EVERY equation - or the integration routine because it certainly can't integrate EVERY function.

And back to TVM:

If someone really needs a better TVM routine, there's always the possibility to write those 4 rearranged solution formulas by himself.

Franz


#86

There are certainly better TVM machines then the 34S. Take the 30b for example. ;-)

TVM was implemented as a goody and it still needs some coding around to be useful. It's more of a proof of concept or nice example with some generic value.

It shouldn't be too complicated to code the four equations for a direct solution and set up a routine for the i solver with automatic guesses. This can then be put in a library file and stored in flash. That's the preferred way of adding features to the 34S which do not require extended precision (only internally available) or hardware support (like serial I/O). Many math problems can be solved in user code and be provided as a library. Matrix and vector arithmetic is one the areas which needs a volunteer to port some existing code.

#87

I looked at including individual routines to solve for each of the parameters using the closed form formulas where possible and the space require was larger than I could justify for a piece of functionality that really is just a nice to have tack on in a scientific calculator.

That doesn't mean I'm closed to the idea, just that I'm not going to spend the time writing very compact but still properly functioning versions of this for each of the five possibilities.


- Pauli

#88

Quote:
That's why I think the TVM equation does not make much sense in the 34s.

This matches my thoughts too but Walter seemed adamant about having it and the implementation then was only about forty bytes (now it is fifty).


- Pauli


#89

Quote:
Quote:
That's why I think the TVM equation does not make much sense in the 34s.

This matches my thoughts too but Walter seemed adamant about having it ...

In fact TVM is the only reason why I reach out for a financial calculator. Thus I requested this - thinking it may be more useful than much of the arcane mathematical items we kept adding ;-)

Walter


#90

Quote:
...much of the arcane mathematical items we kept adding ;-)

You vetoed a lot of really good really arcane stuff :-)

Who wouldn't love having Mills's constant built into the device?


- Pauli


#91

Quote:
Who wouldn't love having Mills's constant built into the device?

Do you want me to start a poll? TVM vs. Mill's? ;-)

Walter


#92

Come on Mills's constant would win by a landslide :-P
It is hard to think of a more exciting number.

And no, no poll is required. I require my delusions to stay intact :-)

- Pauli

#93

Thanks for the suggestions. I've modified the TVM routine to handle the i of zero case. Initial estimates of 0 and 1 work now. So do estimates of 0.8 and 0.9 which aren't even close to bracketing the solution. It is still possible to confuse the solver with estimates that are on the silly side.


- Pauli


#94

Quote:
I've modified the TVM routine to handle the i of zero case.

I've looked at your modification, but it's not quite ok.

As you do it (with the PLUS and then the SKIP(11) jumps again to the last PLUS), the value PMT is added once more, so your expression is now PV+FV+N*PMT+PMT.

Simply making SKIP(11) to SKIP(12) would be ok, BUT it leaves the first entered PMT on the stack, so there has to be done a bit more
(e.g. move this first PMT at the end before the last PLUS)

BTW, why don't you use my code posted above which is just 20 steps compared to your 24?

Franz

Edited: 30 July 2011, 2:06 a.m.


#95

Quote:
I've looked at your modification, but it's not quite ok.

As you do it (with the PLUS and then the SKIP(11) jumps again to the last PLUS), the value PMT is added once more, so your expression is now PV+FV+N*PMT+PMT.

The code as written is fine. It leaves PMT in Y but that is harmless since this routine is meant to be called by the solver and the solver does it own thing with the stack.


Quote:
BTW, why don't you use my code posted above which is just 20 steps compared to your 24?

I tried your code, it didn't work starting with guesses of 0.8 and 0.9 :-( It was easier to fix my code than figure out what was wrong.


- Pauli


#96

Quote:
The code as written is fine. It leaves PMT in Y ...

No, the code is NOT fine!
It doesn't leave PMT in Y but adds it once more to PV+FV+N*PMT.

And BTW, a guess of 0.8 and 0.9 would mean 80 and 90% !!!

Not very useful guesses I'd say (especially if the interest rate of this problem is 0.85%) ...


Edited: 30 July 2011, 3:23 a.m.


#97

Quote:
No, the code is NOT fine!

Oops, I should look harder :-( Fixed now.


Quote:
And BTW, a guess of 0.8 and 0.9 would mean 80 and 90% !!!

Not very useful guesses I'd say (especially if the interest rate of this problem is 0.85%) ...

I know it is a bit silly, however it is a legitimate initial guess. Especially for someone who forgets to supply any guesses. Robust code shouldn't care too much.


- Pauli

#98

Quote:
I tried your code, it didn't work starting with guesses of 0.8 and 0.9 :-( It was easier to fix my code than figure out what was wrong.

Absolute nothing was wrong with my code! I've now tried it here again exactly with your nonsense guesses of 0.8 and 0.9, and the correct result is given without any problems.

I really don't know what's your problem with me, but no matter what I post - everything is either criticized or claimed to be wrong, even if I'm 100% right.

I've now really enough of your behaviour - I wish you much fun and success in your WP34S development, but don't expect to see any further contribution to your project from ME here in the future!

Franz


#99

I just tried your code again and the answer it gives for starting guesses of .8 and .9 is 0.4891696495606895. The solver is getting confused and convergence is *very* slow reaching its iteration limit before a solution is obtained.

I've triple checked what I've typed in against what you wrote above and am pretty sure I've got the code right. Could you verify that what you're running matches what you entered above.

Just to be absolutely sure, the code I'm running is:

ADDR  OPCODE     MNEMONIC

0001: 5b64 LBL A
0002: 6100 SLV 00
0003: 013a RTN
0004: 013a RTN
0005: 5b00 LBL 00
0006: 2453 STO 83
0007: 8803 PSE 03
0008: 5301 SKIP 01
0009: 1354 4d56 GTO'TVM'
000b: 5b67 LBL D
000c: 2b53 RCL 83
000d: 0018 x[!=]0?
000e: 5303 SKIP 03
000f: 2c54 RCL+ 84
0010: 2e50 RCL[times] 80
0011: 530a SKIP 10
0012: 020b 1/x
0013: 6d50 FS? 80
0014: 5a64 INC X
0015: 2e50 RCL[times] 80
0016: 2c51 RCL+ 81
0017: 2b53 RCL 83
0018: 0211 LN1+x
0019: 2e54 RCL[times] 84
001a: 0212 e[^x]-1
001b: 0303 [times]
001c: 2c51 RCL+ 81
001d: 2c52 RCL+ 82
001e: 013a RTN


- Pauli


Quote:
Could you verify that what you're running matches what you entered above.

Yes, it's the same code.

But I must stand corrected: I've in fact confused this 4.89E-1 with the true value 8.46E-3, so with these guesses my routine does indeed not work.

But that doesn't change anything on the above mentioned fundamental problem you seem to have with me ...

Franz


Franz,

Based on my experience, some people here are not accustomed to the direct way we learn in our country. OTOH, you can't expect others being excited about your suggestions everytime, so some "marketing" may be worth considering. And never forget you may get answers of a similar kind - so get used to take them.

Walter


Quote:
Based on my experience, some people here are not accustomed to the direct way we learn in our country.

...in our countries - Franz is from Austria. But well, the Holy Roman Empire is not much more than 200 years ago now, so it's still easy to confuse these things. ;-)
Quote:
OTOH, you can't expect others being excited about your suggestions everytime, so some "marketing" may be worth considering.

Advertising. Marketing is much, much more than that.

Dieter

I'd don't have any major issues with you or what you write, your input has been very useful thus far (in fact one of the most useful) and I think that every problem you've identified has been improved upon. We've both made silly mistakes today and I can live with that. Mistakes are part of life. If nobody made mistakes, life would be really dull. If you report a problem & I can't reproduce it means we've got a misunderstanding, not that either of us is wrong. Believe it or not, I actually believe testers' reports unlike many software developers.

However, this is (at least) the fourth time you've threatened to stop reporting problems. Either stop reporting them or stop saying you'll stop reporting them -- it gets tedious :-) I'd prefer you kept reporting issues and short comings -- we still need all the constructive input we can get. I'm hopeful of a final software release for the HHC in September.

BTW: I like problem reports regardless of who makes them or what they are about. Just don't expect your pet solution to be implemented blindly -- every issue you've raised thus far has resulted in an email discussion between Marcus, Walter and myself. I'll freely admit that we've not implemented your pet solution for many of these issues, but that is usually due to short comings that we'd prefer to avoid. We're trying to make the 34S the best calculator we can and we've got to consider the global impact and community response rather than just avoiding the local problem. That said, I believe we've adequately explained these short comings each time but I might be mistaken.

There is a lot going on with the 34S and I've only so much time to dedicate to it -- I'll also admit that I've been a bit abrupt at times, that is often a result of a bad day at work flowing over. For this I apologise. There is also a language barrier between us which might or might not have excited things -- again I apologise. My German is almost unheard of and your English is very good. Deceptively good in fact -- at times I forget that it isn't your native language. I've had the same problem with Dieter's posts at time as well :-( And Walter's myriad emails.

I've certainly not ignored all your suggestions, your vector cross product code is in the library, a very nice and compact piece of code and a good programming effort. I tried your TVM solution (twice now) and I don't know why it isn't working globally but I don't think I can commit the time to figuring this out for the sake of eight or ten bytes of flash.

I also thought about adding the percentage interest rate to the TVM code instead of the raw value. I'm quite undecided on this one. BTW: "S.R 02" is equivalent to dividing by 100 and much faster. This would be a viable replacement for % in your code.

Since you are actually coding for the 34S and have an interest in the TVM calculation, how about trying to implement the financial bank I mentioned? I can pretty much guarantee than a reasonable attempt will be included.


- Pauli

I've got a suggestion.

First up, I remove TVM from the xrom segment. What is there does what we wanted of it when we decided to include it, however it seems that it doesn't do what the community wants.

Secondly, this community writes a suite of financial functions in user code. We then include this code as the one of the user program flash segments as part of the build process. The contents and nature of this suite is completely open. Use the solver or use the dedicated formulas. Add other financial functions. The only limit will be the whole shall be one program flash segment only. That's 506 steps unless some trickery is performed.

I'll make a few suggestions and ideas but nothing hard and fast:

  • Avoid using lettered registers as temporaries, they are the easiest ones for users to use and firmware ought to avoid them.
  • The four hot keys are available if a program stops with a R/S rather than a RTN.
  • Subroutines are cheap and space saving, use lots.
  • Make the source compatible with the assembler.


So what do people think of this suggestion?

What other functionality suites could be included in a similar manner?

Volunteers?


- Pauli

PS: I'd do the two steps in the opposite order -- get the suite going and then I'll remove the TVM routine.


I second Pauli's suggestion. Here is a head start for a library application:

LBL 'FIN'
SSIZE4 // We need registers A to D
CLa
"Finance"
aVIEW
LBL 00
STOP
LBL A
ENTRY?
SKIP 01
XEQ 'F-A' // compute A
STO A
GTO 00
LBL B
...

This allows A, STO A, RCL A as keys to compute, set or examine parameter A. Hitting A will compute A if the entry flag was not set, otherwise it will store A. You will have easy access to four different parameters. Giving the subroutine that does the actual work an alpha label will make it available to other programs.

After each computation, the PC is moved to the beginning of the application in order to make the hot key labels the first to be found when the respective keys are pressed.

This suggestion is not in contradiction to Pauli's hint not to use the lettered registers. In this case, it's the user interface and it makes perfect sense to use the lettered registers here, because they match the hot key labels.

Happy coding!

Pauli, I'd like to have some more special labels such as "I" so that XEQ I may be used.

Edit: Added command to set stack size to 4. This might not be the best idea but somehow, A to D need to be made available for general use.

Edit: Corrected SSIZE4.

Edited: 30 July 2011, 10:26 a.m. after one or more responses were posted


Marcus,

Watch it: it's called SSIZE4 :-)

Walter

Quote:
Pauli, I'd like to have some more special labels such as "I" so that XEQ I may be used.

We have the op-code space for some more but I'm not sure how much extra flash it will consume....


- Pauli


Quote:
We have the op-code space for some more but I'm not sure how much extra flash it will consume....

- Pauli


I've started working on it but will not have the time to finish it this WE. Maybe Pauli can take over.

Fine - let me add some remarks:

First, "Finance" is much, much more than TVM, so I would suggest something more like a simple "TVM". ;-)

Using registers and labels with the same letter is not new, but still a good idea. That's how basically all TVM programs since the days of the 65 worked. ;-) However, all these solutions had one major advantage: there were five (!) hotkeys A to E, which really is quite nice if there are also five variables. ;-) These five softkeys would match the five financial keys of HP's financial calculators. Even the sequence was the same:

   N    I%   PV   PMT  FV
Looks like a quite logic and intuitive layout to me. Compare that with the current TVM equation which uses registers 80 - 84 for PMT, PV, FV, I%/100 and N.

So, to make your idea work there has to be a fifth hotkey, something like this XEQ I you suggested. Or maybe there even is a solution for a fifth "E" hotkey ?-)

Regarding the mathematical part and its coding for the 34s: The solution in the 41C standard pac may give a first idea. It can be found on this website. There are some details in this program that deserve a closer look:

Basically the 41C program works just like your idea: The "Entry?" test is handled by flag 22, and even STO A or RCL A can be handled by the HP-41 since pressing "A" to "E" here is a shortcut for the register addresses 01 to 05 used by the program. The question wheter to use an interest rate in percent or its decimal value is answered by simply using both: input and output are percentages (R02) while the program internally uses i/100 (R09) and 1+i/100 (R07).

If the interest rate has to be calculated the program first checks whether there is a periodic payment or not (PMT=0?). In the latter case the interest rate can be evaluated directly. Otherwise the usual iterative approach is required. Since the 41C does not feature a solver, a kind of Newton's method is used here. Before that, an initial guess of plus or minus 1E-9 is set, so that the routine will correctly find either a positive or negative interest rate. For the following iteration the choice of the equation to solve is crucial. The two different TVM equations given by Franz and Pauli show the importance of this point.

BTW - setting a common endpoint for each routine, in your example at Lbl 00, was good practice in the days of the 67/97 and even 41 (when local Alpha labels were used). But does it really make a difference in a calculator as fast as the 34s? Anyway - I like it as it reminds me of the good old days when the '41 was new. ;-)

Dieter

Edited: 30 July 2011, 10:04 a.m.


Dieter, if you have more then one application that uses hot keys in the same region it makes a difference where the PC is positioned. So good practice isn't the only explanation.

Having "only" 4 hot keys is a problem here where 5 variables need to be accessed. It's hopefully not to hard to overcome this in the firmware. If LBL I will not be implemented by Pauli, still LBL 'I' can be used which is called by XEQ ENTER^ I ENTER^. For setting the interest rate, STO I will then be the quicker manual key stroke sequence.

Quote:
First, "Finance" is much, much more than TVM, so I would suggest something more like a simple "TVM". ;-)

TVM is certainly the starting point. However, if we're putting aside a whole page of flash for this, a lot more than just TVM will fit.


- Pauli


Possibly Related Threads...
Thread Author Replies Views Last Post
  WP 34s : An old problem coming back Miguel Toro 2 570 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany
  TVM again ;-) fhub 17 1,602 09-02-2013, 11:03 AM
Last Post: fhub
  TVM WP34s trouble Jim P 4 682 06-28-2013, 07:31 AM
Last Post: fhub
  WP 34S flashing problem Gerson W. Barbosa 15 1,296 03-02-2013, 10:18 AM
Last Post: Gerson W. Barbosa
  HP 34S complex # problem Richard Berler 2 418 02-17-2013, 11:01 PM
Last Post: Richard Berler
  TVM-Solver for the PC fhub 14 1,402 12-26-2012, 03:24 PM
Last Post: fhub
  [WP34s] New TVM-solver version fhub 43 3,860 12-26-2012, 06:12 AM
Last Post: fhub
  [WP34s et al.] Solving the TVM equation for the interest rate Dieter 24 2,007 12-01-2012, 05:53 AM
Last Post: Paul Dale
  12c TVM problems where N is less than 1? James 29 2,896 11-25-2012, 11:50 AM
Last Post: Werner
  WP-34S transfer problem Reth 9 891 06-20-2012, 09:25 PM
Last Post: Reth

Forum Jump: