Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 42
  1.    #21  
    jroach1 -
    saranss gave the best test example to see if there is indeed a problem.
    "Select the EDIT button. Then set the "payment/year"= 1, the "payment mode"=BEGIN, PV=0, FV=(blank), Pmt=-100, APR=5, n=1. This is when you make a $100 payment at the beginning of the year for 1 year at interest of 5%. We can figure in our head, that at the
    end of the year the value should be $105. Hit SOLVE. But the answer is $100 instead."
    If you try this on your Visor is this what happens? If you get $100 = there's a problem. On my TI I get the correct answer, $105.
    Don't be scared by this info. We are the first run guinea pigs. We will learn from it and be better people for it!! Right, Handspring?!?
  2. #22  
    to jroach1
    Your TI BAII default setting probably is in END mode. END mode is the one that most banks (if not all)uses when they calculate loans. It's more commonly use than BEGIN most calculator and programs default to END.

    My HP gives correct answers. I believe your TI BAII should also, that calc. has been around for a while.

    As far as the visor, I'm still waiting for the answer from Handspring.

    [This message has been edited by saranss (edited 02-13-2000).]
  3. #23  
    I'm still waiting ..........
  4. #24  
    In my case, PV and FV are ALWAYS 0... but's that's a personal problem...

    Anyway, since the HS Calc is supposedly based on one called Parens ( http://www.probe.net/~rhuebner/parens.html ), I downloaded it to compare and guess what? These same examples yield the same (incorrect???) results.

    I sent an email to the Parens developer to see what (or if) he has to say about all this.

    ------------------
    MarkEagle - Ice is nice!
  5. kstinnett's Avatar
    Posts
    18 Posts
    Global Posts
    19 Global Posts
    #25  
    Has anyone heard if this issue has been resolved yet?
  6.    #26  
    I started this mess, but haven't heard a thing back. I keep checking Handsprings site for a possible fix. My finance class has moved on to other things, luckily. But I would still like for this to be fixed. I may want to amortize something in the future!!!
  7. #27  
    I hate to keep bringing this topic up. But it's a bug that need to be fixed.



    [This message has been edited by saranss (edited 03-20-2000).]
  8. #28  
    JH,
    Have you heard anything back on this issue?
    I emailed HS long time ago but I got no reply.
  9. kstinnett's Avatar
    Posts
    18 Posts
    Global Posts
    19 Global Posts
    #29  
    Originally posted by JHromadka:
    I let Handspring know about the potential bug and am waiting to hear back from them on it.

    I am just trying to keep this thread open. Has anyone heard anything about this issue. I am a grad student and it is nice to use my Visor instead of taking along a calculator. However, if I can't trust the results it doesn't do much good.

  10. #30  
    I'm glad I'm not the only one waiting for this.
  11. #31  
    I've been watching this post to see if Handspring or VisorCentral has recommended any fix. Although I don't use the financial calculator functions much, (I prefer to set-up an Excel spreadsheet), I discovered my calculator gives an abnormal result for a simple calculation, as follows:

    1,761.69 - 1,57.20 = 4.4899999999998

    This answer comes up when using the advanced calculator: When using the basic, I get 4.49. It makes me leary about using the calculator when in business meetings, but I prefer not to have to carry my Visor and a calculator....
  12. #32  
    Oops - make that calculation

    1,761.69 - 1,757.20 = 4.4899999999998

  13. #33  
    Originally posted by Starman:

    1,761.69 - 1,757.20 = 4.4899999999998
    I get the same result with the calculator set to "Float". When set to "Fixed", the proper result is diplayed (ie 4.49000000 when set to fixed-8). It is an interesting bug.




    ------------------
    MarkEagle - Ice is nice!
  14. #34  
    Originally posted by Starman:
    Oops - make that calculation

    1,761.69 - 1,757.20 = 4.4899999999998

    Interesting,
    I use Finance calc. a lot but I've never used the Visor calc. because I don't trust it. Now it can't even do simple calculation.
    If you make
    1761.69 - 1757.19 and
    1761.69 - 1757.18
    I only tested down to 1757.15
    the answers were right.

    But if you make
    1761.69 - 1757.21
    This one I tested up to 1757.25
    the answers were wrong.

    But when I randomly tested it w/ any numbers. The answers were correct.

    This is weird. First I did not trust to use the financial calc. Now I don't think I'll use the calc. at all.
    I might be the only one, but one of the major reason for me to pick the Visor over Palm is the advance calculator function.
    Although I still love my Visor but I think this is unexceptable. Imagine people giving wrong answers in an important meeting.

  15. #35  
    Originally posted by Starman:
    1,761.69 - 1,757.20 = 4.4899999999998
    This is actually a very common problem with floating point numbers represented in computers. Before I go into the dry drivel, the basic calculator has a similar problem, one just cannot see it. Try the following in both the basic and advanced calculators:

    1761.69 - 1757.20 =
    * 100 =
    - 449 =
    In the advanced calculator (set to Sci-8), I get -2.18278728e-11. In the basic calculator I get: 9.0949470e-13. The answer done by hand is 0. Why the difference between the two calculators? I'm not sure, I assume it's a matter of representation differences. Why the difference between the calculators and 0? See drivel below.

    The Drivel:
    One has to remember most modern computers use binary number internally not decimal.
    10 = 2
    110 = 6
    1010 = 10
    There are many ways to represent floating point numbers on computers. The most common is referred to as IEEE floats or doubles, for the ANSI/IEEE 754 standard. Floats are 32 bits long, doubles and 64. I know that the advanced calculator uses IEEE doubles internally, I do not know about the basic.

    Ignoring the IEEE standard for a moment. How does one represent fractions in a binary manner.
    0.1 = 1/2 or 0.5
    0.01 = 1/4 or 0.25
    0.001 = 1/8 or 0.125
    But then what is a simple decimal fraction like 0.1?
    0.0001100110011001100110011001100110011...
    It is a repeating pattern. But that means no matter how many binary digits one uses, one cannot represent the number exactly. Now let us look at the numbers given in binary:
    1761.69: 11011100001.1011000010100011110101110000101000111101011100001010
    1757.20: 11011011101.0011001100110011001100110011001100110011001100110011

    Subtracting I get:
    100.0111110101110000101000111101011100001010001111010110

    Converting that back to decimal, rounding to 16 significant digits I get 4.490000000000000.

    Checking the on the standard, an IEEE double claims to store 53 significant binary digits, reducing the two number to only 53 binary digit, then subtracting I get:
    100.01111101011100001010001111010111000010100

    Converting this to decimal, rounding to 16 significant digits I get: 4.489999999999782. If one the rounded it to only 14 significant digits for display one gets the answer: 4.4899999999998.

    Now IEEE doubles claim to provide 16 decimal digits of significance. In the subtraction, one looses 4 (dropping from the thousands place to the ones place), thus only 12 digits should be relied on. 4.4899999999998 is within 12 digits of 4.49.

    Conclusions:

    Now, is this a calculation bug in the advanced calculator? Not really, it did "perform as designed". It might be argued to be a display bug. The calculator probably should not display more than say 10 significant digits, the advanced calculator author apparently choose 14, the basic 8.

    [This message has been edited by potter (edited 04-14-2000).]
  16. #36  
    Post Script:
    Historically, IEEE floats and doubles were meant for scientific and engineering type computations, where one is dealing with very small and very large numbers and you only care that you have so many significant digits. In Financial computations, you care that you have every last penny accounted for. Typically a financial program will use Binary-Coded-Decimal, where each decimal digit is encoded as 4 binary digits, or straight integers where one is counting pennies not dollars. Many old accountants, when using a paper-tape adding machine do not even bother hitting the decimal point key, they just add up the pennies. Using this technique here one can avoid the rounding problems with IEEE doubles.
    176169 - 175720 = 449
    Under both the advanced and basic calculators, and subtracting 449 correctly gives 0.
  17. #37  
    Once again, it was rumored that the advanced calculator that comes with the Visor is the same application as Parens. I have no idea if this is true or not and I don't even own a Visor. Has anyone contacted parens author, Rick Huebner, to see if this is true and whether he is aware of the problem calculating future values? His website is at: http://www.radiks.net/~rhuebner/index.html
  18. #38  
    Originally posted by bregent:
    Has anyone contacted parens author, Rick Huebner, to see if this is true and whether he is aware of the problem calculating future values?
    I tried Parens and, yes, the HS Advanced Calculator is modified from it. I also emailed the author about the original problem reported in this thread but never received a reply.



    ------------------
    MarkEagle - Ice is nice!
  19. #39  
    Since I work in the financial services industry, the calculator was one of the features that put the Visor ahead of Palm. Luckily, most of my calculations are "End of Period" plus I am still relying on my Sharp EL-733 until I get more proficient with the Visor calc. I sure hope HS responds soon to this problem. Until then, I guess I'm stuck carrying around an old but reliable calculator. (On the bright side, isn't the "retro" look back in style? Or is that only fashion and cars, not electronics?)
  20. #40  
    This will be the last time I try to keep this topic alive. I think it's a poor job from Handspring not even response to this problem. It's been approx. 3 1/2 mos. since the first post. Noone got any reponse from them.
Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions