Does 12c resolve for i ?
Tony Hutchins
There is something very strange about the new 12c platinum.
Resolving for i is, one could say, no longer possible. My one
displays "running" for so long I have to press the ON key. I
have tried many simple examples now.
If indeed it does resolve, before running bateries flat, it
must take a very long time.
Oh, it did work n=10 i=10 pv=100 fv=0 solve for pmt=-162.745
resolve for i ... it seems to take 40 seconds.
On the classic gold 12C it takes 4 seconds.
This is, believe me, an example that is favourable to the 12c
platinum.
Unfortunately this does make it a returnable item, unless one
really likes bugs like this.
- Tony
Veli-Pekka Nousiainen
then change the n down by one and test again, until n=1
VPN
"Tony Hutchins" <t...@csi.com> wrote in message
news:1137558...@news.cis.dfn.de...
Tony Hutchins
29m ago, on Mon, 19.5.03 at 2:17 p.m. +0300, you wrote
in message ID <baaehi$fd9$1...@nyytiset.pp.htv.fi> :
> Have you tried IRR with 20 cashflows
> then change the n down by one and test again, until n=1
I'll get back to you tomorrow on that ;-)
No I hadn't tried it till you mentioned it.
I can't imagine what has gone wrong with interest rate
solutions. Maybe they don't use the same initial guess
strategy as on the 12C, or .. could be a wobbly exit
criterion - that part does seem new.
Eventually the answers produced seem OK.
In fact more accurate than the 12C in
some cases (not that the extra accuracy justifies the extra
computation time - convergence is so rapid near an answer):
n=E 8 i=1.234567891 E-6 PV=0 PMT=.01
Solve for FV=-1,973,883.396
Now resolve for i - I didn't measure how long it took -maybe
2.5 minutes, but the answer was 1.23456790 E-6. That is
MUCH better than the 12C which gives 1.235555343 E-6, not that
the 12C was known for great accuracy - and of course that
didn't dampen it's popularity. The 12C does it in about 5
seconds as against something like 150 in the 12c-pt.
Yup probably all it is is a new exit criterion - to fix it
they just need to drop back to the old code, which probably
took prcision to the maximum anyway, vis a vis internal
precision. But, if this is the case I wonder why the iteration
actually does actually stop, eventually.
- Tony
Veli-Pekka Nousiainen
Hi "Tony Hutchins" <t...@csi.com> wrote in message
news:1001758...@news.cis.dfn.de...
X
> In fact more accurate than the 12C in
> some cases (not that the extra accuracy justifies the extra
> computation time - convergence is so rapid near an answer):
> n=E 8 i=1.234567891 E-6 PV=0 PMT=.01
> Solve for FV=-1,973,883.396
12C: -1.973,883.296
19BII: -1,053,250.72188
49G: -1,053,250.72188
I think that you have already went past the accuracy limit here.
Any ideas of an easier calculation?
VPN
> Now resolve for i - I didn't measure how long it took -maybe
> 2.5 minutes, but the answer was 1.23456790 E-6. That is
> MUCH better than the 12C which gives 1.235555343 E-6, not that
> the 12C was known for great accuracy - and of course that
> didn't dampen it's popularity. The 12C does it in about 5
> seconds as against something like 150 in the 12c-pt.
David Davies
> Hi "Tony Hutchins" <t...@csi.com> wrote in message
> news:1001758...@news.cis.dfn.de...
> X
> > In fact more accurate than the 12C in
> > some cases (not that the extra accuracy justifies the extra
> > computation time - convergence is so rapid near an answer):
> > n=E 8 i=1.234567891 E-6 PV=0 PMT=.01
> > Solve for FV=-1,973,883.396
> 12CP: -1,973,883.143
> 12C: -1.973,883.296
> 19BII: -1,053,250.72188
> 49G: -1,053,250.72188
You just used 12 payments/yr on your hp49 instead of 1.
I get -1,973,883.39591 on the 49 and 48 ...
Cyrille de Brébisson
Wired,
on my 12c platinum, it takes less that 3 second to solve pmt for n=10, i=10,
pv=100, fv=0
can you give me the serial number of your calculator?
regards, Cyrille
"Tony Hutchins" <t...@csi.com> wrote in message
news:1137558...@news.cis.dfn.de...
Veli-Pekka Nousiainen
news:m3u1brc...@janus.local...
> "Veli-Pekka Nousiainen" <DROP...@welho.com> writes:
> > Hi "Tony Hutchins" <t...@csi.com> wrote in message
> > > In fact more accurate than the 12C in
> > > some cases (not that the extra accuracy justifies the extra
> > > computation time - convergence is so rapid near an answer):
> > > n=E 8 i=1.234567891 E-6 PV=0 PMT=.01
> > > Solve for FV=-1,973,883.396
12CP: -1,973,883.143
12C: -1.973,883.296
49G: -1,973,883.39591
>
> You just used 12 payments/yr on your hp49 instead of 1.
> I get -1,973,883.39591 on the 49 and 48 ...
That's how I *always* calculate my loans!
Set to 1/yr => Both the 19BII & 49G is same as yours
Question remains: does the problem already exceed a reasonable
accuracy limit at this point?
Tony Hutchins
| Tue, 20.5.03 06:48 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi Cyrille de BrÚbisson ! <cyr...@hp.com>
03h59m ago, on Mon, 19.5.03 at 08:48 a.m. -0600, you wrote
in message ID <3ec8eedd$1...@hpb10302.boi.hp.com> :
> Hello,
>
> Wired,
>
> on my 12c platinum, it takes less that 3 second to solve pmt for n=10, i=10,
> pv=100, fv=0
>
> can you give me the serial number of your calculator?
CN31301335, with the last digit stamped almost like an exponent.
Solving for PMT is not the problem.
*Resolving* for *i* is the problem.
Example f CLEAR FIN n=10 pv=100 pmt=-20 solve for i.
On the original 12C this takes 15 seconds. Solving for i again
takes 4 seconds, as the original 12C uses the existing i as
part of its initial guess.
On the new 12c platinum it takes 35 seconds.Pressing i again
takes another 35 seconds. This implies that the new platinum
12c does not re-use the existing i as part of the initial
guess strategy.
Tony
> "Tony Hutchins" <t...@csi.com> wrote in message
> news:1137558...@news.cis.dfn.de...
> > -=[ Monday, 2003-05-19 8:42 PM +1200 (NZT) ]=-
> >
> > There is something very strange about the new 12c platinum.
> > Resolving for i is, one could say, no longer possible. My one
> > displays "running" for so long I have to press the ON key. I
> > have tried many simple examples now.
> >
> > If indeed it does resolve, before running bateries flat, it
> > must take a very long time.
> >
> > Oh, it did work n=10 i=10 pv=100 fv=0 solve for pmt=-162.745
> > resolve for i ... it seems to take 40 seconds.
> >
> > On the classic gold 12C it takes 4 seconds.
> >
> > This is, believe me, an example that is favourable to the 12c
> > platinum.
> >
> > Unfortunately this does make it a returnable item, unless one
> > really likes bugs like this.
> >
> > - Tony
> >
>
--
Tony Hutchins
Wellington
New Zealand
#105 An ounce of discretion is worth a pound of
learning. Proverb
Tony Hutchins
| Tue, 20.5.03 07:17 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi Veli-Pekka Nousiainen ! <DROP...@welho.com>
02h44m ago, on Mon, 19.5.03 at 7:32 p.m. +0300, you wrote
in message ID <bab0uu$gik$1...@nyytiset.pp.htv.fi> :
> > > > n=E 8 i=1.234567891 E-6 PV=0 PMT=.01
> > > > Solve for FV=-1,973,883.396
> 12CP: -1,973,883.143
> 12C: -1.973,883.296
No, both those have the correct fraction =.396
The HP92 and HP37E give the same.
> 19BII: -1,973,883.39591
> 49G: -1,973,883.39591
> Question remains: does the problem already exceed a
> reasonable accuracy limit at this point?
Not at all.
The problem is in resolving for i.
Even on the HP41, a simple FIN program, using Newton Raphson for
the i solution, quickly recovers the full 10 digits in i.
On the HP41 the user has less precision available than the
internal programs appear to use.
The problem is with the slowness of the 12CP in resolving for
i. I was really surprised to see this. Then I thought - "Well,
maybe there is a work-around - like on the 12C it uses the i
already stored as an initial guess". But this seems to have
been removed on the 12CP!!! I never thought anyone would
tamper with the 12C TVM code for the i iterative solution, in
the slightest. As it is though, it must use an method that
converges very very slowly. I can't even imagine what that
could be. It definitely needs the old 12C "trick" of taking
the existing i as an initial guess.
--
Tony Hutchins
Wellington
New Zealand
#135 If you want to be happy, be. Leo Tolstoy
David Davies
> Question remains: does the problem already exceed a reasonable
> accuracy limit at this point?
What is 'reasonable'? in this context? 10^8 years is hardly a
'reasonable' number, but you might plug that sort of number in as a
lazy man's substitute for 'perpetual bond'. Or do you mean
'reasonable' as in "as good as we can expect from the underlying
floating point"? Or... calculate the NPV of the error and you'll be
shocked!
dd.
Veli-Pekka Nousiainen
X
> The problem is in resolving for i.
Preproduction units do have bugs...
VPN
Bruce Horrocks
<d...@daviddavies.com> writes
>> Hi "Tony Hutchins" <t...@csi.com> wrote in message
>> news:1001758...@news.cis.dfn.de...
>> X
>> > In fact more accurate than the 12C in
>> > some cases (not that the extra accuracy justifies the extra
>> > computation time - convergence is so rapid near an answer):
>> > n=E 8 i=1.234567891 E-6 PV=0 PMT=.01
>> > Solve for FV=-1,973,883.396
>> 12CP: -1,973,883.143
>> 12C: -1.973,883.296
>> 19BII: -1,053,250.72188
>> 49G: -1,053,250.72188
>
>You just used 12 payments/yr on your hp49 instead of 1.
>
>I get -1,973,883.39591 on the 49 and 48 ...
>
200LX gives -1,973,883.395908565
Regards,
--
Bruce Horrocks
Hampshire
England
b...@granby.demon.co.uk
Tony Hutchins
| Tue, 20.5.03 3:53 p.m. +1200 (NZT) |
+----------------------------------------------+
Hi Bruce Horrocks ! <b...@granby.demon.co.uk>
05h31m ago, on Mon, 19.5.03 at 11:21 p.m. +0100, you wrote
in message ID <BIYn8GCC...@granby.demon.co.uk> :
> >I get -1,973,883.39591 on the 49 and 48 ...
> >
>
> 200LX gives -1,973,883.395908565
Thanks for reminding me about the best HP TVM there is :) Both
the 200LX and the HP49 resolve for i% perfectly as well. Now I
remember - I think that internally the 12C, and probably all
earlier HP Finacial calcs find solutions internally for (1+i)
rather than just i. That "1" helps knock off significance.
This is just a guess - I think the HP "FINANCE" pack did that.
The funny thing is I really quite like the 12c platinum. At
first I honestly thought it could *not* solve for i, it was
taking so long. I couldn't imagine it remembering to finish.
But, now I am confident it does finish I can happily make
coffee while it's working :)
--
Tony Hutchins
Wellington
New Zealand
#74 All taglines are busy..One will be with you shortly.
John H Meyers
> Pre-production units do have bugs...
Is it at all the same processor as the original?
(note that new design uses quite a different battery voltage)
If by any chance it's a different processor,
was the original coding scrapped and rewritten,
and if so, could even the basic math operations
have any detectable differences in results?
Going from 99 program lines to 300 or so is certainly different,
as is the addition of dual RPN/ALG modes and extra programmable
instructions for same, which also must require, internally,
either more than 1 byte per program line or else
some sort of variable-length internal program encoding
(the original 12C had already used up either 255
or all 256 possible "merged" 1-byte program codes,
which was the original reason that storage register arithmetic
had to be limited to the first few registers).
Could it possibly really be a sheep in wolf's clothing?
[r->] [OFF]
.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Veli-Pekka Nousiainen
news:3ECB2680...@miu.edu...
> Veli-Pekka Nousiainen wrote:
>
> > Pre-production units do have bugs...
>
> Is it at all the same processor as the original?
> (note that new design uses quite a different battery voltage)
No, even the current 12C (Gold) has a new CPU
and a new battery system. 3-batt versions are collectables.
Now there are first camples with serial numbers
and all the bugs that I know of are gone.
Gotta find some new (maybe next week)...
> If by any chance it's a different processor,
> was the original coding scrapped and rewritten,
> and if so, could even the basic math operations
> have any detectable differences in results?
Only i and IRR are different
> Going from 99 program lines to 300 or so is certainly different,
max 399 lines. Note: only 20 registers are used in betas. R0-R .9
> as is the addition of dual RPN/ALG modes and extra programmable
> instructions for same, which also must require, internally,
> either more than 1 byte per program line or else
> some sort of variable-length internal program encoding
> (the original 12C had already used up either 255
> or all 256 possible "merged" 1-byte program codes,
> which was the original reason that storage register arithmetic
> had to be limited to the first few registers).
I don't know - I doubt that.
Aren't the GTO's double bytes anyhow?
> Could it possibly really be a sheep in wolf's clothing?
I think it's wolf/wolf and will eat the cheap sheeps away.
VPN
John H Meyers
> Note: only 20 registers are used in betas. R0-R.9
I didn't spot mention of any more regs
in the current downloadable manual;
only that R.9 disappears after program line 310 appears, etc.
So what's in the actual product, you guys that have 'em ?
> Aren't the GTO's double bytes anyhow?
Not in the original 12C; as a boring exercise,
try counting how many programmable operations exist
in that original specification -- don't forget
RCL g 12x and RCL g 12/ (which weren't in the original manual),
RCL g R/S (weird sequence for IRR with a guess),
f 0 thru f 9, GTO 00 thru GTO 99,
and all the storage register arithmetic.
You can not, of course, get GTO 000 thru GTO 400
into one-byte codes -- the manual keeps referring
to 7 lines program memory per sacrificed register,
but that leaves something unanswered.
In other HP models, the 15C had some 1-byte codes
(up to 240) and all the rest were 2-byte codes,
although they displayed as one "line number,"
while the HP32Sii has uniform 12-bit (1.5-byte) codes.
> I think it's wolf/wolf and will eat the cheap sheeps away.
I wouldn't trade one HP17Bii for two platinum 12Cs :)
The 17B/19B menus, many more built-in functions,
huge memory, and smarter equation solver than 48/49
are worth so much more to me than adding more program lines
to the primitive 12C programming system which was so restrictive
(no insertion, no labels, no subroutines, only 2 tests, etc.,
and gee -- no printing, either!)
So when will the platinum 48G come out?
(how about with a free built-in 256K + 4_MB flash memory bank? :)
Jordi Hidalgo
> the original 12C had already used up either 255 or all 256 possible
> "merged" 1-byte program codes
Weren't they 253? That's at least what Gregory Nelson wrote in the PPC Journal:
http://library.hp41.org/Files/00014/qajsiaaa.gif
253 + ALG + RPN + x^2 = 256 ... but what about GTO 100 through GTO 399?
New CPU with new bugs, I'm afraid. Read more in the next Datafile. :-)
Jordi
Jean-Yves Avenard
<jhme...@miu.edu> wrote:
> Veli-Pekka Nousiainen wrote:
>
>> Pre-production units do have bugs...
>
> Is it at all the same processor as the original?
> (note that new design uses quite a different battery voltage)
>
> If by any chance it's a different processor,
> was the original coding scrapped and rewritten,
> and if so, could even the basic math operations
> have any detectable differences in results?
It's an entirely different CPU with a totally new code. Just made it look
identical to the old HP12C. I guess differences in some calculations will
show more this fact.
> Could it possibly really be a sheep in wolf's clothing?
What about the reverse point of view ? :)
Jean-Yves
Jordi Hidalgo
> I guess differences in some calculations will show more this fact.
Also difference in execution times and bugs. AFAIK, there have never
been found any bugs in the 12C.
Jordi
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
John H Meyers
> AFAIK, there have never been found any bugs in the 12C.
I found one, in the original production era;
it has to do with trying to enter non-integers
as cash flow repetition factors, some values like
1.000000001, which *should* be detected as invalid,
but sometimes it is accepted, and then when recalled,
the value actually stored (or recalled)
may be found to have been interpreted as zero;
this is a very obscure bug, which has probably been observed
only by idle people who had no real money, and consequently
no real cash flows to enter :)
But in other areas, the 12C avoided common minor bugs that were
present in other models of the same series, such as 15C and 16C.
HP must have put their "A-team" on the original 12C :)
Jordi Hidalgo
> I found one, in the original production era
Confirmed in my two 12C's (1982 US & 1998 Malaysia) Fixed in the
Platinum, though (noninteger values for Nj generates an Error 6)
But I meant that there have never been any bug reports ... ;-)
Cyrille de Brébisson
> HP must have put their "A-team" on the original 12C :)
they more specially put over 5 year of R&D in it!
current products (like a 49G) are developped on 1 year time frame max. This
makes a word of a difference!
regards, Cyrille
J.Manrique Lopez de la Fuente
Yes, and past products were made to last, nowadays, most users buy a calc
for just their studies and perhaps some field calculus on work. You could
spent 5 years on R&D to show a new product, but times have changed.
Best regards,
--
J.Manrique López de la Fuente
Users Club from Gijón
1077 HPCC Member
Veli-Pekka Nousiainen
news:3ecbca42$1...@hpb10302.boi.hp.com...
Taitaa olla lähes satakertainen aika/koodi tehoero?
VPN
Veli-Pekka Nousiainen
> Veli-Pekka Nousiainen wrote:
> > Note: only 20 registers are used in betas. R0-R.9
> I didn't spot mention of any more regs
> in the current downloadable manual;
> only that R.9 disappears after program line 310 appears, etc.
> So what's in the actual product, you guys that have 'em ?
>
> > Aren't the GTO's double bytes anyhow?
> Not in the original 12C; as a boring exercise,
> try counting how many programmable operations exist
> in that original specification -- don't forget
> RCL g 12x and RCL g 12/ (which weren't in the original manual),
> RCL g R/S (weird sequence for IRR with a guess),
> f 0 thru f 9, GTO 00 thru GTO 99,
> and all the storage register arithmetic.
> You can not, of course, get GTO 000 thru GTO 400
Juuri näin! Siis kaksi tavua hypyille?
> into one-byte codes -- the manual keeps referring
> to 7 lines program memory per sacrificed register,
> but that leaves something unanswered.
>
> In other HP models, the 15C had some 1-byte codes
> (up to 240) and all the rest were 2-byte codes,
> although they displayed as one "line number,"
> while the HP32Sii has uniform 12-bit (1.5-byte) codes.
Oho! Tuota en _todellakaan_ tiennyt! 4096 komentoa!!
> > I think it's wolf/wolf and will eat the cheap sheeps away.
> I wouldn't trade one HP17Bii for two platinum 12Cs :)
Odotellaan sitten Platinum -malleja noista laskimista...
> The 17B/19B menus, many more built-in functions,
> huge memory, and smarter equation solver than 48/49
> are worth so much more to me than adding more program lines
> to the primitive 12C programming system which was so restrictive
> (no insertion, no labels, no subroutines, only 2 tests, etc.,
> and gee -- no printing, either!)
>
> So when will the platinum 48G come out?
Kenpä tietäis sen, ken kertoisi huomisen? Tänä vuonna?!
> (how about with a free built-in 256K + 4_MB flash memory bank? :)
Kuulostaa hyvältä! Lupaatko varmasti?
VPN
Tony Hutchins
| Thu, 22.5.03 11:00 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi Jean-Yves Avenard ! <m...@privacy.net>
07h08m ago, on Thu, 22.5.03 at 01:51 a.m. +1000, you wrote
in message ID <BAF1DD8E.EFFA%m...@privacy.net> :
> It's an entirely different CPU with a totally new code.
Wow, I did not guess that! That is a lot of work. I am
impressed that HP have done this. Must have required a lot of
testing as well.
> Just made it look identical to the old HP12C.
Ahha, that's why it seems the same ;-)
> I guess differences in some calculations will show more
> this fact.
Here I only notice that solutions for "i" in the TVM part seem
slower. Possibly the iterations go until greater accuracy is
achieved. Do you know if the iteration process uses the
"method of bisection"? This would be the shortest to code, but
relatively slow to converge. If there is limited room for code
then I guess this is all that can be done.
The great thing is : it *does* converge!! At first I honestly
thought it was never going to - oh me of little faith<G>
> > Could it possibly really be a sheep in wolf's clothing?
> What about the reverse point of view ? :)
LOL! Actually, what is the grey metal of this wolf in sheep's
clothing<G>. I assume it is "Al" rather than "Pt". If there is
some "Pt" on the case I hope it is extractable<G>
--
Tony Hutchins
Wellington
New Zealand
#64 Air Force Bingo: B-52...F-111...M-16...F-18...F-117...
Veli-Pekka Nousiainen
X
> LOL! Actually, what is the grey metal of this wolf in sheep's
> clothing<G>. I assume it is "Al" rather than "Pt". If there is
> some "Pt" on the case I hope it is extractable<G>
Do you mean it's not gold that I scraped off my HP 12C?
Adelfos-Petros
Roger Metcalf
"Veli-Pekka Nousiainen" <DROP...@welho.com> wrote in message
news:baanrp$vej$1...@nyytiset.pp.htv.fi...
<snip>
> 12CP: -1,973,883.143
> 12C: -1.973,883.296
> 19BII: -1,053,250.72188
> 49G: -1,053,250.72188
> I think that you have already went past the accuracy limit here.
> Any ideas of an easier calculation?
> VPN
Hi All: I have "HP Financial Calculator" ver. 1.02 for Windows (which is
software that was bundled with HP desktops and seems to be very similar to
the Solver in the 200LX) and it gives -1,053,250.721882
Cheers,
Roger Metcalf
Arlington, Texas
Roger Metcalf
"Roger Metcalf" <metca...@nospam.msn.com> wrote in message
news:E28za.422852$Si4.3...@rwcrnsc51.ops.asp.att.net...
17BII and 19BII both return : "Interest <= -100%"....
Roger
James M. Prange
<snip>
> Wow, I did not guess that! That is a lot of work. I am
> impressed that HP have done this. Must have required a lot of
> testing as well.
But from what I've been reading, maybe a bit more than they actually
did.
<snip>
--
Regards,
James
Tony Hutchins
| Fri, 23.5.03 08:14 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi James M. Prange ! <jmpr...@i-is.com>
34m ago, on Thu, 22.5.03 at 3:39 p.m. -0400, you wrote
in message ID <dD9za.54$nU...@fe01.atl2.webusenet.com> :
> > Wow, I did not guess that! That is a lot of work. I am
> > impressed that HP have done this. Must have required a
> > lot of testing as well.
>
> But from what I've been reading, maybe a bit more than they
> actually did.
Apart from solving for "i" when PMT<>0 it seems very good to
me. And, it is difficult to optimise that solution - for
example Newton Raphson can be used but that makes each
interation calculation take longer, and requires more coding.
Convergence is *incredibly* fast and almost independent of the
initial guess if a log transformation is used, but LN takes
time.
But, I agree, maybe a bit more testing, another iteration :)
It probably won't take much to speed it up. A nice challenge
for the team.
--
Tony Hutchins
Wellington
New Zealand
#3 ATS0=1, One Ring to Rule Them All.
John H Meyers
> 12CP: -1,973,883.143
> 12C: -1.973,883.296
> 19BII: -1,053,250.72188
> 49G: -1,053,250.72188
> I think you have already gone past the accuracy limit here.
One reason for the difference between the above groupings
is the two additional mantissa digits retained during
computations by the latter series of calculators;
on this ground, one might expect the latter to be more accurate.
As to differences in speed, I recall that early
TI "Business Analyst" calculators would take longer and longer
to solve for smaller and smaller interest rates, if indeed
they could get any solution at all, while HP had,
at least originally, better dealt with this problem.
The algorithmic approach taken may be a factor,
as well as the choice of alternate forms of the equation
which have the same solution but better convergence properties.
I have once suggested a change of variable, y=ln(1+i),
which has some advantages in solving first for y;
note that y and i are related here by the
now user-accessible functions EXPM and LNP1,
and that for very small i, you find that y and i are equal.
John H Meyers
> Convergence is *incredibly* fast and almost independent of the
> initial guess if a log transformation is used, but LN takes time.
When I once wrote out the keystroke programming of
two approaches for my HP-35, there was almost no difference,
except for the final transforming back to the original variable (i),
which was so small as not to matter much to me.
John H Meyers
> 17BII and 19BII both return : "Interest <= -100%"....
My 17Bii will solve for I%YR < -100 in TVM,
though not in CFLO (NPV/NUS/NFV/IRR),
where the above error message exists.
There is actually no "physical" sense to interest < -100%,
and the transform y=ln(1+i), which creates a useful time-reversal
symmetry (reversing all the cash flows in time sequence
corresponds to taking the negative of y) also makes it
impossible to solve for such a meaningless answer --
so if a calculator can solve for i% < -100%,
then it can't be using the best "universal" algorithm,
at least for problems which have true answers very close to -100%
(e.g. -99.9999999999%)
Tony Hutchins
| Fri, 23.5.03 11:08 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi John H Meyers ! <jhme...@miu.edu>
50m ago, on Thu, 22.5.03 at 5:18 p.m. -0500, you wrote
in message ID <3ECD4CBF...@miu.edu> :
> Tony Hutchins wrote:
>
> > Convergence is *incredibly* fast and almost independent of the
> > initial guess if a log transformation is used, but LN takes time.
>
> When I once wrote out the keystroke programming of
> two approaches for my HP-35, there was almost no difference,
> except for the final transforming back to the original variable (i),
> which was so small as not to matter much to me.
Ah yes, when working with LN(1+i) instead if i,but I was not
clear enough - I refer here to a log transformation of the
whole equation of value, and then applying Newton Raphson. I
need to distinguish 2 cases ( PV and FV cases). For the PV
case I find the root of F=LN(-f/g) where f=FV of PV, and
g=FV+FV of PMTs. So, when F=0 f+g=0 and f+g is the equation of
value. But the LN makes F almost linear in LN(1+i). It's quite
amazing, and convergence is really fast, with very little
dependence on the initial guess. Back in 1983 Don Dewey,
Graeme Dennes and I came up with a nice piece if HP41 code for
this. The LN transformation is only really necessary for FV
cases (where the FV can race away). I think an early version
of this TVM program, called 'FIN' was published in PPCJ.
Anyway, my bit in the search for the 'Holy Grail' ;-)
--
Tony Hutchins
Wellington
New Zealand
#264 Whether you think you can or think you can't
-- you are right. Henry Ford
Martin Cohen
for ln(1+x) and (exp(x)-1) useful when x is close to 0.
Tony Hutchins
| Fri, 23.5.03 12:27 p.m. +1200 (NZT) |
+----------------------------------------------+
Hi Martin Cohen ! <martin_...@west.raytheon.com>
26m ago, on Thu, 22.5.03 at 5:00 p.m. -0700, you wrote
in message ID <Hwdza.3382$c6....@bos-service2.ext.raytheon.com> :
> I think the 49 (and baybe the 48) has separate commands
> for ln(1+x) and (exp(x)-1) useful when x is close to 0.
Indeed. They were in the HP41C back in the early 80's.
--
Tony Hutchins
Wellington
New Zealand
#114 Fortune favors the bold. Virgil
John H Meyers
and history (re HP41).
> The LN transformation [different than the one which JHM mentioned]
> is only really necessary for FV cases (where the FV can race away).
Now, this brings up whether we want to focus on what we could
call "normal" or everyday situations in our experience,
or to generalize completely to cover all situations
with which the user might want to challenge the calculator,
to see just how robust (and consistent) it is.
When we say that "FV can race away," we mean that when
the interest rate is positive, as it generally tends to be,
FV can be very large, compared to PV and PMT.
However, for negative interest rates, the situation
can be exactly the reverse; in fact, for an interest rate
'j' such that 1+i and 1+j are reciprocals, the situation
is identical to that in which the entire cash flow sequence
is reversed, with PV and FV interchanged
(and BEGIN/END mode reversed as well), in which case
it is PV which can "race away," compared with PMT and FV!
This is why I have personally liked an approach which maps
the variable describing the "periodic discount factor" (1+i)
in such a manner that the problem remains exactly the same
when reversed in time, such as the transformation y=ln(1+i),
in which the "meaningful" values of y extend from -infinite
to +infinite (corresponding to an interest rate range of -100%
to +infinite), where a sign change of this value is equivalent
to a time reversal of all cash flows, and a good general solution
algorithm is one which covers this entire range equally well.
Another thing which has appealed to me is to symmetrize
the problem further by dividing out the non-linear coefficient
of PMT in the equation; when I used standard HP numeric solvers
on such transformed equations, these always managed to
converge well to an answer, for any cases which I ever
threw at it, except when letting it solve *numerically*
for 'n', in which case multiplying the entire equation
by 'n' proved to be helpful as well -- but since the
TVM equation is solvable algebraically for any variable
except 'i', only an interest rate solution need actually
involve an iteration within a calculator's internal functions.
As I said, the fact that in TVM (but not in CFLO)
the recent HP calculators accept and return meaningless values
where I%YR < -100% indicates that HP has never felt like
looking at this application the same way I do :)
The dreaded "deflation," by the way, does mean
a really negative interest rate ("modestly" negative,
rather than "impossibly" below -100% :)
Tony Hutchins
| Fri, 23.5.03 1:54 p.m. +1200 (NZT) |
+----------------------------------------------+
Hi John H Meyers ! <jhme...@miu.edu>
01h08m ago, on Thu, 22.5.03 at 7:45 p.m. -0500, you wrote
in message ID <3ECD6F27...@miu.edu> :
> Tony Hutchins, thanks for your interesting and detailed
> last post and history (re HP41).
My pleasure.
> > The LN transformation [different than the one which JHM
> > mentioned] is only really necessary for FV cases (where
> > the FV can race away).
>
> Now, this brings up whether we want to focus on what we could
> call "normal" or everyday situations in our experience,
> or to generalize completely to cover all situations with
> which the user might want to challenge the calculator, to
> see just how robust (and consistent) it is.
Ah, I prefer to at least aim for the latter, especially if it
means less code is needed.
> When we say that "FV can race away," we mean that when
> the interest rate is positive, as it generally tends to be,
> FV can be very large, compared to PV and PMT.
Yes it dwarfs the other cashflows and plays havoc with getting
an initial guess. The PV case where the initial cashflow and
the PMTs have opposite sign is much easier to handle.
> However, for negative interest rates, the situation
> can be exactly the reverse;
Oh yes, if j is the continuous interest rate for a transaction
then -j will satisfy the same transaction with time reversed
(make FV the PV and look backwards).
> in fact, for an interest rate
> 'j' such that 1+i and 1+j are reciprocals, the situation
> is identical to that in which the entire cash flow sequence
> is reversed, with PV and FV interchanged
> (and BEGIN/END mode reversed as well), in which case
> it is PV which can "race away," compared with PMT and FV!
Yes you could well be right there!! Thinking ....
Yup well put. The signs of PV,PMT,FV stay the sane - just
PV/FV are sawpped, and begin/end is swapped. Yup.
This means for my FV case I could have made it into a PV case
and solved for the "other" interest rate, then converted it
back to the one I wanted in the first place!In fact this is
probably similar work to distinguishing PV/FV cases in the first
place. How jolly interesting!! Thanks!
I don't think I even thought of this all those years ago.
Looking at the standard testing that was done all I can see
are positive interest rates!! One good thing I see is my
initial guess for the continuous rate is indeed reversed if
time is reversed. Hmm, if I had done selective time reversal to
force all cases to be PV cases I may have got faster
solutions.
> This is why I have personally liked an approach which maps
> the variable describing the "periodic discount factor"
> (1+i) in such a manner that the problem remains exactly
> the same when reversed in time, such as the transformation
> y=ln(1+i), in which the "meaningful" values of y extend from
> -infinite to +infinite (corresponding to an interest rate
> range of -100% to +infinite), where a sign change of this
> value is equivalent to a time reversal of all cash flows,
Exactly!
> and a good general solution algorithm is one which covers
> this entire range equally well.
I agree 100%<G>. The computation limit on the HP41 was where
EXP(n*LN(1+i)) gave an "OUT OF RANGE". That meant the growth
factor over the entire transaction had to be under about
10^100.
Using LN(1+i) also makes the maths easier (differentiation
etc). Also using continous payments (not available as such on
any HP Financial Calulator) makes the maths even easier.
> Another thing which has appealed to me is to symmetrize
> the problem further by dividing out the non-linear coefficient
> of PMT in the equation; when I used standard HP numeric solvers
> on such transformed equations, these always managed to
> converge well to an answer, for any cases which I ever
> threw at it, except when letting it solve *numerically*
> for 'n', in which case multiplying the entire equation
> by 'n' proved to be helpful as well -- but since the
> TVM equation is solvable algebraically for any variable
> except 'i', only an interest rate solution need actually
> involve an iteration within a calculator's internal functions.
Very interesting! I have done a TVM solver for the HP200LX
which finds all the non-i variables quickly, and also does
well with i. This is the only part that is actually 'solved':
+IF(CF<>0;L(J%;CF*LNP1(J%/CF/100)/PF);L(J%;J%/100/PF)))
+EXP(N*J%)*PV
+PMT*IF(J%=0;N;EXPM1(N*J%)/IF(BCE=0;J%;BCE*EXPM1(BCE*J%)))
+FV
CF=compounding frequency, PF=payment frequency. CF=0 means
continuous interest. BCE=0 means continous payments, with 1
for "END" and -1 for "BEGIN".
Oh first thing after that it converts back to the correct mode
of interest:
+0*(IF(CF<>0;L(J%;CF*EXPM1(J%*PF/CF)*100);L(J%;J%*PF*100))
You can see that in the solver part you can actually
resolve for CF or PF which seemed to work OK.
The whole EQN is quite long - it has lots of "toggle buttons"
(Not used for input or solving as such, just for toggling),
and also can save a whole transaction and recall it...
> As I said, the fact that in TVM (but not in CFLO)
> the recent HP calculators accept and return meaningless values
> where I%YR < -100% indicates that HP has never felt like
> looking at this application the same way I do :)
Yes - something like that could be naturaly controlled by
using the LN(1+i) which is not defined for i<-1 <G>
> The dreaded "deflation," by the way, does mean
> a really negative interest rate ("modestly" negative,
> rather than "impossibly" below -100% :)
Oh, don't mention the D-word ;-) Maybe you should talk to Mr
Greenspan and introduce him to the concept of time-reversal :)
-100% for one period just wipes an asset.
-100% compound is fine - the asset stays at zero.
-200% for one period turns an asset into a debt!!!
(as can happen to a futures trader)
-200% compound keeps swapping the asset/debt :)
For me -100% is quite desirable - I imagine being charged that
on my mortgage - I don't mind how many years the term is<G>
--
Tony Hutchins
Wellington
New Zealand
#104 The only discipline that lasts is
self-discipline. B. Phillips
Tony Hutchins
| Fri, 23.5.03 3:48 p.m. +1200 (NZT) |
+----------------------------------------------+
Hi Tony Hutchins ! <t...@csi.com>
30m ago, on Fri, 23.5.03 at 3:17 p.m. +1200 (NZT), you wrote
in message ID <1100190...@news.cis.dfn.de> :
[...]
> Very interesting! I have done a TVM solver for the HP200LX
> which finds all the non-i variables quickly, and also does
> well with i. This is the only part that is actually 'solved':
>
> +IF(CF<>0;L(J%;CF*LNP1(J%/CF/100)/PF);L(J%;J%/100/PF)))
> +EXP(N*J%)*PV
> +PMT*IF(J%=0;N;EXPM1(N*J%)/IF(BCE=0;J%;BCE*EXPM1(BCE*J%)))
> +FV
Whoops the first line there is multiplied by an earlier zero.
So, it is not part of the solved section.
> You can see that in the solver part you can actually
> resolve for CF or PF which seemed to work OK.
It does seem to work too - but I don't know why.
I checked a few 'n' solutions and they come out fine.
> The whole EQN is quite long - it has lots of "toggle buttons"
> (Not used for input or solving as such, just for toggling),
> and also can save a whole transaction and recall it...
And you can input yearly payments and have them converted to
the appropriate payment per payment period, etc. As a
by-product it shows the total interest etc so can be used for
amortization. The palmtop solver is a great application.
John H Meyers
>> 12C: -1,973,883
>> 19B/48/49: -1,053,250
jhm> two additional mantissa digits retained during computations?
Oops.. I guessed way wrong there;
David Davies had already spotted the real reason:
dd> You just used 12 payments/yr on your hp49 instead of 1.
dd> I get -1,973,883.39591 on the 49 and 48 [and 17Bii]
So it appears that all the calculators are just about
as accurate as they possibly could be, for FV, except
the difference between 12C and 12CP, in which my 12C
actually gets -1,973,883.396 (perfect),
and the 12CP is reported to have been a little off
in the last three mantissa digits (why, does it not
keep 13-digit internal mantissa and round to 10?)
Although even the original 12C can't recalculate 'i'
quite as well, the 17Bii can recalculate I%YR exactly,
in less than 1 second, even when it is deprived
of using a previously stored value by pre-storing
another I%YR value instead, no matter whether that "wrong guess"
is zero, or 9.99999999999E499, or -99.9999999999,
so gold must actually be worth more than platinum :)
Tony Hutchins
| Fri, 23.5.03 11:13 p.m. +1200 (NZT) |
+----------------------------------------------+
Hi John H Meyers ! <jhme...@miu.edu>
04h19m ago, on Fri, 23.5.03 at 01:54 a.m. -0500, you wrote
in message ID <3ECDC588...@miu.edu> :
> So it appears that all the calculators are just about
> as accurate as they possibly could be, for FV, except
> the difference between 12C and 12CP, in which my 12C
> actually gets -1,973,883.396 (perfect),
> and the 12CP is reported to have been a little off
> in the last three mantissa digits (why, does it not
> keep 13-digit internal mantissa and round to 10?)
My 12CP (production unit) is fine - same as regular 12C for
the FV.
That problem has n=1E8 and i=1.234567891E-6. LN(1+i) is
1.23E-6 and n*LN(1+i)=123, and this is way below the sensible
limit of 230 (EXP(230)=7.7E99). This is why this example is
way within the capabilities of all HP Financial calculators.
BTW another interesting symmetry is to use negative n, and
reverse the sign of PMT and swap PV,FV - the same interest
rate applies.
> Although even the original 12C can't recalculate 'i'
> quite as well,
correct - it gives only 1.234500000 E-06
I was told years ago the 12C worked to so many 'decimals', and
not to a relative error criterion on exiting the iteration.
0.0000012345 - yup it was 10 decimals - so that makes sense.
The 12CP slowly gets to 1.234567900 E-06 - I forget how long
it takes - over 2 minutes.
> the 17Bii can recalculate I%YR exactly,
> in less than 1 second, even when it is deprived
> of using a previously stored value by pre-storing
> another I%YR value instead, no matter whether that "wrong guess"
> is zero, or 9.99999999999E499, or -99.9999999999,
Yup the 17Bii is pretty good.
The resolving for i is amazing!!!!
[hehe maybe it keeps a databse of past examples, and seaches
this first <G>]
Here the 17Bii gives FV=1973833.39591
The 200LX gives " .395908565
The 17Bii has the odd limitation that it will not resolve for i
when n exceeds E10. This is documented in the manual though.
Both 12C's have the same limitation, but this is not
documented. Technically the limitation has to apply to
n*LN(1+i) - that should be less than 230. High n is useful to
simulate continuous payments, for example.
> so gold must actually be worth more than platinum :)
Unless slow and steady wins the race :)
--
Tony Hutchins
Wellington
New Zealand
#336 Truth is mighty and will prevail. Nothing the
matter with this, except that it ain't so. M Twain
Veli-Pekka Nousiainen
X
> My 12CP (production unit) is fine - same as regular 12C for
> the FV.
> That problem has n=1E8 and i=1.234567891E-6. LN(1+i) is
> 1.23E-6 and n*LN(1+i)=123, and this is way below the sensible
> limit of 230 (EXP(230)=7.7E99). This is why this example is
> way within the capabilities of all HP Financial calculators.
This is what I also claimed earlier.
The problem should be reasonable to leave some correct digits.
> BTW another interesting symmetry is to use negative n, and
> reverse the sign of PMT and swap PV,FV - the same interest
> rate applies.
>
> > Although even the original 12C can't recalculate 'i'
> > quite as well,
>
> correct - it gives only 1.234500000 E-06
>
> I was told years ago the 12C worked to so many 'decimals', and
> not to a relative error criterion on exiting the iteration.
> 0.0000012345 - yup it was 10 decimals - so that makes sense.
> The 12CP slowly gets to 1.234567900 E-06 - I forget how long
> it takes - over 2 minutes.
Is it then more accurate than 12C?
I'll have to check that...
> Here the 17Bii gives FV=1973833.39591
> The 200LX gives " .395908565
Now where is my 200LX ??
VPN
PS: Have you tried IRR calculations in the 12CP ??
Tony Hutchins
| Sat, 24.5.03 09:00 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi Veli-Pekka Nousiainen ! <DROP...@welho.com>
08h46m ago, on Fri, 23.5.03 at 3:13 p.m. +0300, you wrote
in message ID <bal3dh$luc$1...@nyytiset.pp.htv.fi> :
[...]
> > The 12CP slowly gets to 1.234567900 E-06 - I forget how long
> > it takes - over 2 minutes.
> Is it then more accurate than 12C?
It appears that was the intention of the production team, and
it is borne out in this instance. The original 12C team
purposefully limited the accuracy to the 10th decimal place as
they were aware of the trade-off between time and accuracy.
> I'll have to check that...
Best to leave it "running" for 3 minutes and come back.
I can supply an example where it takes over 5 minutes, if you
want more time ;-)
[...]
> PS: Have you tried IRR calculations in the 12CP ??
Briefly. I don't have that much time for testing. For me
personally the IRR is of more use for solving polynomials than
modelling cashflows from the real world. But maybe it is a
factor on the popularity of the 12C. The reason I liked the
12C when it came out was ... it was the first HP calc to have
y^x on *top* of a key!! Also that "Delta %" is real useful.
Was there a problem with IRR in the beta unit? - if you explain
what the problem was I am happy to test if it has been solved.
John H Meyers
> the original 12C, recalculating 'i' gives only 1.234500000 E-06
On my 12C, serial 2310A.....
End mode
n = 1E8
PV = 0
PMT = .01
FV = -1,973,883.396
Solving for i, in my display I see 0.000001236,
while f PREFIX reveals the full precision 1.235555343E-06
Am I comparing an apple to an orange,
or could there be yet more extant and different
software versions of the HP12C?
Tony Hutchins
| Sat, 24.5.03 12:44 p.m. +1200 (NZT) |
+----------------------------------------------+
Hi John H Meyers ! <jhme...@miu.edu>
01h20m ago, on Fri, 23.5.03 at 6:23 p.m. -0500, you wrote
in message ID <3ECEAD75...@miu.edu> :
> Tony Hutchins wrote:
>
> > the original 12C, recalculating 'i' gives only 1.234500000 E-06
>
> On my 12C, serial 2310A.....
>
> End mode
> n = 1E8
> PV = 0
> PMT = .01
> FV = -1,973,883.396
>
> Solving for i, in my display I see 0.000001236,
> while f PREFIX reveals the full precision 1.235555343E-06
>
> Am I comparing an apple to an orange,
No John you are 100% correct.
Me culpa - I wrongly read a result from my old book - the HP92
gave 1.234500000 E-06, for what it's worth :)
Also the HP37E and HP38C gave the 1.234500000 E-06.
I remember now - then along came the new 12C which gave
something really accurate to only 1.2 E-06. Yet, it became the
most popular HP calc ever! Fascinating!
Even back in 1983 a 12C I tried gave exactly the same as your
result.
I could only conclude then that there were severe limitations
with the 12C CPU compared to earlier HP Financial calcs, or
that somehow a lot of HP mathematical knowledge had been lost.
> or could there be yet more extant and different
> software versions of the HP12C?
No, I have a recent 12C which gives the same.
Now, where does that leave my statement about 10 decimal
accuracy - maybe it is actually 10 decimals of the fractional
i, not the percentage i. So the old 12C is accurate to only
the 1.2 E-6 as a percent or 1.2E-8 as a fraction. Previous HP
Financial calculators were much faster *and* more accurate, as
is the HP17Bii now, for example. The 12C really stands out!!
I do actually *use* the 12C as a calculator though. Everything
is nicely to hand. Probably on no other calculator are y^x and
"delta%" so easy to find.
Thanks for the correction John!
Tony Hutchins
| Sat, 24.5.03 3:08 p.m. +1200 (NZT) |
+----------------------------------------------+
Hi Tony Hutchins ! <t...@csi.com>
01h50m ago, on Sat, 24.5.03 at 1:17 p.m. +1200 (NZT), you wrote
in message ID <1087165...@news.cis.dfn.de> :
> Even back in 1983 a 12C I tried gave exactly the same as your
> result.
>
> I could only conclude then that there were severe limitations
> with the 12C CPU compared to earlier HP Financial calcs, or
> that somehow a lot of HP mathematical knowledge had been lost.
Well, well, little did I know!! I just found this great
article on the web:
http://mprc.pku.edu.cn/archta/codrefer/0405.pdf
written by Professor W. Kahan. He assited Roy Martin, Dennis
Harms and Rich Carone in programming the 12C!! And he mentions
that a log transformation was used, along with Newton
Raphson!! Oh it looks like that article was actually written
on 22 November 1983 as well! What a piece of history that I
never knew about all these years, but half suspected.
--
Tony Hutchins
Wellington
New Zealand
#255 The best way to keep one's word is not to give
it. Napoleon
Tony Hutchins
| Sat, 24.5.03 5:53 p.m. +1200 (NZT) |
+----------------------------------------------+
Hi Tony Hutchins ! <t...@csi.com>
02h10m ago, on Sat, 24.5.03 at 3:43 p.m. +1200 (NZT), you wrote
in message ID <1103031...@news.cis.dfn.de> :
> Well, well, little did I know!! I just found this great
> article on the web:
>
> http://mprc.pku.edu.cn/archta/codrefer/0405.pdf
>
> written by Professor W. Kahan. He assited Roy Martin, Dennis
> Harms and Rich Carone in programming the 12C!! And he mentions
> that a log transformation was used, along with Newton
> Raphson!! Oh it looks like that article was actually written
> on 22 November 1983 as well! What a piece of history that I
> never knew about all these years, but half suspected.
The article is also at
www.cs.berkeley.edu/~wkahan/MathSand.pdf
and on a second reading of pp14+ I see that the log
transformation is not the one I used.
He mentions a "problem of coping with huge n". (n > 1000)
Special allowance is made for this. Then on the 12C he says
more computation was required to cope with the fact that the
fractional part of n is considered differently - hmm maybe
that is the reason that slowness crept into the 12C - there is
just more computation for each iteration!
Contrary to what I thought, there must be a *lot* of code
dedicated to the "i-solution".
--
Tony Hutchins
Wellington
New Zealand
#56 A clean desk is a sign of a cluttered desk drawer.
Veli-Pekka Nousiainen
X
> > Is it then more accurate than 12C?
> I can supply an example where it takes over 5 minutes, if you
> want more time ;-)
> [...]
> > PS: Have you tried IRR calculations in the 12CP ??
>
> Briefly. I don't have that much time for testing. For me
> personally the IRR is of more use for solving polynomials than
> modelling cashflows from the real world. But maybe it is a
> factor on the popularity of the 12C. The reason I liked the
> 12C when it came out was ... it was the first HP calc to have
> y^x on *top* of a key!! Also that "Delta %" is real useful.
>
> Was there a problem with IRR in the beta unit? - if you explain
> what the problem was I am happy to test if it has been solved.
HP 19BII section 5, figure 5-7 (page 14)
INPUT OP OUTPUT
-50,000 [CF0] -50,000.00
5,000 [CFj] 5,000.00
3 [Nj] 3.00
10,000 [CFj] 10,000.00
4 [Nj] 4.00
0 [CFj] 0.00
15,000 [CFj] 15,000.00
3 [Nj] 3.00
IRR 11.30
What does the HP 12C Platinum give?
**************
CLEAR and start over.
Add after this line:
0 [CFj] 0.00
this
1 [Nj] 1.00
What happens then?
VPN
Tony Hutchins
| Sun, 25.5.03 00:44 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi Veli-Pekka Nousiainen ! <DROP...@welho.com>
04h19m ago, on Sat, 24.5.03 at 11:25 a.m. +0300, you wrote
in message ID <banadt$eiu$1...@nyytiset.pp.htv.fi> :
> HP 19BII section 5, figure 5-7 (page 14)
> INPUT OP OUTPUT
> -50,000 [CF0] -50,000.00
> 5,000 [CFj] 5,000.00
> 3 [Nj] 3.00
> 10,000 [CFj] 10,000.00
> 4 [Nj] 4.00
> 0 [CFj] 0.00
> 15,000 [CFj] 15,000.00
> 3 [Nj] 3.00
> IRR 11.30
> What does the HP 12C Platinum give?
11.29957340
In only 15 seconds!
I'menjoying this one, as it doesn't take too long ;-)
> **************
> CLEAR and start over.
Done :)
> Add after this line:
> 0 [CFj] 0.00
> this
> 1 [Nj] 1.00
> What happens then?
Same as above - 11.3 in 15 seconds.
Yep I double checked - I definitely had the 1 PMT of zero.
Looks like a success for the 12CP :)
--
Tony Hutchins
Wellington
New Zealand
#340 Do not be too timid and squeamish about your
actions. All life is an experiment. R-W Emerson
Tony Hutchins
| Wed, 4.6.03 11:05 p.m. +1200 (NZT) |
+----------------------------------------------+
Hi Veli-Pekka Nousiainen ! <DROP...@welho.com>
1 week 4 days 02h40m ago,
on Sat, 24.5.03 at 11:25 a.m. +0300, you wrote
in message ID <banadt$eiu$1...@nyytiset.pp.htv.fi> :
[snip re IRR]
> What does the HP 12C Platinum give?
Today when I advanced past 253 lines of program I suddenly
found that all existing GTO gave Error 4, which rendered the
first 253 lines pretty useless - but indaunted I continued on
and any GTO to a line over 255 worked!!!!!!
This still leaves the first 253 lines useless - but as I
prefer then to the 147 left I shall just clear the memory and
not go over 253 lines - apart from that the unit seems pretty
good - as in the first 253 lines I have done an i-solver that
is more accurate than the built-in version and is faster (not
hard<G>)
I did get a production unit, but I think it must be just be a
lively beta unit that escaped early :)
--
Tony Hutchins
Wellington
New Zealand
#98 Never lose a holy curiosity. Albert Einstein
Veli-Pekka Nousiainen
Seems like "a byte=maximum line address" -bug to me.
Are you sure about the 253? could it be 254 or 255?
I'm really hoping to get a production unit.
Veli-Pekka
PS: can you send your program here!
"Tony Hutchins" <t...@csi.com> wrote in message
news:1152711...@news.cis.dfn.de...
Tony Hutchins
| Thu, 5.6.03 08:10 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi Veli-Pekka Nousiainen ! <DROP...@welho.com>
08h25m ago, on Wed, 4.6.03 at 2:44 p.m. +0300, you wrote
in message ID <bbkm32$sjp$1...@nyytiset.pp.htv.fi> :
> Hi, Tony!
> Seems like "a byte=maximum line address" -bug to me.
> Are you sure about the 253? could it be 254 or 255?
Program lines are made available in bunches of 7 at a time.
My i-solver is 250 lines long. That leaves lines 251 and 252
and 253 with GTO 000 in. The first instruction in the new
program starts at line 252, then I type the second at line
253, and if I type the third then a new bank of 7 lines from
254-260 become available. Once this happens then all GTO in
the first program don't work.
I changed a GTO in the first program and found that all GTO up
to GTO 255 didn't work (except GTO 000 still works I think<G>)
but GTO 256 and over does.
This new bank of lines cannot be
"deleted" - the only way to fix things is clear the program
and re-type, only go up to line 253, and buy another 12C for
the second program<G>
> I'm really hoping to get a production unit.
I'll be very interested to see what the S/N is and if anything
has been fixed.
> Veli-Pekka
> PS: can you send your program here!
Sure - it's in a little 123 spreadsheet.
Tony Hutchins
Wellington
New Zealand
#208 The greatest deception men suffer is from
their own opinions. Leonardo Da Vinci
Gene Wright
the museum forum.
Gene
--
* These statements and opinions are mine alone and do not reflect my
employer's views. *
"Tony Hutchins" <t...@csi.com> wrote in message
news:1055525...@news.cis.dfn.de...
Tony Hutchins
| Thu, 5.6.03 10:50 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi Gene Wright ! <ge...@ford.invalid>
01h50m ago, on Wed, 4.6.03 at 3:59 p.m. -0500, you wrote
in message ID <bblmk2$n4...@eccws12.dearborn.ford.com> :
> I can confirm this happens on my beta unit. I also posted this bug report on
> the museum forum.
Thanks Gene.
Yup mine is a production unit, received 3 weeks ago from
www.educalc.net in Singapore. Last week 10 units arrived in
NZ. I haven't seen one but it is unlikely anything has been
fixed at this stage. But I understand units gave not appeared
in stores in the USA yet. When they finally do they might land
like lead balloons..<G>- however I still like it - it does show
real promise. Hopefully it will be fixed at some stage.
--
Tony Hutchins
Wellington
New Zealand
#10 PIT BULLDOG FOR SALE: Eats anything. Loves children.
Jordi Hidalgo
I think my calc will soon be a collector's item - Thanks!
A nice bug indeed. Here it is:
When program memory consists of at least 260 lines, the instructions
GTO n-255 through GTO 255 cause an Error 4, n being the last allocated
line: 260, 267 ... 393, 400 (NB: not 399).
Don't you love ugly bugs? :)
Not sure if there's time to include it in my review, though. BTW, anyone
interested in a copy, just email me (and give me a good reason why you
don't want to read it in Datafile).
Regards,
Jordi
Tony Hutchins
| Fri, 6.6.03 00:48 a.m. +1200 (NZT) |
+----------------------------------------------+
Hi Jordi Hidalgo ! <jo...@tv3mail.com>
02h35m ago, on Thu, 5.6.03 at 03:13 a.m. -0700, you wrote
in message ID <7fcf10a1.03060...@posting.google.com> :
> I think my calc will soon be a collector's item - Thanks!
My pleasure <G>
> A nice bug indeed. Here it is:
>
> When program memory consists of at least 260 lines, the
> instructions GTO n-255 through GTO 255 cause an Error 4,
> n being the last allocated line: 260, 267 ... 393, 400
> (NB: not 399).
Thanks for that Jordi - very elegant!
> Don't you love ugly bugs? :)
They have a beauty all their own :)
--
Tony Hutchins
Wellington
New Zealand
#85 We boil at different degrees. Ralph Waldo
Emerson