Please take my apologies for the harsh words in my previous email. I will try to get a better explanation.
There is a funny saying, like: "Bullshit in, Bullshit Out". This is what happens with sin(). If the number you provide to the function is not accurate, and the precision is less than pi/2, then you end with a bogus output. The math library may provide 10,000 digits of precision, but all 10,000 digits are wrong. I made the following small experiment: ASSUMPTIONS: PI = 3; PI/2 = 1 [this is to avoid any errors due to floating point] 1) Open Calc 2) enter in A1: =3*10^16 3) enter in A2: =3*10^16 + 1 4) copy A1:A2 and paste as value in B1:B2 5) calculate the difference between B2 and B1, e.g. in cell B3: = B2 - B1 6) Voila, the result is 0 !!! So, Calc cannot differentiate between 3*10^16 and 3*10^16+1. But, the correct result in infinite precision would be: sin(3*10^16) = sin(pi * 10^16) = 0 sin(3*10^16 + 1) = sin(pi * 10^16 + pi/2) = 1 [we assumed pi to be 3 and pi/2 to be 1] However, Calc will compute: [reasoning done in our mind, not actual computations] sin(3*10^16) = sin(3*10^16 + 1) = 0!!! Because Calc sees both 3*10^16 and 3*10^16 + 1 as the same number. So, the math library may be accurate to the infinith digit, the result would be nevertheless wrong, because we provided the wrong number to sin(), and so the math library is not able to compute anything accurate out of the wrong input. We did not provide 3*10^16 + 1, but only 3*10^16, because Calc doe not know of 3*10^16 + 1. It does not know this number. This is a major problem with sin(), because the sine function is not monotonic, unlike other functions., and therefore we have BIG differences between numbers like 3*10^16 + 1 and 3*10^16, and those differences may be in any direction. So, lets get back to my earlier mails. In order to get sin() accurate to the 6th digit, we need to have the input precise to the 6th decimal digit. Because Calc stores numbers with 16 decimal digits, this means that the biggest number that retains a precision of 6 decimal points is 10^9 - 10^10. [16 digits is equivalent to 64 bits] So, in order to get an accurate sine from a number of the order of magnitude of 10^18, I still need 6 decimal places, so we actually need a precision of 24 digits, or ~24*4= ~96 bits (clearly more than 64 bits). I am sure, Calc does NOT store numbers as 96-bit values. I hope this explanation is better than my previous one. I get the feeling otherwise that my posts resemble more and more the dead parrot sketch. Sincerely, Leonard Mada > Betreff: Re: [sc-dev] constraint of x in sin(x) in scaddins > Dear Regina, > > It is completely irrelevant how accurate the implementation is. > > > The problem is that: > sin(10000000000000000) = a very accurate number > sin(10000000000000000 + pi) = (-1) * (the very accurate number from above) > > The difference between those 2 numbers is only pi! > BUT: > pi might be too small with those BIG numbers! > If Calc aproximates 10000000000000000 + pi as 10000000000000000, > because it cannot store (10000000000000000 + pi) to the relevant > digit, then you get bullshit and sinus cannot be computed accurately. > > Lets give another example: > sin(10^16 * pi) = 0 > sin(10^16 * pi + pi/2) = +1 > > However, if the accuracy of storing 10^16 * pi + pi/2 is less than pi/2, > then the actual computed result will be anything between -1 and +1, > without any resemblance to the truth. And it does NOT depend > on the accuracy of the math library. It depends on how Calc stores > the number: 10^16 * pi + pi/2. > > How many decimals are sotred? > If it is inaccurate even to the first decimal or, even worse, > the first digit (pi/2 ~ 1.57), then it does NOT make sense > to compute the sinus of it. > > I hope this explains why there must be an upper limit (unlike > monotone functions, where the value is continuously changing > in a single direction, sinus is not a monotone function). > > Sincerely, > > Leonard Mada > > > > -------- Original-Nachricht -------- > > Datum: Sun, 09 May 2010 18:07:22 +0200 > > Von: Regina Henschel <[email protected]> > > An: [email protected] > > Betreff: Re: [sc-dev] constraint of x in sin(x) in scaddins > > > Hi Leonard, > > > > it seems, that I have not been clear enough. sin() is a function in the > > math library of C and C++ compilers and is nowadays accurate in double > > precision up to x<2^64. To prevent larger arguments the special > > implementation ::rtl::math::sin() is used in OOo. But inside the > > implementation of IMSIN() in the module scaddins a constraint > > "x<134217728" is used. I only want to know, why this has been > > introduced. I doubt, that this restriction is still necessary. > > > > I know, that a lot of binary values give different results for sin(), > > although they are shown with the same decimal values in 15 digit > > precision (the highest precision Calc UI has). But that is not central > > point of my question. > > > > kind regards > > Regina > > > > > > Leonard Mada schrieb: > > > Dear Regina, > > > > > > I believe that sin() should have as constraint the largest float > > > (or integer) that fulfills the following condition: > > > sin(max) = correct result + epsilon > > > sin(max + lambda) = correct result + epsilon , > > > where lambda is a float in the interval (0, pi/2). > > > > > > Let me explain this a little bit. > > > > > > sin: [any float] -> [-1, 1] > > > > > > sin(pi/2) = 1 > > > sin(pi/2 + pi/2) = 0 > > > > > > So basically, if we want to compute sin() at some precision, > > > we have to guarantee that the number we compute the sinus of, > > > can be accurately represented. Else, we risk a total fiasco, because > > > sin(a_very_big_number) may correspond to any value in [-1, +1], > > > as the last digits in a_very_big_number are not accurate. > > > > > > So, big_number +/- pi/2 may be represented as big_number, > > > although the sinus would have different signs for those > > > "theoretically" different numbers. > > > > > > Therefore, the number which still makes sense to compute the sinus > off, > > > should fulfill the requirements set above. > > > > > > We still need to determine what values lambda and epsilon take, > > > but I hope that the general idea is clear. > > > > > > Basically, this also depends on the implementation of general numbers > > > in the particular software (Calc in this example). > > > > > > Some may store 16 decimal digits, so 1.xxx * 10^16 is still ok > > > to compute the sin() (or marginally so), some may store 32 digits, > > > so 1.xxx * 10^32 would be fine in that case. > > > > > > I believe that lambda should be not bigger than pi/4, > > > while epsilon is flexible in this case (e.g. 10^-6 is probably > > > sufficient). > > > > > > Sincerely, > > > > > > Leonard Mada > > > > > > > > > > > > -------- Original-Nachricht -------- > > >> Datum: Sat, 08 May 2010 21:02:45 +0200 > > >> Von: Regina Henschel<[email protected]> > > >> An: Calc dev<[email protected]> > > >> Betreff: [sc-dev] constraint of x in sin(x) in scaddins > > > > > >> Hi all, > > >> > > >> I have notice a constraint "SinOverflow" (which is x>=134217728) in > > >> analysishelper.cxx in scaddins. What is the special reason for it? > > >> > > >> In other places with sin() the version ::rt::math::sin() is used to > get > > >> a guard for overflow. That would result in constraint > > >> x<=9,22337203685478E+018, which is much larger. > > >> > > >> If there is no special reason, should I replace it, while I work on > the > > >> missing complex trigonometric functions? > > >> > > >> kind regards > > >> Regina > > >> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: [email protected] > > >> For additional commands, e-mail: [email protected] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > -- > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
