Please anyone can share your opinion excel how to calculate the PI() value.
In Execl while Calculating =TAN(30*PI()) formula it returns -1.07809E-14.If i directly give the PI() Value(3.141593) it returns 1.03923E-05.
It's almost certainly not calculated at all, but simply stored as a constant at the maximum significance for the machine.
That's pretty certainly more than six decimal places.
Here's the first 20 digits, try putting that in: 3.14159265358979323846
The accuracy or otherwise of Excel's value for π is perhaps less of the issue here than that of Excel's TAN function. TAN takes an argument in radians and 30*PI() is the same angle as 2*PI(), ie 360 degrees (a complete circle - though it might be argued that 30*PI() is a circle after 15 complete turns). The tangent of 360o is 0 (or at least the tangent tends to 0 as the angle approaches 360o) hence whatever the accuracy chosen for π, any answer other than 0 is incorrect.
-1.07809E-14 is nearer 0 than 1.03923E-05 because as has been pointed out, Excel is normally accurate to at least 14 digits and PI() as 3.14159265358979 is more accurate than pi as 3.141593. However -0.0000000000000107809 is nevertheless inaccurate at the 14th decimal place.
A more sensible comparison may be between the tangent of 30o with PI() and 3.141593:
=TAN(30*PI()/180) = 0.57735026918963
=TAN(30*3.141593/180) = 0.57735034616967
To 7 DP the answers are the same.
Excel evaluates 30 times PI() as 94.2477796076938 whereas 30*3.14159265358979 as 94.2477796076937.
Microsoft lists the following:
MS Excel PI function
PI function
Description
Returns the number 3.14159265358979, the mathematical constant pi, accurate to 15 digits.
you can see this by typing:
=pi()
then increasing the decimal places until you see zeros eg:
3.14159265358979000000
Related
how to generate auto number from 0,000000000000000000000000000001 till 0,999999999999999999999999999999 at excel and the format cell is number ?
i've tried for dragging mouse , but i guess thats so terrible
You're out of luck.
Excel uses a 64 bit double precision IEEE754 floating point type for numbers (along with some clever rounding tricks). That gives you 53 bits of precision which loosely translates to 15 decimal significant figures of accuracy.
You will not be able to descriminate between numbers with such a small interval between them, if the total range is between 0 and 1.
(There's also the small matter of there not being enough space in a workbook to represent all those numbers.)
I'm currently writing a C program that among other things generates and prints out an amortization table with numbers rounded to two digits. I get the correct numbers everywhere, that is: monthly_payment = principal_paid + interest_paid except in the last row (last payment) where occasionally my results don't add up, and off by one. For example:
MonthlyPay: 88.83, PrinPaid: 87.96, IntPaid: 0.88
Of course looking at the results printed to 6 digits it's easy to see why this is happening:
MonthlyPay: 88.834637, PrincPaid: 87.955087, IntPaid: 0.879551
What's the best way to handle a situation like this?
What do financial institutions do?
There is no standard.
There are those who say, "Once you round, use the rounded value for all further totals."
There are others who disagree, saying that you should sum the unrounded values to avoid accumulated rounding error. For example, 0.0666 + 0.0666 + 0.0666 + ... 15 times should approximately equal 1.0000, but if rounding each term to 2 decimal places before summing, ends up being 0.07 * 15 = 1.05! So that's the argument for using unrounded values. Your off-by-one is only off-by-one because you have just two terms you're summing.
I think ultimately you have to consider the pros and cons of each method. Who would be interested in the rounding errors? Just the programmers? Accounting? Customers? How does it affect those people? And can you issue a statement that clears the ambiguity, like "Values displayed to 2 decimal places." in which case you don't round anything at all, but simply display the first two decimal places everywhere.
Don't round in your calculations. Round only when displaying to end users.
The displayed values might be off by a cent here or there (maybe, but I doubt it). But if you round in your calculations, you'll end up with either total underreporting interest paid and overreporting principal paid, or vice versa.
If you don't round, your calculations will be correct enough that they won't make 1 cent of a difference unless you do massive loan values.
A friend of mine discovered a really weird thing in MS Excel. Excel rounds down some specific numbers the wrong way, actually it rounds down a number that shouldn't need rounding.
As far as I have tested, it happens in most versions of MS Excel 2007+
Eg. the number 10358.165790 will be rounded down to 10358.1657899999.
Apparently it only happens in this interval: 8192.165790 - 65535.165790.
It is really weird - it doesn't happen with eg. .165890 or .165690, only with .165790.
Do any of you know why this happens and why it only accounts to certain numbers?
Excel uses an IEEE754 64 bit double precision floating point type to represent numeric data; with some clever formatting and roundup tricks to get sums like 1/3 + 1/3 + 1/3 correct.
What you are observing is a natural consequence of that numeric scheme only being accurate to 15 significant figures. Unless the number happens to be a dyadic rational, in which case it can be stored exactly, the closest representable number is chosen to the one you actually want. This may be below or above a rounding cutoff.
It will occur in other ranges other than the one you cite too.
I am trying to round up decimals to specific values in the following way:
1. 12.12 ---> 12.25
2. 12.5 ---> 12.5
3. 12.59 ---> 12.75
4. 12.75 ---> 12.75
5. 12.77 ---> 13
So they should be rounded up to the decimals .25, .5 and .75 or integer.
Is there an Excel function which can do this?
Please try:
=ROUNDUP(4*A1,0)/4
Your question uses positive numbers for sample data but there is a primary difference involving how negative numbers are handled by the CEILING function and the ROUNDUP function that should be mentioned.
This has to do with the way that ROUNDUP rounds away from zero and CEILING rounds to the numerically larger¹ number
The formulas in C2:D2 are:
=CEILING(A2, 0.25) ◄ C2
=ROUNDUP(A2*4, 0)/4 ◄ D2
Note the differences in the 7th, 9th and 11th rows. This is the difference in how the two functions handle rounding negative numbers. If you wanted the results in column C to follow the values in column D, you would have to use the following for negative numbers.
=CEILING(A2, -0.25) ◄ C2
But that doesn't work properly on positive numbers. While you could write a conditional statement that changed the sign of the significance parameter, it's a lot easier to choose what you want to happen with negative numbers and use either CEILING or ROUNDUP as the case may be.
¹If you get several mathematicians in a room and ask them if -1 is higher, larger or greater than -2, you will start World War III so I'm not going down that rabbit hole. The differences between CEILING and ROUNDUP are probably intended to cover both sides of the argument.
All of this can be related to the ROUNDDOWN function and the FLOOR function as well.
If you are only rounding to a fractional significance and not rounding in one direction or another, the MROUND function is another possibility.
I need to convert floats into numbers that resemble measurements from a ruler. For example: 3.75 needs to be converted into 3 and 3/4. However, this is harder than it would seem at first, because I need to keep the denominator in a form that is easily translated into a ruler measurement by a human. Essentially, the denominator should only be powers of 2, up to 16. I don't want a fraction like 3/5 because 5'ths aren't marked on a ruler. I have figured out how to limit the denominator from going above 16, but I can't figure out how to keep the denominator a power of 2.
Answers in python or c++ is preferred.
extract integer part, so you have fraction part less than 1.
find nearest 16th of fraction: multiply by 16 and round to nearest integer. Have some policy to break ties (e.g. round to even). I believe this step can't introduce floating point arithmetic error because you are multiplying by a power of 2.
reduce n/16 to lowest terms (cancel out common multiples of 2). I guess you need to compute the greatest common divisor. In Python that's fractions.gcd, dunno about C++.
I did what Jhecht said because it seemed easy to do with python dictionary.