euler(0,1) shows Maple bugs are really ubiquitous
Vladimir Bondarenko
I wrote on 2003-10-23 13:45:57 in the message "Maple bugs are
ubiquitous (BUG # 3172: asympt: KERNEL FAILURE)"
VB> Looks like I am starting to believe that one can run across
VB> a Maple bug in a very unexpected place...
The recent catch by Peter Luschny is a splendid and fairly
typical example of Maple mathematical correctness. I also
believe it also shows why the Cyber Tester, LLC' massive
computation effort directed to Maple bug identification is
so important: for the first time, all of us will have a
holistic eerie and grand tapestry of Maple bugs, NOT that
you see today at http://maple.bug-list.org/ .
PL> euler(0,1); # Sure, this must be equal to 1
-1
I confirm that this bug is present in these Maple versions
Maple 9.03, IBM INTEL NT, Oct 1 2003 Build ID 141050
Maple 9.02, IBM INTEL NT, Jul 9 2003 Build ID 137227
Maple 9.01, IBM INTEL NT, Jul 9 2003 Build ID 137227
Maple 9.00, IBM INTEL NT, Jun 13 2003 Build ID 136194
Maple 8.01, IBM INTEL NT, May 1 2002 Build ID 119670
Maple 8.00, IBM INTEL NT, May 10 2002 Build ID 111221
Maple 7.00, IBM INTEL NT, May 28 2001 Build ID 96223
Maple 6.01, IBM INTEL NT, Jun 9 2000 Build ID 79514
Maple V, Release 5, IBM INTEL NT, Nov 27 1997
Maple V, Release 4, IBM INTEL NT, Dec 15, 1995
Maple V, Release 3, IBM INTEL NT, Jan 10, 1994
Now I'd like to hear a new Alec Mihailovs' statements like
"it's a feature" or something like he had replied me about
"New Maple bug in series" posted on 2003-10-22 03:03:43,
just read and enjoy again Alec's remarkable sentence,
AM> "Fortunately, arccosh is not something that is used
AM> very often."
Encore! ;)
Best,
Vladimir Bondarenko
http://www.cybertester.com/
http://maple.bug-list.org/
http://www.CAS-testing.org/
.............................................................................
Alec Mihailovs
news:8cf8cf57.03122...@posting.google.com...
>
> PL> euler(0,1); # Sure, this must be equal to 1
> -1
>
> "it's a feature" or something like he had replied me about
> "New Maple bug in series" posted on 2003-10-22 03:03:43,
> just read and enjoy again Alec's remarkable sentence,
>
> AM> "Fortunately, arccosh is not something that is used
> AM> very often."
As usual, this can be easily fixed:
myeuler:=n-> if n=0 then 1 else euler(args) fi:
myeuler(0,1);
1
Alec
Peter Luschny
> > "Vladimir Bondarenko"
> > PL> euler(0,1); # Sure, this must be equal to 1
> > -1
> As usual, this can be easily fixed:
> myeuler:=n-> if n=0 then 1 else euler(args) fi:
> myeuler(0,1);
I am impressed ;-) Thanks.
But, as usual, you did not get the point.
If we have to start to fix even the constant functions
in Maple first, we can very well refrain from using
Maple at all.
Second: Can you tell us how many software out there,
build since
Maple V, Release 3, IBM INTEL NT, Jan 10, 1994
** 10 years now, happy birthday **
use explicit or implicit this function and is
by this very fact buggy? How can you help them?
You can't.
Most of them will never be aware of this fact but
all of them might be bitten some day by the bug.
And third: I did not really expect a bug fix, but a
comment, what might be so fundamentally wrong at
Maplesoft, that they cannot even guarantee a
constant function to have a constant value.
The usual blah-blah of inherent complexity ect.
used to exculpate inability, is obviously not
applicable here.
To build a robust, all time correct code for
euler(0,x) all you have to do is
euler := proc(n,x) if n=0 then RETURN(1) else..
(Which is even shorter than your bug fix.)
They obviously use other techniques, and these
techniques of software-development are not robust
and not state of the art, use techniques which fail
over and over again.
They are to be asked why.
What I can imagine as a possible cause: The
developers there know too much of mathematics
and not enough of software development.
And the management fails to realize this.
The Java-front-end debacle might indicate that
the management cannot even identify competent
developers for a given task.
Regards Peter
Alec Mihailovs
news:bs95sd$at4b0$1...@ID-64349.news.uni-berlin.de...
> > "Alec Mihailovs" wrote:
> > As usual, this can be easily fixed:
>
> > myeuler:=n-> if n=0 then 1 else euler(args) fi:
> > myeuler(0,1);
>
> I am impressed ;-) Thanks.
> But, as usual, you did not get the point.
Why do you think so? Your point is pretty clear - Maple has bugs. What is
hard to get here? I think that everybody in this group knows that.
> If we have to start to fix even the constant functions
> in Maple first, we can very well refrain from using
> Maple at all.
That's not true. I use Maple practically every day, as well as many other
people do. Certainly, from time to time one has to deal with bugs. Usually
it is pretty simple, as in this example.
> Second: Can you tell us how many software out there,
> build since
>
> Maple V, Release 3, IBM INTEL NT, Jan 10, 1994
> ** 10 years now, happy birthday **
Actually, the euler procedure has been copyrigted in 1990, so it is even
older than that.
> use explicit or implicit this function and is
> by this very fact buggy? How can you help them?
> You can't.
Practically all the software that I know that existed in 1990, have bugs.
The same as practically all books and journal articles have typos. That
doesn't prevent most of us from reading books and using computers.
> Most of them will never be aware of this fact but
> all of them might be bitten some day by the bug.
So what? Nobody likes that, but it is a reality. I also don't like the fact
that our bodies contain a few pounds of bacteries, for example. That doesn't
stop us from living though.
> And third: I did not really expect a bug fix, but a
> comment, what might be so fundamentally wrong at
> Maplesoft, that they cannot even guarantee a
> constant function to have a constant value.
As Dr. Edgar already mentioned, it was caused just by a typo. One of
conditional expressions in the euler procedure has elif x=1 ... before elif
n=0. Evidently, not so many people used the euler procedure for calculating
euler(0,1) so it hasn't been discovered earlier. Now, after you found that,
it might be fixed in the next Maple release. Before that, one can use a
pretty simple workaround. Same as with many other bugs. Not a reason to get
hysterical.
> The usual blah-blah of inherent complexity ect.
> used to exculpate inability, is obviously not
> applicable here.
Neither the usual blah-blah about ubiquitous Maple bugs.
> To build a robust, all time correct code for
> euler(0,x) all you have to do is
>
> euler := proc(n,x) if n=0 then RETURN(1) else..
>
> (Which is even shorter than your bug fix.)
The euler procedure has a similar code, just with a typo in it.
> They obviously use other techniques, and these
> techniques of software-development are not robust
> and not state of the art, use techniques which fail
> over and over again.
>
> They are to be asked why.
The usual blah-blah about complexity is applicable here.
> What I can imagine as a possible cause: The
> developers there know too much of mathematics
> and not enough of software development.
I don't see anything wrong in knowing much of mathematics - it never can't
be too much. They know enough of software development to produce Maple. Bugs
and typos happen just because of human nature - not because of lack of
knowledge.
> And the management fails to realize this.
I can't imagine that.
> The Java-front-end debacle might indicate that
> the management cannot even identify competent
> developers for a given task.
The problem is mostly caused by Java - not by Maple developers or
management. One can blame Sun for that rather than Maplesoft. I'm sure it
will work better in future Maple releases.
Alec
Peter Luschny
> > "Peter Luschny" wrote:
> > > "Alec Mihailovs" wrote:
> I also don't like the fact
> that our bodies contain a few pounds of bacteries,
> for example. That doesn't stop us from living though.
;-)) But if the few pounds of bacteria's turn out to
be a few pounds of bugs, live could become pretty rough...
> > The usual blah-blah of inherent complexity ect.
> > used to exculpate inability, is obviously not
> > applicable here.
> Neither the usual blah-blah about ubiquitous Maple bugs.
Yes, Vladimir's marketing is not perfect, yet. But what
about the slogan: "Maple - unsafe at any evaluation"?
> > ... what might be so fundamentally wrong at
> > Maplesoft, that they cannot even guarantee a
> > constant function to have a constant value.
> As Dr. Edgar already mentioned, it was caused just
> by a typo. One of conditional expressions in the euler
> procedure has elif x=1 ... before elif n=0.
Alec, are you kidding? I disagree totally with you to
call this a typo.
This is a bug in the 'logic'. It is a bug like a bug
can be! A program is a linear sequence of 'ifs' and jumps,
and when you change the order in this sequence you change
everything. You get another program or the most classical
bug you can conceive, depending on your point of view!
Further, if you would be more interested in fighting bugs
than in fighting bug hunters, a check with your own eyes,
a thing not totally inappropriate for an academic, would
have revealed another interpretation:
Line 24: elif x = 1 then -euler(n, 0)
is meant to be formula 23.1.8 in the Handbook of
Mathematical Functions, which says
euler(n,1-x) = (-1)^n*euler(n,x)
for x=0. Now the bug amounts to writing '-' instead
of '(-1)^n'. Try it! Replace line 24 by
Line 24*: elif x = 1 then (-1)^n*euler(n, 0)
and the bug is killed ;-) Thus the bug can very well be
seen as a mathematical bug, as a fallacious application
of the symmetry relation of the Euler polynomials.
My point is: I think such a bug is well visible
by using logic analyzers, flow analyzers and some of
the diagram techniques, which are software tools for
professional developers throughout the world for years now.
(Maybe your training dates back to the days of assembler
and so you do not know about these 'modern' tools ;-)
Moreover, the availability of tools to build large bases
of test-cases simultaneously with the writing of software,
would have certainly also revealed this bug, because the
symmetry relation just mentioned which is crucial to the bug
would certainly have been used in such an setup.
Maplesoft obviously does not use these tools, and
therefore is to be asked why not.
> Actually, the euler procedure has been copyrigted in 1990 [...]
> Practically all the software that I know that existed in 1990, have bugs.
Yes, they derive back from the days of the assembler-gurus ;-)
But, Vladimir writes:
| I confirm that this bug is present in these Maple versions
| Maple 9.03, IBM INTEL NT, Oct 1 2003 Build ID 141050
So the bug is in their software of Oct 1 2003, and the
bucks to be paid are the bucks of today. Maplesoft is
responsible for the packages they sell today. It is
their responsibility to include risky old code or
well-engineered code based on up-to-date tools.
> Evidently, not so many people used the euler procedure for calculating
> euler(0,1) so it hasn't been discovered earlier.
Evidently, there are bugs which occur only once: The
bug which crashed Ariane
<http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html>
and the bugs, which killed people in the American Space-Program.
You know that! When we discuss how to avoid bugs your
argument is as poor as an argument can be - because
you totally fail to see that the next silly little 'typo',
as you prefer to call it, might occur at some vital point.
> Now, after you found that,
> it might be fixed in the next Maple release.
It might, and I hope it will. But I have also called
attention (which can be found with google groups) to
bugs in Rel. 4 and Rel. 5, and these bug lived happily
on in Rel. 6, in Rel. 7 and in Rel. 8 thereafter.
Maplesoft used to ignore bug reports.
If they have changed their politics in this regard
(did they really, where is the open database of bugs?)
than maybe because the number of people who are
willing to pay for pounds of bugs decrease in time,
as they can read it in this newsgroup, for example.
> > And the management fails to realize this.
> I can't imagine that.
> > The Java-front-end debacle might indicate that
> > the management cannot even identify competent
> > developers for a given task.
> The problem is mostly caused by Java - not by Maple developers or
> management. One can blame Sun for that rather than Maplesoft.
You can blame Sun for delivering a GUI-library, which
only experts can handle. But it is possible. This is
well known in the Java-community. Moreover, it is a
difficult task to write good GUIs, 10 to 100 times more
difficult than to write correct code for the Euler polynomials.
It seems that Maplesoft management fails to know all this.
> I'm sure it will work better in future Maple releases.
Yes, I read this attitude here before: "Pay now for
the bugs, be thankful for the bug fixes later.."
Regards Peter
Vladimir Bondarenko
O tempora! o mores! Why, shame upon you, man! Only for 20 years
Maplesoft palms off next versions on you - and your faith has
been already shaken, so soon?!
What I am hearing?? Why? Are you in serious?! I cannot believe
my ears...
Haven't you read at
http://www.maplesoft.com/support/index.shtml
MS> Maplesoft is committed to providing the highest level
MS> of support for the products it sells.
Of what Maplesoft says you don't believe a tithe?!
"The highest" is the superlative as you know, so just wait
15-20 years and this will be fixed. (Maybe.)
And remember, if there will not be the fix within these
20-25 years to come, they say, there is afterlife.
Best,
Vladimir
Alec Mihailovs
>
> Alec, are you kidding? I disagree totally with you to
> call this a typo.
Then what is it? Do you think that Maple developers deliberately did that?
> Further, if you would be more interested in fighting bugs
> than in fighting bug hunters,
I am not interested in neither fighting bugs nor bug hunters. Fighting
bugs - it is something that Maplesoft should do. Bug hunters, if they are
interested in future development of Maple, should submit their bugs to
sup...@maplesoft.com and apply for beta tester positions at
beta.maplesoft.com. Then they will be restricted by a contract with
Maplesoft to not post the bugs in public.
> My point is: I think such a bug is well visible
> by using logic analyzers, flow analyzers and some of
> the diagram techniques, which are software tools for
> professional developers throughout the world for years now.
> (Maybe your training dates back to the days of assembler
> and so you do not know about these 'modern' tools ;-)
I program pretty professionally in all the languages that I can name and I
taught quite a few of them for many years. I don't know what is your
training in that direction. "The days of assembler" say that you don't know
the assembler. "The days of assembler" are past, present, and future,
especially for mathematics related programming that can be easily done on
registers thousands times faster than using C and millions time faster than
using Java. For this particular bug, I don't think that any of the logic
analyzers, flow analyzers, or the diagram technique can find it, because it
is a bug in the algorithm and not in logic, flow, or diagrams. Well, maybe
it is a bug in logic. Do you know any particular logic analyzer that could
find it?
> Maplesoft obviously does not use these tools, and
> therefore is to be asked why not.
As far as I can tell, Maplesoft is using a lot of tools. The problem is that
Maple library consists of a lot of small procedures like euler, each of
which has been developed by different people in different times. You can
call that a comlexity bla-bla-bla, but it is true. They are periodically
reviewed by other people, but still some bugs are left undetected. It is not
something unusual or unexpected.
> > Actually, the euler procedure has been copyrigted in 1990 [...]
> > Practically all the software that I know that existed in 1990, have
bugs.
>
> Yes, they derive back from the days of the assembler-gurus ;-)
That is just rude. Assembler-gurus, as well any other gurus don't produce
bugs. Bugs are produced by non-gurus ;-) (whatever the secret sign ;-) that
you think only special people are using means).
> Evidently, there are bugs which occur only once: The
> bug which crashed Ariane
>
<http://archive.eiffel.com/doc/manuals/technology/contract/ariane/page.html>
> and the bugs, which killed people in the American Space-Program.
That's why Maple is not recommended for using in such programs.
> > Now, after you found that,
> > it might be fixed in the next Maple release.
>
> It might, and I hope it will. But I have also called
> attention (which can be found with google groups) to
> bugs in Rel. 4 and Rel. 5, and these bug lived happily
> on in Rel. 6, in Rel. 7 and in Rel. 8 thereafter.
> Maplesoft used to ignore bug reports.
If they were properly submitted and the bugs could be easily corrected, then
certainly Maplesoft would correct them. Why not? One can't expect Maplesoft
to monitor all of the Yahoo groups or even this group though.
Alec
RockyLake
> 20-25 years to come, they say, there is afterlife.
>
of ping pong. The game starts when someone with an ax to grind asks a
question as if truly interested in obtaining help. The serve is
returned by individuals who are generous with their time as they offer
constructive suggestions. The game continues as the ax grinder
volleys back denigrating Maple's capabilities by asking for
acknowledgment that Maple has bugs. And so on and on.
I thought that this unmoderated newsgroup existed for (a) people who
were interested in learning better Maple skills and understanding how
to use Maple to solve problems and (b) for the people who have
expertise that they share with those of us willing to learn to use
Maple. Postings that identify bugs and the follow-ups that state how
to work around them certainly fit into my conception of the purpose of
this newsgroup. Persistent whining that Maple has bugs and demanding
acknowledgment that bugs exist and have persisted is not constructive.
Sarcasm may make the person posting the message feel good, but it
fails to further either understanding or a desire to sympathize with
the point of view taken by the sarcastic writer. Demanding
acknowledgment that bugs exist is not constructive, we all know that
Maple has bugs. Persistently demanding acknowledgment that bugs exist
has the appearance of demanding that others bow down to what the
person posting the message feels is a superior position. Whether such
appearances are accidental or intentional, they are not constructive.
The many postings on problems with version 9's interface have been
very informative and caused me to postpone moving to version 9. I
suspect that the folks at Maple are keenly aware of what version 9's
sales are compared to other releases. That information in conjunction
with the many complaints they have seen get the point across about
dissatisfaction with a buggy interface.
If one wants to have a real effect on Maplesoft's management, I
suggest typing a letter on real paper and sending it via real mail to
the president of Maplesoft. Email is nice, real paper makes an impact.
Make it short, make it polite, and state what specific action you
expect to be taken by Maplesoft.
I, too, have found bugs in Maple and in some cases I found my own work
around and in other cases I relied on others for help, usually in this
newsgroup. Having been using computers for going on 40 years I do not
expect perfection in software (or hardware), and remain disappointed
when defects occur. I have found annoying bugs in assemblers,
compilers, word processors, spreadsheets, mathematics package
(including Maple), presentation packages, and, horrors, even in my own
software.
However, I do not curse the darkness. Instead I attempt to light a
candle. I notify Maplesoft when I find a bug so that they are aware
of it. They have always responded that they have checked and that the
bug exists. I refrain from whining because it is not constructive. I
recognize that Maplesoft is staffed by humans who have more work to do
than time available (that is the human condition – work expands to
completely the time available), and that priorities must be
established. I am not angry that satisfying my individual needs is
not at the top of the list. I am disappointed that bugs waste my time
and I do not like working around bugs. I am thankful that Maple has a
robust structure that allows me to work around bugs. I am thankful
that this newsgroup exists where I get valuable information on bugs
and how to work around them. This is orders of magnitude better than
what I have experienced with some popular compilers. I wish that we
humans did not make mistakes, and I know that yelling and screaming
does not cause people to make fewer mistakes nor make them more
willing to correct errors.
Messrs. Devore, Mihailovs, Israel, Clark, Richard, Edgar and many
others have lit many candles that have contributed enormously to my
understanding of Maple's capabilities and limits. I commend these
fine gentlemen and all others who have been so generous with their
wisdom and time. I recommend that others, who also have considerable
knowledge of Maple's capabilities and limits, to emulate these fine
people by always being constructive.
John Cordes
> I have been reading this thread and similar ones that resemble a game
> of ping pong. The game starts when someone with an ax to grind asks a
> question as if truly interested in obtaining help. The serve is
> returned by individuals who are generous with their time as they offer
> constructive suggestions. The game continues as the ax grinder
> volleys back denigrating Maple's capabilities by asking for
> acknowledgment that Maple has bugs. And so on and on.
<snip>
> Messrs. Devore, Mihailovs, Israel, Clark, Richard, Edgar and many
> others have lit many candles that have contributed enormously to my
> understanding of Maple's capabilities and limits. I commend these
> fine gentlemen and all others who have been so generous with their
> wisdom and time. I recommend that others, who also have considerable
> knowledge of Maple's capabilities and limits, to emulate these fine
> people by always being constructive.
Hear, hear - very well said!
--
John Cordes
Carl Devore
> Bug hunters, if they are interested in future development of Maple, should
> submit their bugs to
> sup...@maplesoft.com and apply for beta tester positions at
> beta.maplesoft.com. Then they will be restricted by a contract with
> Maplesoft to not post the bugs in public.
I disagree. I think that to some extent the public posting of bugs is
a good thing that improves the product. Proprietary software has a
unique and somewhat dangerous position in our society of not being
subject to a public peer review process: Scientific ideas, patented
inventions, "free" software, and buildings and other most other large
engineering projects all undergo a **public** peer review process.
Please see the book _The Cathedral and the Bazaar_ by Eric S. Raymond
for extensive discussion of this (the book is available for free
online and has also been published by O'Reilly).
> One can't expect Maplesoft to monitor all of the Yahoo groups or even this
> group though.
Why not?????? Monitoring **all** Usenet and public Yahoo discussion
of Maple, and filing the consequent bug reports, could easily be done
as a part-time job by an intern. After all, you and I both do that.
I have made such a suggestion to Maplesoft several times.
Nay, in contrast I say that the casual user who posts to Usenet cannot
be expected to file bug reports. They often do not know whether what
they have found is indeed a bug.
Carl Devore
> The many postings on problems with version 9's interface have been
> very informative and caused me to postpone moving to version 9.
Don't let that stop you! You can get all of the mathematical and
memory management improvements of Maple 9 and continue to use what is
essentially
the Maple 8 GUI interface (now called the Classic interface). You do
not have
to ever use the new interface unless you want to use some of the new
GUI features.
> I suspect that the folks at Maple are keenly aware of what version 9's
> sales are compared to other releases. That information in conjunction
> with the many complaints they have seen...
How do you know that they (the management) have seen the complaints?
They do not provide any indication that they read this news group.
>... get the point across about dissatisfaction with a buggy
interface.
To a large extent, students have to buy the latest version of Maple
just like they have to buy the latest edition of a textbook. It could
be that one bad
version does not have an immediate effect on sales. It could be that
the
effect is only felt when university math departments stop using Maple
in
undergraduate classes, and this will likely not happen until 1 or 2
years
after the bad version is released.
> If one wants to have a real effect on Maplesoft's management, I
> suggest typing a letter on real paper and sending it via real mail to
> the president of Maplesoft.
People often say that, but it makes no sense to me. The only
effective ways to make organizations change are public criticism
(boycotts, strikes, journalism, etc.), litigation, and military or
police action. It is only the exceptional
CEO that listens to the individual customer, and such CEOs are
noteworthy
enough that they write articles about that person in _Forbes_, _Inc._,
etc.
> Email is nice, real paper makes an impact.
That is certainly true for some. Personally, I despise receiving
paper mail, and the majority of it gets discarded unopened. Of the
remainder that seems
like it might be too important to discard, the majority is not opened
for at
least a month. I loathe putting things in the mail, and lose respect
for
organizations that do not accept electronic forms or payment and
communication.
Also, for all those people who send me private email about my postings
to this group: Unless they are truly of a private nature, I would much
rather that you post them to the group. Saying something in private I
see as pretty much a
waste of time when it could have been said in public. Yes, I know
that sometimes for legal reasons things cannot be said in public.
That is fine.
> However, I do not curse the darkness. Instead I attempt to light a
> candle. I notify Maplesoft when I find a bug so that they are aware
> of it. They have always responded that they have checked and that the
> bug exists. I refrain from whining because it is not constructive. I
> recognize that Maplesoft is staffed by humans who have more work to do
> than time available (that is the human condition ? work expands to
> completely the time available), and that priorities must be
> established.
Most companies ultimately go out of business -- that is part of the
human
condition also. I very much want to prevent that -- I have too much
intellectual investment in Maple, and I think that it is a great
program even though it has some bugs. I think that some posters to
this group
want Maplesoft to go out of business. You make it sound as if the
management
at Maplesoft is rational and is doing the right things for the
business. It
is extremely difficult to tell because they are so silent.
Harald Pleym
dev...@math.udel.edu (Carl Devore) wrote in message news:<3a64b911.0312...@posting.google.com>...
> flatir...@yahoo.com (RockyLake) wrote:
> > The many postings on problems with version 9's interface have been
> > very informative and caused me to postpone moving to version 9.
You are not alone to do that. I have been told that a lot of Maple
users have got enough of the bad new Maple 9 Java GUI.
>
> Don't let that stop you! You can get all of the mathematical and
> memory management improvements of Maple 9 and continue to use what is
> essentially
> the Maple 8 GUI interface (now called the Classic interface).
The question is how long it is possible to use the Classic interface.
What I have been told is: "Maplesoft will keep Classic around for at
least another release and after that for as long as they need to". And
no one knows what they intend to do.
And as far as I know Maplesoft will only fix the most serious bugs in
the Classic version of Maple 9. And there is a lot of bugs in the
Classic version.
They will only give priority to the new Java GUI, which I think will
give Maplesoft problems for years from now.
Maple 9.03 is still useless for me and my students, mainly because of
still serious problems to get hyperlinks in Maple 8 worksheets to
work when loaded with Maple 9 Java GUI. And in addition we have to
wait for a long time
to get worksheets to pop up. All I have talked to have no confident to
Java as a GUI. It seems to me that MapleSoft have a very long time to
go within they can provide us with a computational tool is it poosible
to live with at the same level as for instance Mathematica and Matlab.
> You do not have
> to ever use the new interface unless you want to use some of the new
> GUI features.
It is not at all a question of "want to use ..". We are really
prevented from using the new GUI due to all the serious bugs already
mentioned.
> How do you know that they (the management) have seen the complaints?
> They do not provide any indication that they read this news group.
They should, and they should also have learned from the bad
experiences up to know.
> It could be that one bad version does not have an immediate effect on >sales. It could be that the effect is only felt when university math >departments stop using Maple in undergraduate classes, and this will likely not happen until 1 or 2 years after the bad version is released.
If Maplesoft still ignore all feedbacks from users, I think Maple will
be off the market in few years.
> > If one wants to have a real effect on Maplesoft's management, I
> > suggest typing a letter on real paper and sending it via real mail to
> > the president of Maplesoft.
I don't think at all that will work, it will run off like water off a
duck's back. Sorry to say, but I think Maplesofts days are numbered.
Cheers,
Harald Pleym
Vladimir Bondarenko
Happy birthday,
happy birthday,
happy birthday to you,
o stupid Maple bug!
Many returns of the day!
Laurent Bernardin, a Chief Scientist and VP, Research and
Development, Adjunct Professor, Dept. of Pure Mathematics,
University of Waterloo. claims:
http://bernardin.com/maple/index.php
LB> Being strict about backwards compatibility can be frustrating
LB> for our developers. A common comment I hear, is: "It would
LB> really be easier to make this command work better, if I would
LB> not have to worry about compatibility". This is a good sign.
LB> It means the issue is taken seriously at all levels. It also
LB> means that we are finding ways to move Maple forward and
LB> improve the system without breaking existing user code.
Peter Luschny proposed on Dec 23 2003 a splendid idea
http://groups-beta.google.com/group/comp.soft-sys.math.maple/msg/572265481f09ebe5
PL> Vladimir's marketing is not perfect, yet. But what
PL> about the slogan: "Maple - unsafe at any evaluation"?
Oh yes!
This is a hot piece of news on 2003 Peter's remarkable
extended comments.
PL> If we have to start to fix even the constant functions
PL> in Maple first, we can very well refrain from using
PL> Maple at all.
PL> Second: Can you tell us how many software out there,
PL> build since
PL> Maple V, Release 3, IBM INTEL NT, Jan 10, 1994
PL> ** 10 years now, happy birthday **
PL> use explicit or implicit this function and is
PL> by this very fact buggy? How can you help them?
PL> You can't.
PL> Most of them will never be aware of this fact but
PL> all of them might be bitten some day by the bug.
PL> And third: I did not really expect a bug fix, but a
PL> comment, what might be so fundamentally wrong at
PL> Maplesoft, that they cannot even guarantee a
PL> constant function to have a constant value.
PL> The usual blah-blah of inherent complexity etc.
PL> used to exculpate inability, is obviously not
PL> applicable here.
After only 10 years of its existence, in Maple 9.5.2 the bug
with euler(0,1) reported by Peter was fixed...
euler(0,1);
-------------------- (2004) Maple 9.5.2 ----------------------
1
-------------------- (2004) Maple 9.5 ------------------------
1
-------------------- (2003) Maple 9 --------------------------
-1
-------------------- (2002) Maple 8 --------------------------
-1
-------------------- (2001) Maple 7 --------------------------
-1
-------------------- (2000) Maple 6 --------------------------
-1
-------------------- (1997) Maple V Rel 5 --------------------
-1
-------------------- (1995) Maple V Rel 4 --------------------
-1
-------------------- (1994) Maple V Rel 3 --------------------
-1
---------------------------------------------------------------
Was fixed... partially!
And this (partial, jury-rigged, quick-fix) approach is TYPICAL for
Maplesoft. Read the Maple Review coming very soon for details.
Here is the bug, alive and kickin'!
limit(euler(z,1), z=0);
-------------------- (2004) Maple 9.5.2 ----------------------
-1
-------------------- (2004) Maple 9.5 ------------------------
-1
-------------------- (2003) Maple 9 --------------------------
-1
-------------------- (2002) Maple 8 --------------------------
-1
-------------------- (2001) Maple 7 --------------------------
-1
-------------------- (2000) Maple 6 --------------------------
-1
-------------------- (1997) Maple V Rel 5 --------------------
-1
-------------------- (1995) Maple V Rel 4 --------------------
-1
-------------------- (1994) Maple V Rel 3 --------------------
-1
---------------------------------------------------------------
Maplesoft> Maple 9.5: Standard for any type of mathematics
He-he... A zero cool slogan. The only rub is that it is
not implemented in real life.
Read much more about the 'standard' Maplesoft proposes us
to use, in the immediate future.
All this is just the very beginning,
Vladimir Bondarenko
VM and GEMM architect
Co-founder, CEO, Mathematical Director
Cyber Tester, LLC
Peter Luschny
> limit(euler(z,1), z=0);
Oh, what an interesting question are you investigating!
Are these the confluent Euler Polynomials?
Well, I do not know how Maplesoft defines euler(s,z),
s not an integer, therefore I will take my own approach.
> restart;
> E := proc(s,z) z^s*(4^(s+1)*Zeta(0,-s,1/(4*z))
> - 2^(s+1)*Zeta(0,-s,1/(2*z))) end:
> `E(s,z)`=E(s,z);
Let's get a first impression what this looks like for s=0:
> plot(E(s,1),s=-1/2..1/2);
Seems as if E(0,1) = 1. And indeed:
> E(0,1);
1
Fine! So let us compute next:
> limit(E(s,1),s=0,real);
-2
Uhh, now I am confused. :-/
Well, I am using Maple V Release 5,
perhaps I should upgrade?
Regards Peter
A N Niel
<peter....@gmx.net> wrote:
> "Vladimir Bondarenko" tested yesterday:
>
> > limit(euler(z,1), z=0);
>
> Oh, what an interesting question are you investigating!
> Are these the confluent Euler Polynomials?
>
> Well, I do not know how Maplesoft defines euler(s,z),
> s not an integer, therefore I will take my own approach.
According to ?euler ...
euler(n, x)
n - non-negative integer
x - expression
So it seems putting in a non-integer is not supported...
> euler(1/4,x);
Error, (in euler) invalid arguments
>
> > restart;
> > E := proc(s,z) z^s*(4^(s+1)*Zeta(0,-s,1/(4*z))
> > - 2^(s+1)*Zeta(0,-s,1/(2*z))) end:
> > `E(s,z)`=E(s,z);
>
> Let's get a first impression what this looks like for s=0:
> > plot(E(s,1),s=-1/2..1/2);
>
> Seems as if E(0,1) = 1. And indeed:
> > E(0,1);
> 1
>
> Fine! So let us compute next:
> > limit(E(s,1),s=0,real);
> -2
>
> Uhh, now I am confused. :-/
>
Here's _your_ problem:
> restart;Zeta(0,-1,1/4);limit(Zeta(0,x,1/4),x=-1);
1
--
96
-1
--
12
Maple 9.52.
The mitigation I find is in ?Zeta...
Zeta(n, z, v)
v - algebraic expression, understood not to be a non-positive
integer
and 1/4 isn't an integer. But:
> Zeta(0,-1,1);
-1
--
12
so we were given the value at a nearby integer ... ???
I guess that's our punishment for going outside the intended domain of
definition.
Peter Luschny
> > Peter Luschny wrote:
> > Well, I do not know how Maplesoft defines euler(s,z),
> > s not an integer, therefore I will take my own approach.
> According to ?euler ...
> euler(n, x)
> n - non-negative integer
> x - expression
> So it seems putting in a non-integer is not supported...
Yes, and I did not assume that Maple would provide such
a generalization. As I said. "...therefore I will take
my own approach."
> > > E := proc(s,z) z^s*(4^(s+1)*Zeta(0,-s,1/(4*z))
> > > - 2^(s+1)*Zeta(0,-s,1/(2*z))) end:
> > > limit(E(s,1),s=0,real);
> > > -2
> I guess that's our punishment for going outside the intended domain of
> definition.
I do not understand this remark. Outside the intended domain
of the Zeta function? How that? I am looking at Zeta(0,s,1/4)
and Zeta(0,s,1/2) in a neighborhood of zero.
Zeta(n,z,v)
n - an expression, understood to be a non-negative integer
z - an expression
v - an expression, understood not to be a non-positive integer
n - 0 is a non-negative integer
z - z is extended to the complex plane less the point 1
by analytic continuation, so a neighborhood of 0 is included.
v - 1/2 and 1/4 are not non-positive integers.
> But: Zeta(0,-1,1);
> -1
> --
> 12
> so we were given the value at a nearby integer ... ???
What does this mean?
Zeta(0,-1,x) = -1/12 - 1/2 x^2 + 1/2 x
Do you want to say that Maple regards polynomials only
defined at nearby integers?
Regards Peter
Wilbert Dijkhof
Peter Luschny wrote:
>
> Zeta(n,z,v)
> n - an expression, understood to be a non-negative integer
> z - an expression
> v - an expression, understood not to be a non-positive integer
>
> n - 0 is a non-negative integer
> z - z is extended to the complex plane less the point 1
> by analytic continuation, so a neighborhood of 0 is included.
> v - 1/2 and 1/4 are not non-positive integers.
>
> > But: Zeta(0,-1,1);
> > -1
> > --
> > 12
> > so we were given the value at a nearby integer ... ???
>
> What does this mean?
>
> Zeta(0,-1,x) = -1/12 - 1/2 x^2 + 1/2 x
>
> Do you want to say that Maple regards polynomials only
> defined at nearby integers?
>
> Regards Peter
"z is extended to the complex plane less the point 1 (thus
except z=1) by analytic continuation"
That should answer it.
Wilbert
Peter Luschny
>> Peter Luschny wrote:
>> Zeta(n,z,v)
>> n - an expression, understood to be a non-negative integer
>> z - an expression
>> v - an expression, understood not to be a non-positive integer
> "z is extended to the complex plane less the point 1 (thus
> except z=1) by analytic continuation"
> That should answer it.
Answer what? My question was:
>> Let
>> E := proc(s,z) z^s*(4^(s+1)*Zeta(0,-s,1/(4*z))
>> - 2^(s+1)*Zeta(0,-s,1/(2*z))) end:
Then Maple computes
E(0,1) = 1 and limit(E(s,1),s=0,real) = -2.
Is this ok? Do you think your comment answers this?
(s + 1) (s + 1) (-s)
E(s,1) = 4 Zeta(0, -s, 1/4) - 2 (2 - 1) Zeta(-s)
> subs(s=0,E(s,1)) = 4 Zeta(0, 0, 1/4)
Or look at
> limit(4^(s+1)*Zeta(0,-s,1/4),s=0); and
> plot(4^(s+1)*Zeta(0,-s,1/4),s=-1/2..1/2);
Sorry, but I am still confused. Maybe I am missing something.
Regards Peter
Peter Luschny
> Hi Maple customers all over the world,
> After 10 years of its existent, in Maple 9.5.2 the bug with
> euler(0,1) reported by Peter was fixed...
> euler(0,1);
> -------------------- (2004) Maple 9.5.2 ----------------------
> 1
Hurrah, Maple quality improves! ;-)
PL> Well, I do not know how Maplesoft defines euler(s,z),
PL> s not an integer, therefore I will take my own approach.
PL> E := proc(s,z) z^s*(4^(s+1)*Zeta(0,-s,1/(4*z))
PL> - 2^(s+1)*Zeta(0,-s,1/(2*z))) end:
Just to explain a little bit, what this function does:
it is a generalization of the Euler numbers and gives
us a way to compute the Euler numbers with Maple without
using the Maple 'euler' function, which is known to be buggy
in almost all Maple releases, as your foregoing posting shows.
> seq(E(i,1),i=0..10);
> seq(euler(i),i=0..10);
1, 0, -1, 0, 5, 0, -61, 0, 1385, 0, -50521
1, 0, -1, 0, 5, 0, -61, 0, 1385, 0, -50521
> seq(2^i*E(i,1/2)/i!,i=0..11);
> seq(2^i*euler(i,1)/i!,i=0..11);
-17 62 -1382
1, 1, 0, -1/3, 0, 2/15, 0, ---, 0, ----, 0, ------
315 2835 155925
-17 62 -1382
-1, 1, 0, -1/3, 0, 2/15, 0, ---, 0, ----, 0, ------
315 2835 155925
> series(1+tanh(x),x,12);
3 5 17 7 62 9 1382 11
1 + x - 1/3 x + 2/15 x - --- x + ---- x - ------ x + ..
315 2835 155925
Note that the Maple coders did not even use such a well known relation
as the one given between the expansion of 1 + tanh(x) and the Euler
polynomials to check their code! 'Test Driven Development' does not
seem to be much appreciated in Waterloo.
In an test driven development Maple's 'Decadium Bug' would not
have even reached the beta build (sorry for you, Vladimir ;-)
However, a workaround for a Maple bug might again be buggy
because of another Maple bug, as we have seen:
Maple (VR5) computes E(0,1) = 1 and limit(E(s,1),s=0,real) = -2.
By the way, Mathematica 5.0 does it right:
In[1] = F[s_, z_] := z^s(4^(s+1)Zeta[-s,1/(4z)]- 2^(s+1)Zeta[-s,1/(2z)])
In[3] = F[0,1] Out[3]= 1
In[4] = Limit[F[s,1],s->0] Out[4]= 1
In[5] = Limit[F[s,1],s->0,Direction->-1] Out[5]= 1
In[6] = Limit[F[s,1],s->0,Direction->1] Out[6]= 1
Ok, this is the first part of the story. The second part
follows immediately. We have not looked at the Euler
polynomials yet.
First the definition:
EP := proc(s,z) z^s*E(s,1/(2*z)) end;
The meaning is clear:
> seq(EP(i,z),i=0..4);
2 2 3 3 4
1, z - 1/2, z - z, 1/4 - 3/2 z + z , z - 2 z + z ,
> seq(euler(i,z),i=0..4);
2 2 3 3 4
1, z - 1/2, z - z, 1/4 - 3/2 z + z , z - 2 z + z ,
VB> Here is the bug, alive and kickin'!
VB> limit(euler(z,1), z=0); -> -1
But what does limit(euler(z,1), z=0) mean, exactly?
Now our version:
limit(EP(z,1), z=0); -> 1
It works! Even with good ol' buggy Maple! ;-)
And we have assigned an exact meaning to the limit:
lim EP(z,1) = lim (2 - 4*2^z) Zeta(-z) = 1
z->0 z->0
Regards Peter