- To: mathgroup at smc.vnet.net
- Subject: [mg112331] Re: FindRoots?
- From: "Ingolf Dahl" <ingolf.dahl at telia.com>
- Date: Thu, 9 Sep 2010 05:31:10 -0400 (EDT)
To Andrzej Kozlowski and MathGroup,
Yes, I was too harsh in using the word "snobbery". But I feel that it is not
good to let the best (the Semenov method?) be an enemy of the good
(RootSearch), when the Semenov method not yet is fully implemented. You have
argued for the capabilities of Reduce to find zeroes, so I wonder of course
if a routine based on the Semenov method would fail in a similar way. So
much better if it does not. Maybe we should ask MathGroup, if there is
anyone willing to implement your demonstrations as a more general package?
The code does not look too difficult, even if I not immediate gasp all
details (I usually don't). And as usual, the hell might be in the details.
However, in order to implement the Semenov method and to obtain provable
results, you state that there are "certain mild conditions" that must be
fulfilled. These conditions seem to be that the program needs to obtain
explicit and valid upper bounds for the first and second derivatives. The
task to find these bounds cannot be automated in a provable way in the
general case, so one problem has effectively been replaced by another. One
could put the responsibility to solve this second problem on the user, but I
cannot see such a solution as superior. Nevertheless, there seems to be
niches where the Semenov method might be very useful, especially in the
multidimensional case, so it should be worth the effort to create a full
implementation. I doubt that such an implementation will be option-free -
would it not be nice to have an "Automatic" way of estimating the bounds of
the derivatives? But then some roots might be missed.
> -----Original Message-----
> From: Andrzej Kozlowski [mailto:akozlowski at gmail.com]
> Sent: den 8 september 2010 06:59
> To: mathgroup at smc.vnet.net
> Subject: [mg112299] Re: FindRoots?
> On 7 Sep 2010, at 18:40, Andrzej Kozlowski wrote:
> > On 7 Sep 2010, at 10:02, Ingolf Dahl wrote:
> >> But anyway, I consider it as snobbery to say that Reduce is superior to
> >> RootSearch. They do not play in the same division, and perform
> >> tasks.
> > Why should it matter to me what you call it? Is that an argument?
> > If you read what I have written on this subject you may noticed that
there are ways to do
> essentially the same things that RootSearch attempts to do and obtain the
complete set of
> roots (provably complete) (I am not referring to using Reduce). That, I
do call "superior"
> and really I don't care if anyone thinks it's "snobbery" or not.
> > Andrzej Kozlowski
> In case my meaning is still unclear, I will once again repeat something
that I have written
> already on this forum several times on various occasions.
> If Wolfram really wanted a method that solves numerical transcendental
> could implement one of several existing sophisticated modern algorithms,
including the one
> due to Semenev (2007) that is the subject of my demonstrations:
> Unlike the SearchRoot package this algorithm finds the complete set of
solutions of any
> system of n equations in n unknowns satisfying certain mild conditions. I
have no problem
> at all calling it "superior" to what is implemented in the SearchRoot
package. Moreover, it
> can solve systems of equations (yes, systems) which Mathematica is at
present is unable
> even to attempt (one such example is given in the first demonstration
above) and neither of
> course can SearchRoot. The set of solutions is provably complete and the
user does not need
> to set any options.
> My implementation of Semenev's algorithm is probably inefficient as it was
only meant to
> demonstrate the method and not to be used in practice. Semenev's paper
> complexity estimates for the method which show that it is quite practical
if the number of
> equations (and unknowns) is not too large.
> It would be trivial for Wolfram to implement this algorithm and it would
not require leasing
> anything from anyone, with all the problems that this usual entails.
> Andrzej Kozlowski
Prev by Date:
Re: Collecting Positive and Negative Terms
Next by Date:
Re: locating overlow/underflow (and the issue of accuracy)
Previous by thread:
Next by thread: