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."
> PL> euler(0,1); # Sure, this must be equal to 1 > -1
> 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."
As usual, this can be easily fixed:
myeuler:=n-> if n=0 then 1 else euler(args) fi: myeuler(0,1);
> "Alec Mihailovs" wrote: > > "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.
> > "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 Mihailovs" wrote: > > "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.
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.."
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...
> 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 supp...@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
> 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.
> And remember, if there will not be the fix within these > 20-25 years to come, they say, there is afterlife.
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.
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.
RockyLake <flatironsv...@yahoo.com> wrote: > 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.
"Alec Mihailovs" <a...@mihailovs.com> wrote: > Bug hunters, if they are interested in future development of Maple, should > submit their bugs to > supp...@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.
flatironsv...@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.
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.
dev...@math.udel.edu (Carl Devore) wrote in message <news:3a64b911.0312280420.4396f5f@posting.google.com>... > flatironsv...@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.
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
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 --------------------
> > > 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.
> "A N Niel" wrote: > > 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?
> 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"
> "Wilbert Dijkhof" wrote: >> 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.
> Vladimir Bondarenko" wrote: > 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.
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.
|
