Bug in Mathematica 6 - Integrate - 63 (Sqrt, regression bug)
Vladimir Bondarenko
An exact 1-D integration challenge - 48 -
(go and give a kick to all stupid CASs!)
----------------------------------------------------------------
N[Integrate[
Sqrt[Sqrt[2] + Sqrt[z] + Sqrt[2 + 2 Sqrt[2] Sqrt[z] + 2 z]],
{z, 0, 1}]]
----------------------------------------------------------------
VERSION OUTPUT RESOLUTION
----------------------------------------------------------------
Mathematica 6.0 2.67602 <-------------------------------- BUG
Mathematica 5.2 3.66533 <-------------------------------- BUG
Mathematica 4.2 Unevaluated integral
Mathematica 3.0 Unevaluated integral
----------------------------------------------------------------
Best wishes,
Vladimir Bondarenko
VM and GEMM architect
Co-founder, CEO, Mathematical Director
http://www.cybertester.com/ Cyber Tester, LLC
http://maple.bug-list.org/ Maple Bugs Encyclopaedia
http://www.CAS-testing.org/ CAS Testing
quasi
<v...@cybertester.com> wrote:
>----------------------------------------------------------------
>
>An exact 1-D integration challenge - 48 -
>(go and give a kick to all stupid CASs!)
>
>http://groups.google.com/group/sci.math.symbolic/browse_thread/thread/28416525f0de8f90/1d8cd83e96cb7f63?#1d8cd83e96cb7f63
>
>----------------------------------------------------------------
>
>N[Integrate[
>
> Sqrt[Sqrt[2] + Sqrt[z] + Sqrt[2 + 2 Sqrt[2] Sqrt[z] + 2 z]],
>
> {z, 0, 1}]]
>
>----------------------------------------------------------------
>VERSION OUTPUT RESOLUTION
>----------------------------------------------------------------
>
>Mathematica 6.0 2.67602 <-------------------------------- BUG
>
>Mathematica 5.2 3.66533 <-------------------------------- BUG
Let f(z) = sqrt(sqrt(2) + sqrt(z) + sqrt(2 + 2*sqrt(2)*sqrt(z) + 2*z))
Then it's completely obvious that f has domain [0,infinity) and that
is strictly increasing.
Hence the integral of f on the interval [0,1] must be strictly between
f(0) and f(1).
Approximately, we have
f(0) = 1.681792831
and
f(1) = 2.242172940
which makes it clear that Mathematica's outputs are ridiculous.
Maple 9.5 gives a result of 2.062759840, which at least seems
reasonable. Whether it's correct or not, I'm not sure.
quasi
quasi
A CAS should never return a wrong answer. Returning no answer is
better than a wrong one.
For this example in particular, Mathematica really has no excuse for
getting it wrong. It's not like the function has wild variations which
might throw off a numerical integration. This is a positive,
increasing function, easily evaluated. For a CAS, the numerical
integration of such a function should be effortless.
quasi
Axel Vogt
Finding a possible (numerical) error is only half the job
of a tester. I would expect him to locate it closer by
deforming the situation, easiest would be the bounds.
Then one could say something whether MMA is disturbed
by the vertical tangent in 0.
Changing z ---> t^2 should do it.
quasi
wrote:
I disagree -- a tester needs to find a reproducible bug -- period. An
instance is sufficient, the simpler, the better.
The fixers (on the Mathematica side) are the ones who need to
investigate further.
>I would expect him to locate it closer by deforming the situation,
>easiest would be the bounds.
I would expect that Mathematica should sense a possible problem and
deform the function and/or the bounds automatically, if needed.
>Then one could say something whether MMA is disturbed
>by the vertical tangent in 0.
If a vertical (or near vertical) tangent is an important consideration
for the internal algorithm, then the CAS implementation should
incorporate a way to automatically detect and deal with that
contingency.
>Changing z ---> t^2 should do it.
If the user gets an actual answer, why should the user have to check
to see if it's correct? Worse, if the integral is used as part of a
user-written program, the user doesn't even get to look at the answer
-- it just gets fed to the next piece of the program. Shouldn't a
supposed world-class CAS at least offer an option to automatically
verify/certify numerical calculations to within a specified accuracy?
quasi
David W. Cantrell
That's a result of a _numeric_ integration in Maple. Mathematica does that
easily also:
In[4]:= NIntegrate[
Sqrt[Sqrt[2] + Sqrt[z] + Sqrt[2 + 2 Sqrt[2] Sqrt[z] + 2 z]], {z, 0, 1}]
Out[4]= 2.06276
> >which at least seems
> >reasonable. Whether it's correct or not, I'm not sure.
> >
> >quasi
>
> A CAS should never return a wrong answer. Returning no answer is
> better than a wrong one.
True.
> For this example in particular, Mathematica really has no excuse for
> getting it wrong. It's not like the function has wild variations which
> might throw off a numerical integration. This is a positive,
> increasing function, easily evaluated. For a CAS, the numerical
> integration of such a function should be effortless.
And it _is_ for Mathematica in this case.
You are criticizing something without understanding what you are
criticizing! The error lies in Mathematica's _symbolic_ integration, not in
its subsequent numerical evaluation of that symbolic result.
A correct symbolic answer is easily obtained from Mathematica if you help
it by doing a substitution such as u for Sqrt[z]. One then gets, after
simplification,
(4/15)*Sqrt[4 + 11*Sqrt[2] + 2*Sqrt[226 + 127*Sqrt[2]]]
the numerical value of which agrees with the result of numerical
integration.
David
quasi
<DWCan...@sigmaxi.net> wrote:
Ok, I missed the fact that, for the original example, the command was
N[Integrate ...
rather than
NIntegrate ...
Hence if I criticized Mathematica unfairly, I apologize.
Still, a badly incorrect numerical answer was the final result, hence,
if embedded, perhaps mission-critical programs were to use such
results, the outcome could be scary.
quasi
Mariano Suárez-Alvarez
What'd be scary is to have someone blindly trusting the answers
from a huge, immensely complicated piece of software the internal
workings of which he has absolutely no knowledge and whose makers
themselves make no warrants other than the good quality of the
media it is distributed on and, in fact, recommend against the use
in critical situations.
Likewise, it's scary that people use Mathematica blindly for doing
their homework, actually.
-- m
Axel Vogt
We talk about commercial software development. And there seems to
be no complex and growing SW system, which is free of bugs.
Especially testing is not "found your error, so repair it", this
is only acceptable for a user doing tests, not a professional (by
this I do not want to insult Bondarenko, he does not get money or
s.th. close equivalent ... I guess).
For this there are several reasons, here are 2: the one who codes
does it because he can do that best, the other does something else.
You have a project with several hundred man years and have to share
tasks. It is not a question of sin and atonement - both sides are
supposed to do more then the obvious.
Usually that even is done in cascading, only "3rd level" begins to
care for errors.
Besides organizing work these are fairly complex systems and 'the'
error may not be due to some new lines of code, deeper testing is
a help on that and someone who refuses to contribute to that just
has the false job as a tester in quality assurance.
If you are aware that the whole system contains bugs the coder and
the tester are in a similar situation like you. Which conversely
tells you: there is no reason to trust your program, because it
depends on stuff of others.
For the other thing "automatically verify" ... well, the above will
apply as well, it will not give you a break off that vicious circle.
Axel Vogt
Yes, but it also shows, why a professional tester should *not* stop
at an error, but modify the situation
quasi
That assumes interactive use. For a user-written program, should the
programmer have to write code to double check returned values?
Moreover, why should the users have to do their own checks when the
CAS developers, as expert implementers and testers of algorithms,
could simply build such checks into the CAS, allowing the user an
option to toggle automatic consistency checking on or off.
>from a huge, immensely complicated
= immensely buggy?
(and if so, why so expensive?)
In any case, as already suggested, why doesn't the program check
_itself_ for types of calculations for which it is known to often be
wrong?
>piece of software the internal
>workings of which he has absolutely no knowledge and whose makers
>themselves make no warrants other than the good quality of the
>media it is distributed on and, in fact, recommend against the use
>in critical situations.
Sure, they want to limit their liability, but that doesn't take away
their obligation to strongly defend (within the CAS program itself)
against well known flaws. Given that the CAS developers _know_ that
certain calculations are often unreliable, it is _their_
responsibility to safeguard the user by building in consistency
checks.
>Likewise, it's scary that people use Mathematica blindly for doing
>their homework, actually.
Not that scary -- more of a shame. Then again, those same students
(assuming they graduate) get to possibly use such CAS programs in
real-world applications. Yep, could be scary after all.
quasi
Jaap Spies
> On Sat, 26 Jan 2008 08:26:32 -0800 (PST), "Mariano Suárez-Alvarez"
>
>> Likewise, it's scary that people use Mathematica blindly for doing
>> their homework, actually.
>
> Not that scary -- more of a shame. Then again, those same students
> (assuming they graduate) get to possibly use such CAS programs in
> real-world applications. Yep, could be scary after all.
>
Therefor I plea for an open source alternative: Sage, see
http://www.sagemath.org/
Goal:
Creating a viable free open source alternative to
Magma, Maple, Mathematica, and Matlab
Sage has bugs too, but in the open. Look at the source and
send a patch if you know how to solve it. Within a week or two
your contribution will be integrated in Sage and you will be
recognized as contributor to one of the most promising open
source mathematical software systems.
Jaap Spies
> quasi
Christopher Creutzig
>> What'd be scary is to have someone blindly trusting the answers
>
> That assumes interactive use. For a user-written program, should the
> programmer have to write code to double check returned values?
For a mission critical system: Yes, absolutely. And not just those
returned by a CAS, but those returned from anything substantially more
complicated than an integer multiplication. (Not necessarily “double
check” as in “calculate in a different way,” although that is often a
good idea, but sanity checks should happen all the time.)
> Moreover, why should the users have to do their own checks when the
> CAS developers, as expert implementers and testers of algorithms,
> could simply build such checks into the CAS, allowing the user an
> option to toggle automatic consistency checking on or off.
I agree that in a more perfect world, we'd have at least such
consistency checks for all the things CAS systems are doing. But for
many things, that is simply not doable. In other cases, it may not
necessarily be desirable, even when ignoring the (nontrivial) runtime
overhead. For example, any numerical integration algorithm not using
intervals etc. will produce grossly incorrect results on at least one
example input. Using numerical integration as a sanity check on definite
integration can, therefore, only reduce the potential of errors, never
eliminate it – and would certainly lead to bogously rejected correct
results.
--
if all this stuff was simple, we'd
probably be doing something else. -- Daniel Lichtblau, s.m.symbolic
Vladimir Bondarenko
writes:
http://groups.google.com/group/sci.math.symbolic/msg/b1d22cd149c93198
CC> I agree that in a more perfect world, we'd have at
CC> least such consistency checks for all the things CAS
CC> systems are doing. But for many things, that is
CC> simply not doable.
This is completely false.
If designed and implemented with care, it can help, and
without hurting the CAS performance badly.
I am scared to hear such a viewpoint from a SciFace GmbH
person responsible for QA process.
There's no doubt that such a viepoint is at least in part
responsible for at least many thousands distinct defects
in MuPAD 4.
You may wish to consider some comments here.
.........................................................
"Our Competence is your Success" -- claims SciFace GmbH,
the MuPAD makers
.........................................................
A question to the SciFace GmbH leaders/owners
from the #1 world CAS QA engineer
.........................................................
MuPAD 4's havoc: What is the model the SciFace GmbH uses?
.........................................................
Best wishes,
Vladimir Bondarenko
VM and GEMM architect
Co-founder, CEO, Mathematical Director
http://www.cybertester.com/ Cyber Tester, LLC
http://maple.bug-list.org/ Maple Bugs Encyclopaedia
http://www.CAS-testing.org/ CAS Testing
.........................................................
On Jan 26, 12:50 pm, Christopher Creutzig <christop...@creutzig.de>
wrote:
> quasi wrote:
> >> What'd be scary is to have someone blindly trusting the answers
>
> > That assumes interactive use. For a user-written program, should the
> > programmer have to write code to double check returned values?
>
> For a mission critical system: Yes, absolutely. And not just those
> returned by a CAS, but those returned from anything substantially more
> complicated than an integer multiplication. (Not necessarily "double
> check" as in "calculate in a different way," although that is often a
> good idea, but sanity checks should happen all the time.)
>
> > Moreover, why should the users have to do their own checks when the
> > CAS developers, as expert implementers and testers of algorithms,
> > could simply build such checks into the CAS, allowing the user an
> > option to toggle automatic consistency checking on or off.
>
> I agree that in a more perfect world, we'd have at least such
> consistency checks for all the things CAS systems are doing. But for
> many things, that is simply not doable. In other cases, it may not
> necessarily be desirable, even when ignoring the (nontrivial) runtime
> overhead. For example, any numerical integration algorithm not using
> intervals etc. will produce grossly incorrect results on at least one
> example input. Using numerical integration as a sanity check on definite
> integration can, therefore, only reduce the potential of errors, never
> eliminate it - and would certainly lead to bogously rejected correct
Peter Pein
...
> That assumes interactive use. For a user-written program, should the
> programmer have to write code to double check returned values?
From a programmer who used CASs for a relevant time, this is the _least_ I
would expect.
Peter
Daniel Lichtblau
> On Jan 26, 12:50 pm, Christopher Creutzig <christop...@creutzig.de>
> writes:
>
> http://groups.google.com/group/sci.math.symbolic/msg/b1d22cd149c93198
>
> CC> I agree that in a more perfect world, we'd have at
> CC> least such consistency checks for all the things CAS
> CC> systems are doing. But for many things, that is
> CC> simply not doable.
>
> This is completely false.
>
> If designed and implemented with care, it can help, and
> without hurting the CAS performance badly.
You are talking (writing) based on no experience. Implement a symbolic
calculus program, say, and then you'll have some basis to judge such
matters. For one, you'll have a much more clear idea as to whether
they might help in any significant way.
Implementing an "autocheck" for various types of computation makes
good sense, within a software testing environment. Using it inside the
actual computations is generally a RBA ("real bad idea"). There are
exceptions, e.g. using numeric checks to discard parasite roots in
algebraic system solutions. But that tends to be a fairly well defined
area.
It is an open question of whether and when to use such checks
automatically in symbolic integration. Unlike algebraic solvers, there
are myriad problems lurking. I'll name a few.
(1) The symbolic integral might contain functions that are slow to
numerically evaluate accurately.
(2) The checks involve quadrature. This can be significantly slower
than the symbolic integration, particularly as dimension increases.
(3) Quadrature can be prone to errors.
(4) These only are applicable when no parameters are present, or
numerical values within assumption and proviso ranges (if any) have
been selected for the parameters.
None of these impede the use of such checks in the QA process. They
simply mean that such a check is difficult to make within the symbolic
integration itself.
> I am scared to hear such a viewpoint from a SciFace GmbH
> person responsible for QA process.
>
> There's no doubt that such a viepoint is at least in part
> responsible for at least many thousands distinct defects
> in MuPAD 4.
Not knowing specifics of MuPad development, I'd be inclined to suspect
there are several distortions in this statement.
(1) I've seen ample reference to a document claiming another program,
Maple, has "dozens thousands distinct bugs" in some version, possibly
aple 9.5. Said document is partly correct in that it shows clear sign
of the "dozens" distinct bugs. But the "thousands" part was suspect
(okay, conspicuously absent), and really was ly repetition of the same
underlying defects as were categorized in the "dozens".
Point being, from past history I'd be inclined to believe the part
above about MuPad having "many" distinct defects. But I'd not take
seriously the "thousands" claim without independent corroboration.
(2) The claim originally was that exact integration is not likely to
use a numeric check. This reluctance can contribute to some level of
bugginess but I rather doubt it contributes to much, given the
impediments to implementing it well.
(3) It may well be the case that SciFace GmbH uses such methods in
their QA testing processes. The original remark, again, was simply
that it is not readily used in symbolic computations themselves.
Case in point: Integrate in Mathematica does not at this time use
quadrature checks via NIntegrate. But they are used, and in some
places automated, in the testing of Integrate. My opinion is if we
tried to add such quadrature checks to Integrate itself, we'd break
more than we fixed.
(4) Those who write, maintain, and (at least for the commercial ones)
market computational math programs need to have a sense of where to
place finite resources. It is quite possible that the MuPad developers
simply disagree with your implied claim that symbolic calculus is a
high priority area.
> You may wish to consider some comments here.
> [...]
> A question to the SciFace GmbH leaders/owners
> from the #1 world CAS QA engineer
Self-proclaimed. Always remember that. You are the "self-proclaimed #1
world CAS QA engineer." That sort of thing makes a difference, in the
world of credentials (consider the overall level of regard for the
various self-proclaimed mathematics geniuses who post to Usenet).
> [...]
>
> Best wishes,
>
> Vladimir Bondarenko
> [...]
> On Jan 26, 12:50 pm, Christopher Creutzig <christop...@creutzig.de>
> wrote:
> [...]
> > --
> > if all this stuff was simple, we'd
> > probably be doing something else. -- Daniel Lichtblau, s.m.symbolic- Hide quoted text -
[He sounds like a sensible sort. I hope to be like that some day.]
Daniel Lichtblau
Wolfram Research
Christopher Creutzig
> On Jan 26, 12:50 pm, Christopher Creutzig <christop...@creutzig.de>
> writes:
>
> http://groups.google.com/group/sci.math.symbolic/msg/b1d22cd149c93198
>
> CC> I agree that in a more perfect world, we'd have at
> CC> least such consistency checks for all the things CAS
> CC> systems are doing. But for many things, that is
> CC> simply not doable.
>
> This is completely false.
Wrong. It is absolutely true. Please learn some fundamentals, such as
the basic problems about determining whether a constant expression is
zero. This is *undecidable* (in the strong, well-defined sense of that
word used in computer science) for a Turing machine, with the only
constraint being that the algorithm terminate in finite time.
> If designed and implemented with care, it can help, and
> without hurting the CAS performance badly.
Sorry, but I know you hardly know anything about implementing computer
algebra. There's nothing wrong with that, of course, and quite a few of
the bugs you've published are valuable starting points for QA work. But
please stop writing nonsense about things in which you've obviously
never gained experience.
If you wish to disagree, the only way I'm going to be convinced is from
seeing you actually doing some useful work in the realm of CAS
implementation. Put up or shut up.
Oh, just for the record: While of course based on professional
experience, everything stated in here is completely my personal opinion.
quasi
<chris...@creutzig.de> wrote:
>Vladimir Bondarenko wrote:
>> On Jan 26, 12:50 pm, Christopher Creutzig <christop...@creutzig.de>
>> writes:
>>
>> http://groups.google.com/group/sci.math.symbolic/msg/b1d22cd149c93198
>>
>> CC> I agree that in a more perfect world, we'd have at
>> CC> least such consistency checks for all the things CAS
>> CC> systems are doing. But for many things, that is
>> CC> simply not doable.
>>
>> This is completely false.
>
> Wrong. It is absolutely true. Please learn some fundamentals, such as
>the basic problems about determining whether a constant expression is
>zero. This is *undecidable* (in the strong, well-defined sense of that
>word used in computer science) for a Turing machine, with the only
>constraint being that the algorithm terminate in finite time.
>
>> If designed and implemented with care, it can help, and
>> without hurting the CAS performance badly.
>
> Sorry, but I know you hardly know anything about implementing computer
>algebra. There's nothing wrong with that, of course, and quite a few of
>the bugs you've published are valuable starting points for QA work. But
>please stop writing nonsense about things in which you've obviously
>never gained experience.
I think _you_ miss the point.
No one is saying that a CAS can always give valid outputs, given valid
inputs.
Rather the CAS code should _defend_ against inputs which are out of
range for the given algorithm. If the input is out of range, the CAS
should fail, returning an error message rather than a wrong answer.
Microsoft learned this lesson the hard way with buffer overruns.
It's a lesson that keeps on getting relearned by each generation of
developers.
Professional programs, designed for public use, need to check their
inputs at every stage. No internal routine should "trust" the calling
routine unless the input arrives with a "certificate of validity", and
an indication of whether exact (if symbolic) or, if approximate, a
bound on the error. Similarly, outputs should be accompanied by such a
certificate, freeing the next routine from the obligation to check its
inputs (except to inspect the certificate), but not freeing it from
the obligation to certify its output.
The performance loss in return for guaranteed reliability is worth it
for many applications, as long as the penalty is not too severe. For
most routines, the performance penalty should be negligible, since
checking is typically faster than solving, but in the worst case, I
would not expect a certified system to take more than twice the normal
time.
Moreover the CAS can offer 2 modes -- a "draft mode" (like for a
printer) which gives fast results but with no guarantees, and a
"certified mode" which guarantees the final output to within a
specified error tolerance.
Is it doable? Of course!
Is it easy? Well, it may require a full redesign of the internals --
not a small task, so no, it's not so easy, but it doesn't require
rocket science -- just a careful redesign.
The CAS providers who undertake such a redesign will have that as a
huge selling point in their favor. One can judge the relative quality
of a CAS based on its range of important features, its ease of use,
its speed, _and_ its reliability. Let the best CAS win!
quasi
Bhuvanesh
> ----------------------------------------------------------------
>
> An exact 1-D integration challenge - 48 -
> (go and give a kick to all stupid CASs!)
>
>
> ----------------------------------------------------------------
>
> N[Integrate[
>
> Sqrt[Sqrt[2] + Sqrt[z] + Sqrt[2 + 2 Sqrt[2] Sqrt[z] + 2 z]],
>
> {z, 0, 1}]]
>
> ----------------------------------------------------------------
> VERSION OUTPUT RESOLUTION
> ----------------------------------------------------------------
>
> Mathematica 6.0 2.67602 <-------------------------------- BUG
>
> Mathematica 5.2 3.66533 <-------------------------------- BUG
>
> Mathematica 4.2 Unevaluated integral
>
> Mathematica 3.0 Unevaluated integral
>
> ----------------------------------------------------------------
>
> Best wishes,
>
> Vladimir Bondarenko
>
> VM and GEMM architect
> Co-founder, CEO, Mathematical Director
>
> http://www.cybertester.com/ Cyber Tester, LLChttp://maple.bug-list.org/ Maple Bugs Encyclopaediahttp://www.CAS-testing.org/ CAS Testing
I believe a similar example was discussed in sci.math.symbolic quite
recently. The antiderivative was incorrect. It was fixed in the
development version and we now have:
In[1]:= Integrate[Sqrt[Sqrt[2] + Sqrt[z] + Sqrt[2 + 2 Sqrt[2] Sqrt[z]
+ 2 z]], {z,0,1}] //InputForm
Out[1]//InputForm=
Integrate[Sqrt[Sqrt[2] + Sqrt[z] + Sqrt[2 + 2*Sqrt[2]*Sqrt[z] + 2*z]],
{z, 0, 1}]
In[2]:= N[%]
Out[2]= 2.06276
Bhuvanesh,
Wolfram Research
Christopher Creutzig
> I think _you_ miss the point.
Maybe. I know I did a few times in the past, but that's part of what a
discussion is all about.
> No one is saying that a CAS can always give valid outputs, given valid
> inputs.
>
> Rather the CAS code should _defend_ against inputs which are out of
> range for the given algorithm. If the input is out of range, the CAS
> should fail, returning an error message rather than a wrong answer.
Please re-read what I quoted and what I replied to. While there is some
value in cross-checking with semi-heuristic methods, such as numerical
evaluations often are, for automated testing (I'm sure every CAS
producer has been doing that for ages), I (and others) highly doubted
the value of such an approach for on-line checking of results produced
in a production environment behind the scenes. This part is certainly
something that could be discussed at length, but any such discussion, if
it tries to go beyond personal gut-feeling, must include at least
empirical studies. I don't currently see anyone doing these.
The other part of my reply was that there are numerous things in a CAS
which simply *cannot* be reliably checked in a strong sense. I've
pointed to some theoretical background on the reasons for that. Nothing
of this is new, it's been proven decades ago and, to be honest, should
be part of the general knowledge for sci.math.symbolic authors, if not
readers. (Oh, BTW, I'm not going to keep responding to such excessive
crosspostings.) I regard it as highly surprising that Vladimir seems to
be unaware of these problems. (I am not surprised to see that he starts
spreading fud on MuPAD again. That's just a predictable reaction to my
pointing out some of his errors.)
Please note that I'm not talking about inputs which are “out of range.”
Some of the cases where you run into these fundamental problems may be
considered “out of range” for the algorithm implemented, but certainly
not “out of range” for the problem specification. Neither do I wish to
say “software is buggy, but it must be.” What I was trying to say is
“sounded like a good idea the first time I heard it, but this particular
approach does not work as generally as you imply, and here's why: …”
> Microsoft learned this lesson the hard way with buffer overruns.
Sorry? What's special about Microsoft in terms of buffer overruns? Just
about every programmer using a susceptible language has been bitten by
those at least once. And probably every server-like program has at one
time or the other had to be fixed because such a bug caused security
problems. I'm not saying that is all right. I just try to keep a
realistic world-view, to improve things that can be.