Dear Regina, I had a second thought about this issue.
My comments are correct, though, lambda is dependent on epsilon. So, if we accept an epsilon of 10^-6, then we can get the lambda. e.g. lambda = arcsin(0.5) - arcsin(0.5-10^-6) lambda ~ 10^-6 radians So, virtually, the constraint on sin(max_number) is to have max_number with a precision of 6 decimals. This will guarantee a precision in sin(max_number) of 10^-6. [Please note, there is not quite a linear dependence between lambda and epsilon, but I think this approximation is OK.] So, the biggest number that the sinus makes sense is ~10^9 to 10^10. This number can be represented with enough precision (6 decimal places) to guarantee that sin() is accurate to its 6 decimal. If, on the other hand, we wish a greater precision for sin() [lets say 10^-12], then the max number is much smaller. Sincerely, Leonard Mada -------- Original-Nachricht -------- > Datum: Sat, 08 May 2010 23:18:50 +0200 > Von: "Leonard Mada" <[email protected]> > An: [email protected] > Betreff: Re: [sc-dev] constraint of x in sin(x) in scaddins > 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] > > -- > 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]
