mm-406
===
Subject: Mathcad QuickSheet Problem
I have Mathcad 2001.  When I am using the Help system, and try to
access Quick Sheets, I get an error message: A run-time error has
occurred, do you wish to debug?  When I go to the debugger, the
following code is highlighted:
<script LANGUAGE=VBScript><!--
Sub LaunchQS_OnClick()
  objLaunchMathcad.OpenResourceCenter(mo70vfu.mcd)
End Sub
In particular, the middle line, objLaunchMatthcad.Open... is
highlighted.  Can anyone tell me what the problem is, and how to fix
it, so I can open the Quick Sheets?
Steve O.
Steven AATT Domain DDOOTT com
To send an e-mail, substitute @ for AATT, a . for DDOOTT, and OpComm for 
Domain
Standard Antiflame Disclaimer:  Please don't flame me.  I may actually *be* 

an idiot, but even idiots have feelings.
===
Subject: Re: Mathcad QuickSheet Problem
 Can anyone tell me what the problem is, and how to fix
 it, so I can open the Quick Sheets?
sorry, I haven't a clue...but MathCad has a (rather cumbersome) web-
based forum in which I've frequently gotten answers to questions like 
yours...try http://www.mathcad.com/community/Collaboratory.asp
standard disclaimers: FWIW & YMMV  :^D
____________
Visit the Numerical Methods in Pascal web page at
http://www-rab.larc.nasa.gov/nmp/fNMPhome.htm
===
Subject: Re: Averaging quaternions
 I've finally realized that all I contributed was questions and complaints
 and no alternative solutions.
 If I were doing this, I would probably convert the quaternions to Euler 
(or
 Bryant) angles first (convert the quaternion to a direction cosine 
matrix,
 then extract the Euler angles).  Then, I would compute the average of the
 Euler angles, and then convert the resulting average Euler angles back to 
a
 quaternion (convert the Euler angles to a direction cosine matrix, then
 extract the quaternion).
This has exactly the same problems as averaging over quaternions, since
angles are only unique up to a multiple of pi or 2pi; so the average
depends on whether you represent an angle by a number close to pi or
close to -pi ...
===
Subject: Re: Averaging quaternions
> I've finally realized that all I contributed was questions and
complaints
> and no alternative solutions.
> If I were doing this, I would probably convert the quaternions to Euler
(or
> Bryant) angles first (convert the quaternion to a direction cosine
matrix,
> then extract the Euler angles).  Then, I would compute the average of
the
> Euler angles, and then convert the resulting average Euler angles back
to a
> quaternion (convert the Euler angles to a direction cosine matrix, then
> extract the quaternion).
 This has exactly the same problems as averaging over quaternions, since
 angles are only unique up to a multiple of pi or 2pi; so the average
 depends on whether you represent an angle by a number close to pi or
 close to -pi ...
 Arnold Neumaier
Uniqueness of the Euler angles is not the issue, it's more an issue of
continuity of the angles.  Euler angles do not have the same problems 
as
averaging over quaternions.  My basic beef with averaging quaternions is
that the initial result of the average is not a quaternion (i.e., the 
result
does not have unit norm).  Euler angles do not suffer from such a
complication.
If all the OP is doing is trying to find the average attitude over some
fairly small period of time, then one might expect the Euler angles
corresponding to the quaternion samples to fairly continuous.  Admittedly,
if the quaternions are completely independent of one another, then  such a
continuity argument will fail.  But then, what would be the purpose of
finding an average attitude for quaternions that are randomly 
distributed?
I agree (and my post gave fair warning) that with Euler angles one has to 
be
careful of choosing sequences near the singularity  of the sequence.  The
problem you raise is essentially equivalent to that case - if you are near
the singularity for the sequence, then you can expect large discontinuities
in the extracted Euler angles.  A quick plot of the Euler angles can help
identify if the selected Euler (or Bryant) sequence is a good one.  In
general, it usually isn't that hard to avoid the singularity, particularly
if you have an understanding of the underlying process that generated the
quaternions in the first place.
John
===
Subject: Re: Averaging quaternions
>>I would compute the average of the
>>Euler angles, and then convert the resulting average Euler angles back to 

a
>>quaternion (convert the Euler angles to a direction cosine matrix, then
>>extract the quaternion).
>This has exactly the same problems as averaging over quaternions, since
>angles are only unique up to a multiple of pi or 2pi; so the average
>depends on whether you represent an angle by a number close to pi or
>close to -pi ...
>Arnold Neumaier
Uniqueness of the Euler angles is not the issue, it's more an issue 
of
 continuity of the angles.  Euler angles do not have the same problems 
as
 averaging over quaternions.  My basic beef with averaging quaternions is
 that the initial result of the average is not a quaternion (i.e., the 
result
 does not have unit norm).  Euler angles do not suffer from such a
 complication.
The real part of a unit quaternion (with nonnegative real part)
is redundant in that it can be recomputed from the imaginary part.
Thus averaging the imaginary parts and recomputing the real part
would be a simpler recipe of the same kind as yours with Euler angles.
And it would have exactly the same problems as the avarage-and-scale
method, although there are no asingularities. It is a matter of
non-uniqueness in both cases, which implies that one must make ad hoc
normalizations: A choice of sign in the quaternion case, and a choice
of some normalization interval in the Euler case. This cannot be
done without introducing discontinuities - these are not present
in the mathematics but only in the normalization chosen.
 If all the OP is doing is trying to find the average attitude over some
 fairly small period of time, then one might expect the Euler angles
 corresponding to the quaternion samples to fairly continuous.  
Not if one of the angle is just a little less than pi and increasing
beyond pi (suddenly becoming -pi)
 I agree (and my post gave fair warning) that with Euler angles one has to 
be
 careful of choosing sequences near the singularity  of the sequence.  
AND near the normalization bounds! The average-and-scale technique is
thus even better since it has no singularities and only the
problem with possible discontinuities in the representation.
===
Subject: Re: Computationally cheap sin/acos approximations
 Can anyone suggest *fast* approximations to sin and acos?
 I'm currently using a fiddled Taylor series for sin. Worst-case error
 is around 0.00038, and it requires 8 multiples and 4 adds.
 My acos uses 5 multiples, 5 adds and a square-root, and has a
 worst-case error of around 0.00087 radians. It's a weighted sum of a
 1, X and root(1-x^2).
 Can anyone suggest more accurate approaches? These need to run on a
 videogame console with a pretty weak CPU, so they can't be much more
 expensive than the ones I'm using. Very roughly speaking, multiply and
 add have a cost of 1, and square-roots and divides have a cost of 3.
 Any advice or pointers in the right direction would be much
 appreciated.
========
[Method 1]. In order to approximate SIN(x) for x in [-pi,pi], try to find
the coefficients A_k from the development [Schur's series]
  SIN(x)=SUM_{k=1 to k=infty}A_k*y^k  with y=x(pi-x) .
 It seems that
  A_1= 1/pi  , A_2=1/pi^3   , A_3=(12-pi)/(6*pi^5) , .... .
 Therefore
 (1)  SIN(x)=approx=A_1*y +A_1*y^2 +A_3*y^3    , |x|=< pi .
 [Method 2].
 Let  a_0=0.864864         b_0=1.297296
      a_2=0.898128         b_2=0.37422
      a_4=0.10206          b_4=0.0183708
      a_6=0.0020412        b_6=0.00010935
and denote y=y(x)=x/3 ,
  A=A(x)= a_0 -a_2*y +a_4*y^2 -a_6*y^6 ,
  B=B(x)=y*(b_0 -b_2*y +b_4*y^2 -b_6*y^6).
If it's possible, for |x| =< pi consider the approximations
                        2*A*B
(2)     SIN(x)=approx= ----------      .
                       A^2 + B^2 
================================================================
To approximate ACOS , consider
(3)  ACOS(x)=approx=E_j(x)*sqrt(1-x), x in (0,1),j in {1,2,3},
where
   E_1(x)=c_0 +c_1*x+c_2*x^2 +c_3*x^3
   E_2(x)=d_0 +d_1*x+d_2*x^2 +d_3*x^3 +d_4x^4   
   E_3(x)=e_0 +e_1*x+e_2*x^2 +e_3*x^3 +e_4x^4 +e_5*x^5 ,   
with 
c_0=  1.5707288            d_0=  1.57078786   e_0=  1.570795207
c_1=- 0.2121144            d_1=- 0.21412453   e_1=- 0.214512362 
c_2=  0.0742610            d_2=  0.08466649   e_2=  0.087876311 
c_3=- 0.0187293            d_3=- 0.03575663   e_3=- 0.044958884
                           d_4=  0.00864884   e_4=  0.019349939  
                                              e_5=- 0.004337769
see pp.159-163 from  C.Hastings, J.T.Hayward and  J.P.Wong ,
    ,,Approximations for digital computers,
 Princeton Univ.Press,Princeton 1955,pp.159-163.
In fact 
       ACOS(x)=arccos(x)=
=(2+SUM_{k=1 to k=infty}T(k)*(1-x)^k )*sqrt((1-x)/2)  ,  |x|<1 ,
where
        C(2k,k)
T(k)= ----------    , C(n,k):= n!/(k!(n-k)!) .
      (k+0.5)*8^k 
=================
===
Subject: Re: Computationally cheap sin/acos approximations
 To approximate ACOS , consider
 (3)  ACOS(x)=approx=E_j(x)*sqrt(1-x), x in (0,1),j in {1,2,3},
Yes, that's already been considered in this thread. It seems, Alex, that
you haven't been paying attention. See below.
 where
    E_1(x)=c_0 +c_1*x+c_2*x^2 +c_3*x^3
    E_2(x)=d_0 +d_1*x+d_2*x^2 +d_3*x^3 +d_4x^4
    E_3(x)=e_0 +e_1*x+e_2*x^2 +e_3*x^3 +e_4x^4 +e_5*x^5 ,
 with
 c_0=  1.5707288            d_0=  1.57078786   e_0=  1.570795207
 c_1=- 0.2121144            d_1=- 0.21412453   e_1=- 0.214512362
 c_2=  0.0742610            d_2=  0.08466649   e_2=  0.087876311
 c_3=- 0.0187293            d_3=- 0.03575663   e_3=- 0.044958884
                            d_4=  0.00864884   e_4=  0.019349939
                                               e_5=- 0.004337769
The c_i are suboptimal. That is, if one wishes to approximate Acos(x)
on [0,1] by Sqrt(1-x)*(cubic polynomial in x) so as to minimize max|error|,
then the c_i you have quoted are incorrect. Look at my previous posts in
this thread. Using the c_i you quoted, we get |error| of about 6.8*10^(-5)
at x = 0; using the coefficients I derived, we have |error| < 4.5*10^(-5).
And my cubic is surely (at least slightly) suboptimal itself.
Although I have not examined the cases involving quartic and quintic
polynomials, I'd be willing to bet that the d_i and e_i which you quoted
above are similarly suboptimal.
 see pp.159-163 from  C.Hastings, J.T.Hayward and  J.P.Wong ,
     ,,Approximations for digital computers,
  Princeton Univ.Press,Princeton 1955,pp.159-163.
Yes, this is the source of 4.4.45 and .46 in Abramowitz and Stegun.
Unfortunately, if the objective of Hastngs et al. was -- as it surely seems
to have been -- to minimize max|error| over the stated domain, then their
coefficients were derived using an idea which was fundamentally flawed.
David Cantrell
===
Subject: Re: Computationally cheap sin/acos approximations
PS: The longer asin approximation in A&S 4.4.46 also appears to slightly
exceed it's claimed max error.
>Can anyone suggest *fast* approximations to sin and acos?
> Over what domains should the approximations work? How about [0, pi/2]
> for sin(x) and [0, 1] for acos(x)?
 Also, just to make sure, am I right to think that you wish to 
minimize
> the maximum of |absolute error|, rather than |relative error|?
> Phew! I was using the range [-pi,pi] for sin(x), but I just 
recalculated
> by coefficients for [0,pi/2] and the error dropped to 0.00001, which is
> definitely good enough.
> Acos is still a problem though...domain [0,1] is fine, and yes, I am
> looking to minimise |absolute error|.
 Of most interest, I seem to have discovered an error in Abramowitz and
 Stegun. But I find that difficult to believe. It's more likely that _I_
 made a mistake. Please see below.
 Pierre's suggestion was good, but I suspect that approximating Acos(x) by
 Sqrt(1-x)*(polynomial in x) works better here. Using a cubic polynomial, 
I
 obtained the following approximation for Acos(x) when 0 <= x <= 1:
   Sqrt(1-x)*(a + x*(b + x*(c + x*d)))
   with a = pi/2, b = -0.213300989, c = 0.077980478, and d = -0.02164095 .
 This approximation is computationally less expensive that the one you had
 been using, and it has |error| < 0.000045 .
 After having done the above, I thought to myself This is still not
 optimal. Let me see what Abramowitz and Stegun have. Not surprisingly,
 their 4.4.45 (on p. 81)
 <http://jove.prohosting.com/~skripty/page_81.htm>
 gives a similar approximation, with the claim that |error| < 0.00005 . 
But
 I was not able to verify that claim. Rather, it seems clear to me that
 their |error| reaches a maximum of approximately 0.000068 when x = 0. So
is
 there a mistake in 4.4.45 of A&S, or did I make a mistake somehow?
 BTW, I still think that my approximation above is not optimal for the 
form
 Sqrt(1-x)*(cubic polynomial in x), that is, unless one insists that error
 must be 0 when x = 0. Probably, by slightly changing a from pi/2, an
 approximation with slightly smaller max|error| could be obtained.
 David Cantrell
===
Subject: Re: Computationally cheap sin/acos approximations
 PS: The longer asin approximation in A&S 4.4.46 also appears to slightly
 exceed it's claimed max error.
Slightly, yes. It should be about 2.18*10^(-8), while they give 2*10^(-8).
But I suppose it could be argued that their claim here is correct in 
that
they gave only one significant digit.
I have now looked more carefully at 4.4.45 and .46 in A&S, and I am shocked
at what I found. The polynomials which are given are optimal, but for the
wrong thing! They do indeed minimize max|error| for a polynomial
approximating Acos(x)/Sqrt(1-x). But if one then multiplies the polynomials
so obtained by Sqrt(1-x), the result is _not_ optimal for approximating
Acos(x). [Example: The cubic polynomial case which I worked out earlier
demonstrates the suboptimality of A&S 4.4.45 for its intended purpose. But
OTOH, if one wished instead to approximate Acos(x)/Sqrt(1-x) by a cubic
polynomial, then their polynomial is optimal.]
It's surprising that these results in such a venerable work as Abramowitz
and Stegun have never been corrected. But what really shocks me is that
they are based on a conceptual misunderstanding!
Hmm. What does one do with newly discovered errata for A&S now?
David Cantrell
>> Can anyone suggest *fast* approximations to sin and acos?
Over what domains should the approximations work? How about [0,
>pi/2] for sin(x) and [0, 1] for acos(x)?
> Also, just to make sure, am I right to think that you wish to
>minimize the maximum of |absolute error|, rather than |relative
>error|?
 Phew! I was using the range [-pi,pi] for sin(x), but I just
> recalculated by coefficients for [0,pi/2] and the error dropped to
> 0.00001, which is definitely good enough.
 Acos is still a problem though...domain [0,1] is fine, and yes, I am
> looking to minimise |absolute error|.
> Of most interest, I seem to have discovered an error in Abramowitz and
> Stegun. But I find that difficult to believe. It's more likely that _I_
> made a mistake. Please see below.
> Pierre's suggestion was good, but I suspect that approximating Acos(x)
> by Sqrt(1-x)*(polynomial in x) works better here. Using a cubic
> polynomial, I obtained the following approximation for Acos(x) when 0
> <= x <= 1:
>   Sqrt(1-x)*(a + x*(b + x*(c + x*d)))
>   with a = pi/2, b = -0.213300989, c = 0.077980478, and d = -0.02164095
> This approximation is computationally less expensive that the one you
> had been using, and it has |error| < 0.000045 .
> After having done the above, I thought to myself This is still not
> optimal. Let me see what Abramowitz and Stegun have. Not 
surprisingly,
> their 4.4.45 (on p. 81)
> <http://jove.prohosting.com/~skripty/page_81.htm gives a similar approximation, with the claim that |error| < 0.00005 .
> But I was not able to verify that claim. Rather, it seems clear to me
> that their |error| reaches a maximum of approximately 0.000068 when x =
> 0. So
 is
> there a mistake in 4.4.45 of A&S, or did I make a mistake somehow?
> BTW, I still think that my approximation above is not optimal for the
> form Sqrt(1-x)*(cubic polynomial in x), that is, unless one insists
> that error must be 0 when x = 0. Probably, by slightly changing a from
> pi/2, an approximation with slightly smaller max|error| could be
> obtained.
===
Subject: Re: Why mcc compiled windows exe is 20 times slower than m-files??
  I have a matlab code that does a lot of matrix operations, things
 like A.*B.*C etc. in the main loop. 
Do your matrices have some specific sparsity structure?
===
Subject: Re: Why mcc compiled windows exe is 20 times slower than m-files??
  I tried MSVC and lcc. Both with similar results. I also found a few
older postings talking about similar symptom. It seems that these
matlab to C compilers don't take as much care in optimizing the code
as matlab itself.
  Some postings said Falcon from UIUC generates faster code. But I
cannot find the software anywhere. Some said Matcom compiler is
better, but that is not on the market anymore either.
 mcc is the Matlab function that takes a relatively arbitrary Matlab .m 
 script or function (there are constraints) and turns it into an 
 executable. Usually this greatly improves the execution time of the 
script.
 Different compilers can be used by mcc to generate the executable, 
 including VC++, lcc (provided by Mathworks with matlab), gcc (*nix only) 
 and some Fortran compilers.
 Luigi didn't specify which compiler he is using so I'm guessing it is 
 the default lcc compiler.
> What is this mcc compiler?
> Is there any way to see what executable it is?
luigi <lchian@yahoo.com> a .8ecrit dans le message de
>  I have a matlab code that does a lot of matrix operations, things
>>like A.*B.*C etc. in the main loop.
>  The Windows EXE compiled with mcc runs 20 times SLOWER than the
>>m-file script. I used default options for mcc and mbuild, which
>>according to ther manual, has all optimizations turned on.
>  Is this specific to the mcc compiler? Is there something I can do to
>>speed it up?
>