This bug affects irr.m and rate.m. Both irr() and rate() functions call
the fsolve() function in the same erroneous way.
How to fix rate():
- r = fsolve (sprintf ("pv (x, %g, %g, %g, \"%s\") - %g",
- n, p, l, m, v), 0);
+ f = @(x) pv (x, n, p, l, m) - v;
+ r = fsolve (f, 0);
How to fix irr():
- r = fsolve (sprintf ("npv (x, %s) - %g", p_string, i), 0.01);
+ f = @(x) npv (x, p) - i;
+ r = fsolve (f, 0.01);
These changes solve the error messages and they are already in the HEAD
of Octave Forge. But there is a specific bug in rate.m that is not yet
understood. If the initial value to fsolve is zero, the solution is
wrong. Use a non-zero value to isolate that other bug. Observe that
irr.m does use 0.01 as the initial value. Using Octave 3.4 series, the
zero initial value work for both irr() and rate(), as reported in octave
forge mailing list.
Ex. rate(30, 510.19, 10000) should return 3%.
This is a recent known bug to octave forge maintainers. And they are
fixed in 3.4 series (next bug fix release). The 3.2 series is not
maintained anymore. I do not know why Debian/Ubuntu uses an unmaintained
version.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/569030
Title:
irr.m does not work
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/octave-financial/+bug/569030/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
