Calculator bugs

The standard Mac Calculator v4.2 (the lastest version as of writing) has some basic bugs it seems...
Try typing each of these. I'm using 15 decimal places in scientific mode, in Degrees, not in Reverse Polish (RPN) mode:
1E1, x^2, x^2 Produces "Error" but 10, x^2, x^2 succeeds
1,1/x,x!,x! Produces "Error". Fails on other initial numbers too.
2,1/x,cos,cos Produces "Error".
2,1/x,=,cos,cos is OK though.
Similarly x!,1/x,x!,x! produces "Error"
2,M+ causes all functions on the left (trig, power, exp etc) to stop (presumably this is as designed). But you can still press 1/x, if you press it before any other buttons.
Any number,y^x,PI,= gives the result as PI
Any number,y^1/x,PI,= gives the result as PI
Any number 'q',y^x,RN,= gives the result as RN + 10q for q < 1E16
Any number 'q',y^1/x,RN,= gives the result as RN + 10q for q < 1E16
1E16,=,y^x,RN,= gives the random number, but 1E16,-,M+,C,MR,y^x,RN,= gives "1e+17"
1E16,=,y^x,RN,= gives the random number, but 1E16,-,M+,C,MR,y^x,RN,= gives "1e+17"
9.99999999999999E127, =, =, = Produces odd results: "1E+128","Not a Number","Error"
And finally a harder one to get right:
1E22,sin (in radians) gives 0 but the correct answer is -0.8522008497671888017...
All the above work fine on the standard calculator for another OS I could mention. The command line 'bc' tool would work fine too I imagine.

typewriter wrote:
I'll add one more MAJOR calculator bug to the list.
The trig functions are completely wrong.
Examples :
COS(135) --> .707 (in degrees - should be negative)
I get - 0.707
COS(3) --> .989 (in radians - should be negative)
I get -0.99
SIN(-45) --> .8509 (degrees - should be negative)
I get -0.7091 - you are still in radians mode and even there the answer I get is -0.8509
Wrong wrong wrong. I can't even conceive HOW these could go wrong. Wouldn't the COS button on the calc just use the cos() function in the code?
You are correct about being wrong, but I cannot duplicate it on my calculator. The error is on your system. I believe you have a corrupt file somewhere.
And after pressing the Cos button:
Message was edited by: nerowolfe
Message was edited by: nerowolfe

Similar Messages

HP Prime calculating bug

Hi, I'll get right to the issue i'm having with my HP Prime calculator. Recently during an exam where i was calculating the moments of inertia of certain bodies i encountered what i can only describe as a bug in the software because I can't figure any other reason why it would kick out the answer it did for such a seemingly simple function. After I had done all the laboreous work of simplifying the differential equations I just needed to add some simple fractions. As i have been operating this calculator for several weeks now, the only way i can get it to show a fraction in exact form is to type (number) / (number) and it shows it in exact form. In my case and for this particular calcuation I input (3/20) - (1/7) "enter". the answer Prime gave me was noticably unsimplified given that i needed it in simplified form. although the numerical, non-exact value was almost correct (.00714285714309 instead of the correct value of .00714285714286), generally Prime kicks out a simplified value. What it gave me was 214500215/30030030099 instead of 1/140. i'm just curious if i need to do something different to get a simplified/correct answer on the first go rather than having to do a work-around.
Thanks in advance

If you want an exact and simplified answer on the first go, do your calculation in CAS view rather than Home view. Try this experiment.
1. Go to CAS view, and enter your calculation (3/20)-(1/7). The Prime will respond with 1/140, the exact answer. Now press the a b/c key. The Prime will respond with 0.00714285714286, the approximate decimal equivalent. Keep pressing the a b/c key, and the Prime will toggle between the two answers.
2. Now try the same steps in Home view. The Prime will toggle between 0.007142857143 and 214500215/30030030099.
Remember, the true decimal value for 1/140 is an infinite repeating number. Since every calculator can store only a finite number of digits, it must truncate the value after a set number of digits, and this introduces a small error. The big fraction you got in Home view is not wrong, and it's certainly not a bug. It's just that Home view is not designed to handle exact values. The CAS, on the other hand, is designed to handle exact values, so when you tell it to show an approximate answer, its decimal form will be closer to the exact value, namely, 1/140.
The moral of the story is, use CAS view when you want exact values and Home view when you want approximate values. I tell my students to use fractions whenever possible (since those are usually exact) rather than converting them to decimal values. It's far easier to use 1/3 than 0.33333....[infinite number of 3s go here].

WONKY calculation bug in Numbers 3.0.1

Hi,
This is wonky. It's a bit hard to explain in words, so best see the attachment to understand. You can download the attachment here: https://app.sugarsync.com/iris/wf/D162135_83773729_7822834
Basically, I have a number in each of A1, B1, and C1. The numbers have up to 2 decimals.
D1 contains the following formula: A1 - SUM( B1:C1 ), giving the result 19782.10.
E1 contains the number 19782.10.
F1 contains the formula D1 - E1.
The answer should be 0.00. Instead, it reads 0.00000000000363797881....
There is no inputted number anywhere with more than 2 decimal places. Clearly there is some kind of bug. The funny thing is if I change the formula in D1 to A1 - B1 - C1, then I get 0.00.
I've also tried changing the numbers in A1, B1, and C1 and then adjusting E1 accordingly. With very few exceptions, I get the correct 0.00. There is something about those particular numbers running through the SUM formula that produces the ghost decimals.
Of course, errors to the 12th decimal aren't going to throw off my spreadsheet too badly. But I have to wonder if these bugs are coming up in such simple math, what else is wonky in Numbers 3.0?
When I get weird results in my math, I like to be able to assume it is because of my error. Knowing that Numbers is wonky is going to add a lot of uncertainty to complex troubleshooting in my formulas.
What's the deal? Any ideas?
A

Hello
Here's a brief anatomy of 1.1 - 1.0 - 0.1 = 8.32667268468867E-17 and 1.1 - 0.1 - 1.0 = 0.0.
legend
    s = sign (0 => +, 1 => -)
    e = exponent (bias = 0x3ff = 1023)
    m = mantissa (hidden bit is explicitly represented; integer bit (1/0) in mantissa is hidden bit)
1.1 = 3ff199999999999a := {s = 0; e = 3ff; m = 1.199999999999a}
1.0 = 3ff0000000000000 := {s = 0; e = 3ff; m = 1.0000000000000}
0.1 = 3fb999999999999a := {s = 0; e = 3fb; m = 1.999999999999a}
1.1 - 1.0 = 3fb99999999999a0 := {s = 0; e = 3fb; m = 1.99999999999a0}
    3ff199999999999a - 3ff0000000000000
    = {s = 0; e = 3ff; m = 1.199999999999a} - {s = 0; e = 3ff; m = 1.0000000000000}
    = {s = 0; e = 3ff; m = 0.199999999999a}    [1]
    = {s = 0; e = 3fb; m = 1.99999999999a0}    [2]    # e -= 4; m << 4
    = 3fb99999999999a0
    = 2 ^ (0x3fb - 0x3ff) * 0x1.99999999999a0
    = 2 ^ (1019 - 1023) * 1.600000000000001421085471520...
    = 2 ^ -4 * 1.600000000000001421085471520...
    = 0.100000000000000088817841970...
1.1 - 1.0 - 0.1 = 3c98000000000000 := {s = 0; e = 3c9; m = 1.000000000000}
    3fb99999999999a0 - 3fb999999999999a
    = {s = 0; e = 3fb; m = 1.99999999999a0} - {s = 0; e = 3fb; m = 1.999999999999a}
    = {s = 0; e = 3fb; m = 0.0000000000006}    [1]
    = {s = 0; e = 3c9; m = 1.8000000000000}    [2]    # e -= 50; m << 50
    = 3c98000000000000
    = 2 ^ (0x3c9 - 0x3ff) * 0x1.8
    = 2 ^ (969 - 1023) * 1.5
    = 2 ^ -54 * 1.5
    = 8.32667268468867E-17
1.1 - 0.1 = 3ff0000000000000 := {s = 0; e = 3ff; m = 1.0000000000000}
    3ff199999999999a - 3fb999999999999a
    = {s = 0; e = 3ff; m = 1.199999999999a} - {s = 0; e = 3fb; m = 1.999999999999a}
    = {s = 0; e = 3ff; m = 1.199999999999a} - {s = 0; e = 3ff; m = 0.199999999999a}    [3]
    = {s = 0; e = 3ff; m = 1.0000000000000}
    = 3ff0000000000000
    = 1.0
1.1 - 0.1 - 1.0 = 0000000000000000
    3ff0000000000000 - 3ff0000000000000
    = {s = 0; e = 3ff; m = 1.0000000000000} - {s = 0; e = 3ff; m = 1.0000000000000}
    = {s = 0; e = 0; m = 0.0000000000000}    [4]
    = 00000000000000
    = 0.0
[1] This is not normalised form with hidden bit = 0
[2] This is normalised form with hidden bit = 1
[3] the 2nd term is not normalised form; LSB of mantissa of the 2nd term is result of rounding.
[4] +0
Cheers,
H

E72 - Arabic Calculator Bug Info

For ARABIC USERS who cant use their calculators on E72:
Menu>Ctl. Panel>Settings>General>Personalisation>Language:
Phone Language: Arabic
Writing Language: English
Number Format: Arabic or English
*Notes:
- The Number format option will only be visible if the phone language is set to ARABIC.
- The calculator will work in ARABIC if the 'Writing Language' will be set to ENGLISH, and the number format set to ARABIC
Hope this helps the arabic users. And I hope that this thing gets fixed on the next firmware release.
E71-1 (40) || RM-346 || 400.21.013

/t5/Software-Updates/Language-changed-or-missing-after-software-update-sticky/td-p/265903
And its not a good idea to post IMEI number on a public forum.
Previous Phones: 6600, 7610, 6230, 6230i, 1100, 1112, N70, N73, N95, N95 8GB, 5800XM, 5230, C5, iPhone 3GS, SE Xperia X10, N900, N8, SE Xperia Arc
Current Phones: Nokia N9, iPhone 4

Calculator bug in 10.6.4

If I press 1, then << several times, I can't exceed 1024, it loops to 2... This never happened before the 10.6.4 update. Am I the only one to experience that?

Probably, since it works here. Move the com.apple.calculator.plist file out of your /Library/Preferences/ folder onto the Desktop, log out and back in, and try again. If that fixes things, delete the moved file.

Prime calculator - Bugs

I have discovered several bugs in the latest firmware. They are:
If you chose "Digit Grouping" containing spaces or other signs, the solver stops working for larger numbers than 999...
It is no longer possible to plot more than one function. If I check two or more, the plot funtion reply "no function checked"...
/Hans

Hi,
These problems have been reported here:
http://www.hpmuseum.org/forum/thread-1443.html
http://www.hpmuseum.org/forum/thread-1705.html
http://www.hpmuseum.org/forum/thread-1565.html
Regards.
Note: I do not work for HP, I just like playing with calculators :-)

WP8.1 calculator bug

Using the build-in calculator I get two different answer for the same input.
Try this on you WP8.1
14 x 3600 + 7 x 60 + 5 = 3024425 (wrong)
Now try in landscape mode.
14 x 3600 + 7 x 60 + 5 = 508225 (correct)
Whats going on.
You can also try this:
2 + 1 x 0 = 0
2+ 1 x 0 = 2 (landscape correct)
Order of precedence should be the same regardless of the orientation.

Normal mode
(((14 x 3600) + 7) x 60) + 5 = 3024425
Landscape mode
(14 x 3600) + (7 x 60) + 5 = 50825
Yep. If you don't want issues use parentheses. Anyway, the two solutions are correct.
First one is using one variable where the calculator store the result of one binary operation and after do the same with this variable and the next operand.
Landscape mode use more than one variable.

My HD icon on the desktop is showing far more free space than I actually have.

I use a 2011 17" MBP with OS X Lion (750GB HD, 8GB RAM, 2.2GHz i7) and have noticed recently (only since I bought the new OS) that the Hard Drive icon on my desktop shows far more free space available than I know I have. It shows 488GB free of 497GB (with 250GB on a partition for Windows 7 Enterprise) and I know I have about 250-300GB worth of stuff. I've checked several times to ensure it's still there and all my files still work so it doesn't seem to be deleting things randomly. I just want to know if it's a calculation bug or if there's something else wrong. Thanks for any help in advance!

In case anyone reads this wondering if there's a solution, there is: turn off automatic time machine backups, and restart your computer. It turns out I had about 80GB worth of data stacking up between physical backups to external HDs. Apparently it counts as free space because it can be over-written when necessary, hence an elated free space count.
I also did a disk repair on the partition which OS X is on, which fixed some "minor logging issues" but I don't think that made a difference because nothing happened until I cleared the backup cache by turning off time machine. By the way, once I turned off time machine my HD free space sky-rocketed to 576GB of 497GB which freaked me out but don't worry, this is fixed once you restart.

Bug in excel 2012/pivot/summation of calculated field

I have a calculated field (called TO) in a pivot
= if(time >= 600,1,0)
where time is a field.
I present it in 'values' with 'sum'. It shows correct values, but the sub-totals are wrong. I can send an example if you tell me where to...

It's not a bug, it's a consequence of the way calculated fields work. You should read your formula as
=IF([subtotal of time in pivot table]>=600,1,0)
To calculate what you want, add a column with formulas to the source data of the pivot table.
Regards, Hans Vogelaar (http://www.eileenslounge.com)

Bug LABVIEW 2014 - Calcul Quotient et Reste

Bonjour à tous,
Avez-vous remarqué ce bug dans labview 2014 sur la fonction quotient et reste?
J'ai lu sur le forum anglais que le bug a déjà été vu en 2009. Il est à nouveau présent!
C'est la seconde fois que je tombe dessus et qui m'oblige à utiliser un "patch maison", mais cette fois j'en informe la communauté:
Par exemple dans mon cas 8.6 / 0.1 = 85 et reste 0.1... (voir PJ).
Merci aux personnes concernées de prendre en compte ce bug dans vos prochaines mises à jour car c'est une fonction assez basique...
Bonne journée.
Julien P.
Certified LabVIEW Developer
Résolu !
Accéder à la solution.
Pièces jointes :
quotient.vi ‏7 KB

Bonjour à tous les deux,
En effet, comportement particulier mais qui n'est pas un bug.
Le "souci" vient des règles qui régissent la façon dont sont arrondis les nombres à virgule:
IEEE Rounding rules
C'est pour celà que dans l'aide détaillée de la fonction une remarque est présente (cf Quotient et reste (fonction)):
"Remarque Certains nombres réels ne peuvent pas être représentés par les nombres à virgule flottante de la norme ANSI/IEEE. Il est donc possible que des erreurs d'arrondi surviennent et que LabVIEW produise des résultats inattendus si vous utilisez les nombres à virgule flottante avec cette fonction. Pour obtenir des comparaisons et des calculs exacts, convertissez les nombres à virgule flottante en entiers."
Bonne journée,
Valentin
Certified TestStand Architect
Certified LabVIEW Developer
National Instruments France
#adMrkt{text-align: center;font-size:11px; font-weight: bold;} #adMrkt a {text-decoration: none;} #adMrkt a:hover{font-size: 9px;} #adMrkt a span{display: none;} #adMrkt a:hover span{display: block;}
Travaux Pratiques d'initiation à LabVIEW et à la mesure
Du 2 au 23 octobre, partout en France

Overridable calculations...bug?

Has anyone been able to implement a field that is calculated, but can be
overridden? I have created a numeric field that calculates a value
based on two other fields. I then selected the field type to be
"Calculated - User Can Override". The calculations occur successfully,
however, if I attempt to override the calculated value, as soon as I
exit the field it replaces the typed-in value with the calculated value
again.
I have also trying experimenting with different values for the
'override' property on the Calculate object in the XML source, but
nothing seems to change the behavior. It doesn't appear to be behaving
the way the XFA Specification says it should.
Is this a bug? Is there any other way to allow overrides of calculations?
Justin

Jon,
What Ricardo is suggesting is a workaround to the Acrobat 7.x bug where a field whose value is calculated yet overridable cannot, in fact, be overridden in the way XFA specifies that one should be able to do.
When you set a field's Value Type to "Calculated - User Can Override" (using the Value tab in the Object palette), that's supposed to define a field with a calculated value (via script) which the user can opt to override with a specific value that, once entered into the field, shouldn't change.
The problem is that while Acrobat 7.x lets you override the calculation by entering a number in the field, once you press Enter or click away to commit the override, it's completely ignored and subsequent calculations use the calculated value from the script instead of the value that was specified as the override.
Using Ricardo's workaround, you can achieve the desired functionality without having to wait for a bug fix in Acrobat 8.0. Essentially, Ricardo's workaround is using a hidden check box to determine whether the calculation has been overridden. When the user enters a value, it's considered an override and the check box's value is set to 1. Then, when calculations are run on the form, the field's calculation script first checks to see if the check box's value is 1. If it is, it just uses the value already entered into the field. Otherwise, it uses the default script.
Stefan
Adobe Systems
Learn how to
build intelligent forms using Adobe LiveCycle Designer.

[bug] Numpad keyboard don't work with fractions in Spotlight calculations

In the hopes that the community can shine some light on this problem or possibly come up with an easy fix, I am posting a copy of a bug #7168140 here on the forums.
Numpad keyboard don’t work with fractions in Spotlight calculations
Summary:
Spotlight cannot perform calculations with fractions where the separator is comma (as it is in Norwegian) instead of the American period.
The Apple aluminum keyboard with numpad in Norwegian locale (Æ, Ø, and Å) have a comma instead of a period on the numpad (this differs from US keyboard with numpads).
Steps to Reproduce:
(Norwegian bokmål system local and a Norwegian keyboard with numpad required)
1. Open Spotlight using Command–Space
2. On the numpad, type: 79,9+56,50
Expected Results:
136,40
Actual Results:
"No result."
Screenshots:
http://yfrog.com/0tshotofspotlightp
http://yfrog.com/2qapplenorwegiannumpadp
Notes:
This works as expected in Calculator.app, but not with the Spotlight calculator.

It works in 10.6 Snow Leopard!

The calculator has a bug (at least iPhone 4)

Look at this bug in the calculator (tried on 3 different iPhone 4)
Go to the calculator in scientific mode (tilt it horizzontally)
Type 0.1234^100 (^ stands for the "pow symbol")
Enjoy the result
(It's off exactly by 256 order of magnitude)

The right answer using some math must be around 1.3e-91
Making calculations on scratch paper, by mind:
log10(.1234) ~= -0.908
make the pow: 100*(-0.908) = -90.8 = -91+0.2
10^0.2 ~= 1.31
so my best guess without the calculator was 1.327e-91, while the actual result is 1.353e-91.

Numbers 3 has bugs in calculations.

Hi,
Numbers 3 has bugs in calculations. And I do not mean rounding errors. I mean plain wrong. How can I get back to my older version? I have a time machine backup.
Thanks,
Gerd

Hi Gerd,
I opened the document and here is what I get. As you can see, it doesn't seem to be a Numbers bug.
I see you have the data format for the first row of the Jährliches Budget nach Monaten table set to Automatic and the format for the Monat column as a pop-up. You could try changing the data format for the first row of the Jährliches Budget nach Monaten table to a pop-up (and add the same pop-up list as you have in the yada table) and see if that helps.
Or maybe it's related somehow to your Language & Region preferences (System Preferences>Language & Region>Advanced>Dates.... Mine are like this and it's possible Numbers 3 is too fussy about what it expects.
SG

Can't figure out how to solve the decimal point bug in this calculator code

Hi guys, I'm new in flash and is currently learning how to build a simple calculator with multipliers (plus,minus,multiple,divide,decimal point and change sign) but I'm stuck on the decimal point and change sign.
var multiplier_old:Number = 10;
var multiplier_new:Number = 1;
// .: Sets the multipliers so that new input numbers become decimals of a lower unit column
action_point.addEventListener(MouseEvent.MOUSE_DOWN, function():void {
          multiplier_old = 1;
          multiplier_new = 0.1;
          point = true;
// Takes intput from the input_ buttons and adds it to the input after applying the multipliers.
// If `point` is true then the multiplier_new is divided by 10, also as described.
function inputNumber(n:Number):void {
          input = input * multiplier_old + n * multiplier_new;
                    if (point) {
                                    multiplier_new *= 0.1;
                   trace(multiplier_new);
          output_txt.text = input.toString();
Decimal point
The problem is that when I input 2.7 in the calculator, it will display the values in output_txt correctly. But then when I input 2.78, it will display 2.780000000000000000000000002. This will also happen to other numbers if the input is too big.
What I want is just 2.78. How do I change the codings to make 2.780000000000000000000000002 become 2.78?
Change sign
Any tips on how to start on this one?
Thanks for your time,
Zainu

I think you misunderstand what I mean. The weird decimal doesnt comes out after I press the 'equals' sign. It comes out when im just pressing on the caculator number buttons
First I click the no.2 button and then the decimal point button.
So the caculation output display will show
2.
after that I press the no.7 button
2.7
and then no.8 button. It appears like
2.7800000000000000002
This is the code I use when the user press the decimal point button.
// .: Sets the multipliers so that new input numbers become decimals of a lower unit column
action_point.addEventListener(MouseEvent.MOUSE_DOWN, function():void {
          multiplier_old = 1;
          multiplier_new = 0.1;
          point = true;
// Takes intput from the input_ buttons and adds it to the input after applying the multipliers in the method described above.
// If `point` is true then the multiplier_new is divided by 10, also as described.
function inputNumber(n:Number):void {
          input = input * multiplier_old + n * multiplier_new;
                    if (point) {
                             trace(multiplier_new.toFixed(3));
                              multiplier_new *= 0.1;
                              //trace(multiplier_new);
          output_txt.text = input.toString();
I think there is some code wrong in this function that makes this weird problem. I tried putting toFixed method but it's still not working.
Sorry for this long reply but I have to try my bestto explain with my bad english.

Calculator bugs

Similar Messages

Maybe you are looking for