Re: linalg[leastsqrs] in Maple V R4

Thanks Prof. Israel.

I won't burden the group with a message filled with hundreds of decimal
digits. I will do some more tests and get back to you. In the meantime,
I do hav a work around--I set digits rather high. In my particular
case, I am estimating the coefficients in a rational approximation
problem, so I need a good degree of decimal precision in my results.

Here is an abridgement of what I am getting now. u is a 72 by 9 matrix,
bb is a 72 element vector:

Digits: = 50:
<snip out lots of other stuff>
linalg[leastsqrs](u,bb):
linalg[leastsqrs](u,bb):
"-"";

The last command produces a 9 element vector of differences ranging
between about 4E-42 to 1E-45. That is what amazes me--why would the
leastsqrs routine differ in the last 5 to 9 significant digits in two
CONSECUTIVE calculations of the exact same thing? And which one, if
either, is "right"? When the matrix is bigger (136 x 17), the exact
same thing with Digits at 50 produces a difference vector with 17
elements ranging between 3E-25 and 6E-37, so there is discrepancy in
the last 13 to 25 digits at least in consecutive calculations. Are
there many potential solutions that differ only in the last several
decimal digits, and Maple converges to one or the other in consecutive
performances of the exact same computation? That strikes me as somewhat
random.

Since I know this happens, I will just be sure to set Digits to a lot
more than what I need. On my machine Maple seems very fast for problems
of this size so this is no hardship. In the meantime, I will see if
Svd() and manual computation of leastsquares solutions yields more
reproducible results.

In the meantime, I am grateful for ongoing comments and wisdom.

Les


Robert Israel wrote:
In article <1154264326.861799.211040@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
lcw1964 <leslie.wright@xxxxxxxxxxxxx> wrote:
I know that I am using an admittedly ancient version of the software,
but it suits my modest personal purposes for the most part.

I am wondering if anyone has has any experience with the leastsqrs
procedure, in either older or newer incarnations, only to discover that
it seems painfully inaccurate on repeat application.

I have tried to use linalg[leastsqrs] to find the least squares
solution of an fairly hefty sized overdetermined system, about 80
equatons in 16 unknowns. Repeat application on the exact same
matrix/vector input combination yields different results with the loss
of many if not most of the significant digits. I am not talking just a
few digits lost to accumulated rounding error, I am talking a couple of
dozen digits when Digits is set pretty high. The problem gets worse the
larger the linear system is, and using the 'optimize' argument seems to
slow things down and doesn' add any value.

This is driving me wonky. Is this a bug or a feature? Is it present in
newer versions of Maple? Would I be better off using Svd() and
computing the least squares solution myself from that output? I really
don't mind "black box" routines if they give reproducible results, and
linalg[leastsqrs] in my hands does not.

The LinearAlgebra package in more recent versions of Maple should be
quite a bit better than linalg at most number-crunching applications.
But I didn't see any significant difference between linalg[leastsqrs]
and LinearAlgebra[LeastSquares] on a random 80 x 16 problem. Could
you provide a specific example of the problem you're experiencing?

Robert Israel israel@xxxxxxxxxxx
Department of Mathematics http://www.math.ubc.ca/~israel
University of British Columbia Vancouver, BC, Canada

.

Relevant Pages

  • Re: controversial paper
    ... I need only specify a location (the zero ... bits that differ. ... regions to the network (add more digits on the right). ...
    (sci.crypt)
  • Re: Is continuum completely filled up?
    ... then they differ in some finite position. ... which means it has a nonzero digit in some finite position. ... until its all digits are shown. ... even without knowing all the digits of pi. ...
    (sci.math)
  • Re: Syntax across languages
    ... >> the number of digits to be considered significant in doing an FP ... differ by at most 1 part in 10^5", ... *really* don't want to specify the acceptable difference ... The latter is what number of significant digits gives ...
    (comp.lang.python)
  • Re: Serial Number on 50g
    ... contain 8 digits. ... I'm thinking they all start with "CNA" anymore. ... Mine differ by 1,2 and 21 weeks. ... and 21 weeks on a 49g+ with a lousy keyboard. ...
    (comp.sys.hp48)
  • Re: Sum of a series ?
    ... |> My aim is to find /if possible/ the sum of the series with many exact ... According to Maple: ... Enough digits for you? ...
    (sci.math)