Re: Maple bugs: Thomas Richard: Hurrah, Maple quality improves! - Example 4
From: Vladimir Bondarenko (vb_at_cybertester.com)
Date: 03/07/05
- Next message: Humberto Jose Bortolossi: "Is it possible to know a priori if an integral is not an elementary function?"
- Previous message: John Creighton: "Re: I created a fractal that looks like a penis !!!"
- In reply to: Shug Boabby: "Re: Maple bugs: Thomas Richard: Hurrah, Maple quality improves! - Example 4"
- Messages sorted by: [ date ] [ thread ]
Date: 7 Mar 2005 13:09:46 -0800
"Shug Boabby" <Shug.Boa...@gmail.com> wrote on Fri, Mar 4 2005 4:03 pm
SB> proof that maple is getting worse.
Actually, the proof is just before your and my eyes. As you know,
there is a concept named 'regression bug'. This means that if a
functionality works well in the version n, then it should work at
least not worse in the version (n+1) of the given product. This
kind of things is designed and used to guarantee the customer of
the given product that the functionality he or she relies upon
is again here when he or she buys a new version.
The proof about the fact that Maple is getting worse is *massive*
presence of essences that now work now don't work over Maple
versions since 1994 to 2005.
This implies blatant lack of regression testing (or ignoring the
results of such testing).
There are _at least_ thousands examples when something works
well in version Maple n, but is broken in version Maple n+1.
You can find such examples easily in Maple Bugs Encyclopaedia
Further, if you are interested in testing software, there are
many bright books on the topic, including easy-to-read but
very useful and practical ones like
http://www.amazon.com/exec/obidos/ASIN/0471358460/
Testing Computer Software, by Cem Kaner, Jack Falk, Hung Q.
Nguyen, 2nd Edition, 1993, ~500pp
http://www.amazon.com/exec/obidos/ASIN/0471120944/103-0233297-5319828
Black Box Testing, by Boris Beizer, 1995, John Wiley & Sons
An older interesting book is
http://portal.acm.org/citation.cfm?id=539194
Joseph M. Fox, Software and Its Development, 1982, 336 pp
directly from a person who had been an IBM top software
development leader during 7.5 years.
Lots of important (and excellent written!) stuff could be found
at the home site of highly gifted Prof. Cem Kaner, J.D., Ph.D.
The Software Quality Research Laboratory's team conducts
fundamental research in support of professional software
developers, specifically to develop methods and tools that
can be used to improve the quality of industrially developed
software.
BS> if your real intent is to prove Herr Richard wrong, then
BS> please provide us with a full list of bugs shipped with
BS> each version of maple...
I am inspired to feel that you obviously consider me to be a
computational genius :)
Because you expect from me (1 person) resolving the task (and
quickly!), the whole Maplesoft team (now about 150 persons)
failed to resolve during about 25 years.
Even more, you expect from me to provide, _for free_, general
public with a huge stock of Maple bugs (many thousands bugs in
early Maple versions of the beginning of the 90s to (at least!)
dozens thousands bugs in Maple 9.5.2)
In other words, the task you propose is BEYOND human powers.
It is beyond even the powers of a team of trained professionals.
Remember, at Maple has about 4,500 functions. (By the way, it
is not improbable that some Maple functions you will even not
try during your lifetime, - you just need not them!)
However, the most amazing thing about our unexpected dialogue
is that YOU ARE RIGHT IN YOUR EXPECTATIONS!
Because I am a bright computational talent who was able to
architect the GEMM and the VM machines, and at Cyber Tester
we keep implementing them to deliver, in a reasonable amount
of time - not years, the description of Maple bugs of the
scope never available before Cyber Tester.
By the way, the task completing which you expect from me
had been already set at this page of Maple Bugs Encyclopaedia
http://maple.bug-list.org/why.php
BS> normalised to the power gained in each release.
At the first glance, the normalization idea seems to be a kind
of something reasonable and two decades ago I spent many dozens
hours playing with it. But...
Actually, the main rub is how to define 'the power gained
in each release' in a reasonable way?
The worst is that, this 'gained power', in contrast to 'pure'
bug existence statements (bug reports etc) is subjective. You
prefer green, I like yellow, who of us is 'right'?
Say, you are interested mostly in Maple's 'tensor-power',
I am interested in Maple's 'calculus-power', Alec Mihailovs
is interested in Maple's 'group-power'... and all of us are
right. Because each of us buys Maple for his specific tasks.
Of cause, it could be possible to concoct a kind of mixture
of a*'tensor-power' + b*'calculus-power' + c*'group-power'
and use it. But it looks like such a criterion would hardly
reflect something really of interest for you or me or Alec.
BS> i'd be very surprised if the number of new bugs seriously
BS> outweighs new features.
Haven't you meant,
'the number of [and damage caused by] new bugs seriously
outweighs [the benefits coming from] new features.' ?
At any rate, this is your (or mine) internal estimation of
what is valuable and what is not.
The main facts about Maple are that
1. The quality of a concrete feature in the next Maple
release is not predictable.
2. The quality of a concrete feature, over Maple versions,
can deteriorate in a complex way, most typical are,
roughly speaking, if considered qualitatively,
1) oscillatory quality decay
2) monotonic quality decay
3) abrupt quality failure.
Find much more in our Maple Review coming.
SB> every program has bugs in its release.
There is a lot of exciting stuff on this topic in, for example,
http://www.cybertester.com/data/whysobad.pdf
Why software is so bad, by Charles Mann, Technology Review, 2002
> It's one of the oldest jokes on the Internet, endlessly
> forwarded from e-mailbox to e-mailbox. A software mogul -
> usually Bill Gates, but sometimes another - makes a speech.
> 'If the automobile industry had developed like the software
> industry,' the mogul proclaims, 'we would all be driving
> $25 cars that get 1,000 miles to the gallon.' To which an
> automobile executive retorts, 'Yeah, and if cars were like
> software, they would crash twice a day for no reason, and
> when you called for service, they'd tell you to reinstall
> the engine.'
> ...........................................................
> .............. many interesting facts .....................
> ...........................................................
http://www.economist.com/printedition/displayStory.cfm?Story_ID=3423238
Managing complexity, The Economist, Nov 25th 2004
> Most software projects fail to meet their goals. Can this
> be fixed by giving developers better tools?
> On September 14th, the radios in an air-traffic control
> centre in Palmdale, California shut down, grounding hundreds
> of flights in southern California and Nevada, and leading to
> five mid-air encounters between aircraft unable to talk to the
> ground controllers. Disaster was averted because aircraft
> managed to communicate with more distant back-up facilities.
> But why did Palmdale's radios fail? A glitch in the software
> running the system meant the computers had to be re-booted
> every 30 days, and somebody forgot to do so. But software
> running a mission-critical system should not have to be
> restarted every month. The culprit: poor design.
> At least Palmdale's software worked some of the time. The
> same cannot be said of an $4 billion write-off that America's
> Internal Revenue Service (IRS) had to swallow when a multi-year
> effort to overhaul its computer system failed completely in 1997.
> And such problems are confined neither to governments nor to
> America. A L456m ($844m) project for Britain's Child Support
> Agency came in over a year late, and has failed to deliver
> payments to more than half of eligible applicants.
> ...........................................................
> .............. many interesting facts .....................
> ...........................................................
BUT.
This is like a splinter in the mind of most persons. Actually,
the hidden connotation is even maybe 'every program has many
bugs in its release.'
However, this silly statement resides in minds of humans but
NOT in nature of software itself.
Do you realize, for example, that one can seriously improve the
quality of CA systems by using a typed system for generating
much of the code instead of hand-writing it?
With such an approach, the compiler is able to check for many
many bugs and refuse to compile the code in those cases.
This is a direction proposed recently, in particular, by
Jacques Carette.
http://www.cas.mcmaster.ca/~carette/publications/ge.pdf
> Is it possible to write a generic yet effcient Gaussian
> Elimination algorithm?
> Is it possible to write a generic, type-safe yet effcient
> Gaussian Elimination algorithm?
>..........................................................
Further, it looks like that (overwhelming majority of) the
'survivor bugs' could be identified automatically by my VM
and GEMM machines.
SB> and it sucks that proprietary software such as maple has a
SB> very poor way of addressing bug fixes (opposed to the open
SB> model which maxima has).
Yep. I agree with you 101% here. In fact this is a question of
Maplesoft's internal policy.
Robert Israel <israel@math.ubc.ca> writes on Nov 7, 2001 15:03:49
http://www.scg.uwaterloo.ca/~maple_gr/Digests/Digest01.11
RI> The fact is that new features sell much better than
RI> bug-fixes.
This is so. However, such an approach is good for temporizers
only because is leads, gradually, to loosing control over the
development, which is precisely the case with Maple. Much more
stuff on this you could find in my Maple Review coming.
SB> i do think it is great that you are creating a bug list
SB> for maple...
Thank you for sincere appreciation of Cyber Tester's team work!
In the long run, sooner or later, I hope to made public the
details behind the Cyber Tester's effort, and I believe that
you will be rocked by some facts.
SB> hopefully the valid bugs can be addressed by the authors
Actually, Maplesoft visits our sites regularly.
SB> and people like me will benefit from your work in the
SB> future.
Thanks again! I believe that, while I do not know the motives
making Maplesoft's team fixing this or that concrete bug, even
at present, at least many dozens bugs have already been fixed
by Maplesoft because the bugs have been made public. I have such
a feeling, in particular, because in Maple Bugs Encyclopaedia,
there are *contiguous* spans of bug reports for which ALL these
bugs are now fixed.
The brightest most recent case of the benefit you are speaking
about is maybe the Maple 9.5.2 fix proposed by Paul DeMarco,
Manager of Kernel Development, Maplesoft
http://groups-beta.google.com/group/comp.soft-sys.math.maple/msg/5a7f09a0e965f819
http://groups-beta.google.com/group/comp.soft-sys.math.maple/msg/c8779e533f3071e6
in response to Cyber Tester's publication,
Maple bugs: A dangerous, misleading ad statement at the main
Maplesoft's site
http://groups-beta.google.com/group/comp.soft-sys.math.maple/msg/dd5e6a02c428dad9
followed by a vivid discussion started by Urlich Thye
not nice
http://groups-beta.google.com/group/comp.soft-sys.math.maple/msg/137d00cd3cc7b8b1
maple 9.5:
> z-z+z^2+z^3;
> z-z+z^2+z^3;
2 3
z + z
2 3
2 z + 2 z
My claim to fame is that this bug was identified not by a human
being but automatically, by the GEMM machine, along with many
thousands other distinct Maple bugs. By distinct I mean that
most probably to fix each of them, Maplesoft developers should
change specific lines for each bug (and cannot fix these bugs
via replacing the lines in a single place).
I also would like to express deep gratefulness to active
Maple users for commenting bugs!
Unitis viribus, together we the Maple customers make an
invincible power.
All the Maple customers of the world unite! ;)
Vladimir Bondarenko
VM and GEMM architect
Co-founder, CEO, Mathematical Director
Cyber Tester, LLC
http://www.cybertester.com/
http://maple.bug-list.org/
http://www.CAS-testing.org/
- Next message: Humberto Jose Bortolossi: "Is it possible to know a priori if an integral is not an elementary function?"
- Previous message: John Creighton: "Re: I created a fractal that looks like a penis !!!"
- In reply to: Shug Boabby: "Re: Maple bugs: Thomas Richard: Hurrah, Maple quality improves! - Example 4"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
