31 views

Skip to first unread message

Dec 22, 2003, 5:14:35 PM12/22/03

to

Hi everyone,

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/

.............................................................................

Dec 22, 2003, 11:20:58 PM12/22/03

to

"Vladimir Bondarenko" <v...@cybertester.com> wrote in message

news:8cf8cf57.03122...@posting.google.com...

>

> PL> euler(0,1); # Sure, this must be equal to 1

> -1

>

news:8cf8cf57.03122...@posting.google.com...

>

> 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."

> "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

Dec 23, 2003, 5:39:57 AM12/23/03

to

> "Alec Mihailovs" wrote:

> > "Vladimir Bondarenko"

> > "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

Dec 23, 2003, 10:55:06 AM12/23/03

to

"Peter Luschny" <peter....@gmx.net> wrote in message

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.

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

Dec 23, 2003, 4:37:48 PM12/23/03

to

> "Alec Mihailovs" wrote:

> > "Peter Luschny" wrote:

> > > "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.

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

Dec 23, 2003, 6:44:37 PM12/23/03

to

"Peter Luschny" <peter....@gmx.net> wrote in message news:<bs95sd$at4b0$1...@ID-64349.news.uni-berlin.de>...

PL> And third: I did not really expect a bug fix

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

Dec 23, 2003, 9:21:54 PM12/23/03

to

"Peter Luschny" <peter....@gmx.net> wrote in message

news:bsacce$baq5h$1...@ID-64349.news.uni-berlin.de...>

> 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

Dec 24, 2003, 11:41:32 AM12/24/03

to

... Snip ...

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.

> 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> 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.

Dec 24, 2003, 1:10:23 PM12/24/03

to

RockyLake <flatir...@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.

Hear, hear - very well said!

--

John Cordes

Dec 27, 2003, 6:08:34 PM12/27/03

to

"Alec Mihailovs" <al...@mihailovs.com> wrote:

> 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.

> 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.

Dec 28, 2003, 7:20:44 AM12/28/03

to

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.

> 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.

Dec 28, 2003, 1:48:36 PM12/28/03

to

A few comments:

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

Message has been deleted

Mar 14, 2005, 8:35:38 AM3/14/05

to

Hi Maple customers all over the world,

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

Mar 15, 2005, 6:52:26 AM3/15/05

to

"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.

> 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

Mar 15, 2005, 8:16:16 AM3/15/05

to

In article <39o0iqF...@individual.net>, Peter Luschny

<peter....@gmx.net> wrote:

<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.

Mar 15, 2005, 12:01:09 PM3/15/05

to

> "A N Niel" wrote:

> > Peter Luschny 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?

Regards Peter

Mar 15, 2005, 12:27:33 PM3/15/05

to

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

Mar 15, 2005, 4:15:03 PM3/15/05

to

> "Wilbert Dijkhof" wrote:

>> Peter Luschny 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.

Regards Peter

Mar 17, 2005, 4:08:54 AM3/17/05

to

> 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.

> 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

Reply all

Reply to author

Forward

0 new messages

Search

Clear search

Close search

Google apps

Main menu