Hmm, it looks like the I%YR improvement wasn't such an improvement after all.
I'll look into it, it looks like 1.0.6 won't be far behind...
(Specifically, the revised starting guess doesn't work for PMT=0, but it doesn't actually make sense to use the iterative I%YR solver in that case. When PMT=0, I%YR can be calculated directly, without needing iteration at all.)
(06-08-2022 04:57 PM)Thomas Okken Wrote: [ -> ]Hmm, it looks like the I%YR improvement wasn't such an improvement after all.
I'll look into it, it looks like 1.0.6 won't be far behind...
(Specifically, the revised starting guess doesn't work for PMT=0, but it doesn't actually make sense to use the iterative I%YR solver in that case. When PMT=0, I%YR can be calculated directly, without needing iteration at all.)
What do you mean ?
With PMT=0, nonzero (PV,FV),
edge rates = PMT/FV, -PMT/PV, both 0%, perfectly valid guess rate.
Edge rate is not meant for close to true rate, only to guarantee convergence (if solution exist)
Example, n=36, PV=-10000, PMT=0, FV=20000
I = 0% --> 1.869% --> 1.944% --> 1.944%
---
There is indeed a flaw with I%YR solver. It *assumed* solution exist, without confirmation !
do_i_pct_yr() seach loop terminate if (f=0) or (f'=0) or (--count==0) or (new_i==i)
After termination, it just returned the last i, which may not be a solution.
Example: n=36, pv=-10000., pmt=500., fv=-9000
I%YR solver return 6.2488% ??? (without warning!)
Correct answer is no solution.
do_i_pct_yr() Wrote:phloat h = i / 10000;
phloat f2 = tvm_eq(i + h);
phloat d = (f2 - f) / h;
The problem is h = 0 when i = 0, which produced NaN slope.
The bug exist before the new rate guess.
It is just very rare to be hit by it.
The plan is to prevent those errors by implementing the check you suggested, to rule out the cases where you know in advance that there is no root, or no unique root. I just need to make sure that that check does the right thing in both BEGIN and END modes, and I haven't had the time to look into that yet.
(06-08-2022 05:58 PM)Albert Chan Wrote: [ -> ]do_i_pct_yr() Wrote:phloat h = i / 10000;
phloat f2 = tvm_eq(i + h);
phloat d = (f2 - f) / h;
The problem is h = 0 when i = 0, which produced NaN slope.
The bug exist before the new rate guess.
It is just very rare to be hit by it.
Ah, OK. My original code used a hard-coded starting guess of 1e-4, so that particular failure could not occur.
1.0.6 is out now, all platforms, with the special case for PMT=0.
(06-08-2022 12:15 PM)Thomas Okken Wrote: [ -> ]Personally, I approached the big stack primarily from a programming perspective. As long as you can program stackrobatics, I don't particularly care how hard it is to reach those functions. And the functions are all there: ROT = R↑N 3, OVER = RCL ST Y or PICK 2, etc.
But to meet these or similar requests, a custom skin could serve, for example, by mapping CATALOG → STK to the keyboard perhaps.
Just to be clear on one of the key reasons that I appreciate easy access to the stack commands on my 28/48/50. It's more for when I'm working through ideas that involve a lot of stack acrobatics, it's useful to have everything laid out on the soft keys. I tend to flowchart longer programs but it's also useful to step through a problem as you would when approaching the problem on a non-programmable calculator, as you often find optimised approaches by 'gaming the possible steps'.
When it comes to entering the programs, the RPL calculators benefit from decent alpha layouts, so most of the time I just spell the commands out.
(06-08-2022 08:48 PM)Thomas Okken Wrote: [ -> ]1.0.6 is out now, all platforms, with the special case for PMT=0.
h=0 bug is still there, just now not from first guess.
It is possible a nonzero rate guess, coupled with correction, produce an iteration of 0%
It might be the second iteration, or third ...
Example: n, pv, pmt, fv = 10, 1000, -600, 5650.23
i0 = pmt/fv = −0.10619037 (guess)
i1 = i0 - f/f' = −0.00000006
i2 = i1 - f/f' = +0.03263217
i3 = i2 - f/f' = +0.03612254
i4 = i3 - f/f' = +0.03616164
Instead of special cased PMT=0, we may be better off with say,
h = 1E-6
We don't need really tiny h. With guess rate from the edge, f is relatively straight.
f = NPMT/n = ((pv+fv)/expm1(n*log1p(x))+pv)*x + pmt
plot (6650.23/(expm1(10*log1p(x)))+1000)*x-600, x = -0.106 .. 0.6
While testing a Plus42 (Linux version) program, I encountered a fatal program shutdown issue.
Following program cutout gives the necessary and sufficient elements to cause this problem.
Code:
00 { 56-Byte Prgm }
01▸LBL "TEST"
02 LSTO "AA"
03▸LBL 01
04 CLMENU
05 "L0"
06 KEY 1 GTO 81
07 MENU
08 STOP
09 EXITALL
10 GTO 01
11▸LBL 81
12 "L1"
13 LSTO "TYP"
14 LASTO "UN"
15 CLMENU
16 KEY 1 GTO 21
17 MENU
18 STOP
19 EXITALL
20 GTO 01
21 .END.
It uses a two-level menu in combination with LSTO and LASTO. In the second level, pressing RCL or STO causes the application to stop suddenly. I suspect this happens when showing the possible variables for STO or RCL. Removing 1 line of lines 02, 13 or 14 makes the problem go away.
I tested the same program also in the Android version. There it gives no problem.
That program does not seem to provide "necessary and sufficient" conditions to replicate the problem if you can't reproduce the crash on Android. For what it's worth, I'm unable to reproduce the crash on my iPhone as well.
So, it looks like additional context is needed. Maybe I'll be able to reproduce the crash if I could test with your state file. (Unless the problem is specific to the Linux version, but that seems unlikely. It sounds like a crash in the core, and that should be platform-independent.)
Correction: It is a bug in the core, but apparently it only causes a crash in the Linux version. It's performing and out-of-bounds access on an array of std::string.
I'm surprised that this doesn't seem to cause crashes in the Android and iOS versions, but I'll push out updates for all platforms anyway, since even without the crash, the code is incorrect in its current state.
1.0.7 is up on my web site now, and the Android and iOS versions are queued for their respective app stores.
The new version includes the variable catalog fix, and a couple of robustness improvements to I%YR.
Quote:That program does not seem to provide "necessary and sufficient" conditions to replicate the problem if you can't reproduce the crash on Android.
By necessary and sufficient I meant reducing the code to a minimum to repeat the crash on the platform I have available.
Quote:1.0.7 is up on my web site now, and the Android and iOS versions are queued for their respective app stores.
The new version includes the variable catalog fix, and a couple of robustness improvements to I%YR.
Thank you for the quick solution to the problem! By the way, your Plus42 application is a magnificent tool!
(06-11-2022 03:33 PM)Thomas Okken Wrote: [ -> ]1.0.7 is up on my web site now, and the Android and iOS versions are queued for their respective app stores.
It was fast in Google Play. The Signal developers always complain it takes days for a beta version to become available, but they do a staged rollout which seems to slow down things considerable.
Plus42 has now become my standard phone calculator (dethroning Free42).
(06-11-2022 07:54 PM)johanw Wrote: [ -> ]The Signal developers always complain it takes days for a beta version to become available, but they do a staged rollout which seems to slow down things considerable.
I'm sure it does, but if you have a lot of users, as I'm sure they do, you really want a staged rollout, so a buggy update doesn't cause everyone on the planet to try to contact your tech support all at once.
With the number of users I have, rolling out to everyone at the same time isn't much of a risk, and it does make for happier users, so that works better for me.
(06-11-2022 09:17 PM)Thomas Okken Wrote: [ -> ] (06-11-2022 07:54 PM)johanw Wrote: [ -> ]The Signal developers always complain it takes days for a beta version to become available, but they do a staged rollout which seems to slow down things considerable.
I'm sure it does, but if you have a lot of users, as I'm sure they do, you really want a staged rollout, so a buggy update doesn't cause everyone on the planet to try to contact your tech support all at once.
I remember that time they changed the manual reset session in case of errors option from manual activation to automatic. And then their own app started ddossing their servers. In the weekend of course.
In that case a staged rollout is a good thing.
Quote:With the number of users I have, rolling out to everyone at the same time isn't much of a risk, and it does make for happier users, so that works better for me.
I saw on Google Play it says 100+ users. The next step is 500 so there are only between 100 and 500 sales (Free42 has 100k+ downloads, I guess you are your own competitor here), I don't have the iOS numbers but I hope you don't have to live from this.
(06-11-2022 10:24 PM)johanw Wrote: [ -> ] (06-11-2022 09:17 PM)Thomas Okken Wrote: [ -> ]With the number of users I have, rolling out to everyone at the same time isn't much of a risk, and it does make for happier users, so that works better for me.
I saw on Google Play it says 100+ users. The next step is 500 so there are only between 100 and 500 sales (Free42 has 100k+ downloads, I guess you are your own competitor here), I don't have the iOS numbers but I hope you don't have to live from this.
Sales have been slower than I expected. I figured I'd sell at least 5,000 units, 5% of Free42 users being willing to pay for the upgrade seemed like a reasonable guess, but so far I've only just gotten to 1,000 (Android and iOS combined).
On the positive side, the app has gotten nearly a hundred ratings so far, and without exception, they are 5 stars, so at least the people who have bought the app appear to be happy with it. So maybe sales will continue to come in, even if at a slower rate than I had originally hoped. But I am going to have to find myself another 9-to-5 job, because this won't be sufficient for me to be able to retire early, especially with outrageous housing prices and general inflation making my savings disappear before my eyes. Fun times!
There is also a minor issue with TVM AMORT program. Entering #P = 0 breaks the calculation. Negative numbers or non-integer numbers do not break it, but zero does.
Confirmed, it allows 0 as input to #P, which it shouldn't, and then it gets stuck in a state where all the AMORT menu functions return Invalid Data, because the AMORT state is now invalid.
You can get out of that state by exiting and re-entering AMORT, but of course it shouldn't accept 0 for #P to begin with.
It will be fixed in the next release.
Thank you.
By the way, I find it very convenient to see simultaneously all values (#P, Interest, Principal, Balance) in the top display rows.
Is it possible to use them in user programs in the same way?
Original HP-42s commands VIEW, AVIEW and PROMPT work only with the header row.
(06-11-2022 11:34 PM)Thomas Okken Wrote: [ -> ][quote='johanw' pid='161209' dateline='1654986274']
Sales have been slower than I expected. I figured I'd sell at least 5,000 units, 5% of Free42 users being willing to pay for the upgrade seemed like a reasonable guess, but so far I've only just gotten to 1,000 (Android and iOS combined).
On the positive side, the app has gotten nearly a hundred ratings so far, and without exception, they are 5 stars, so at least the people who have bought the app appear to be happy with it. So maybe sales will continue to come in, even if at a slower rate than I had originally hoped. But I am going to have to find myself another 9-to-5 job, because this won't be sufficient for me to be able to retire early, especially with outrageous housing prices and general inflation making my savings disappear before my eyes. Fun times!
Sometimes a slow burn can be a good thing. Especially if it's combined with a steady stream of bug fixes and enhancements (much as you're currently doing).
Positive word of mouth is the hardest thing to force, and you're certainly getting that at the moment.