Welcome to the wide world of idiocy with Maplesoft
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level
of support for the products it sells"
...............................................................
DESCRIPTION: None of Maple versions since at least 1994 on
can calculate this CHILD LEVEL limit correctly.
TEST CASE: limit(1/(sin(z)^2+cos(z)^2), z= infinity);
EXPECTED: 1
CHECKUP: limit(1/(sin(z)^2+cos(z)^2), z= 100.);
limit(1/(sin(z)^2+cos(z)^2), z= 1000.);
limit(1/(sin(z)^2+cos(z)^2), z= 10000.);
1.000000000
1.000000000
1.000000000
--------------- (2005) Maple 10.00 ------------------------------
undefined
--------------- (2004) Maple 9.5.1 ------------------------------
undefined
--------------- (2004) Maple 9.5 --------------------------------
undefined
--------------- (2003) Maple 9 ----------------------------------
undefined
--------------- (2002) Maple 8 ----------------------------------
undefined
--------------- (2001) Maple 7 ----------------------------------
undefined
--------------- (2000) Maple 6 ----------------------------------
undefined
--------------- (1997) Maple V Rel 5 ----------------------------
undefined
--------------- (1995) Maple V Rel 4 ----------------------------
undefined
--------------- (1994) Maple V Rel 3 ----------------------------
undefined
------------------------------------------------------------------
COMPARE: Axiom 3, Derive 6.1, Mathematica 5.2, Maxima
5.9.3, and MuPAD 4.0 return the correct answer.
limit(1/(sin(z)^2+cos(z)^2), z= %plusInfinity)
LIM(1/(SIN(z)^2+COS(z)^2),z,inf)
Limit[1/(Sin[z]^2 + Cos[z]^2), z -> Infinity]
limit(1/(sin(z)^2+cos(z)^2),z,inf);
limit(1/(sin(z)^2+cos(z)^2), z= infinity);
1
1
1
1
1
...............................................................
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells,
next evidences
http://groups.google.com/group/sci.math.symbolic/browse_frm/thread/e7f7079a987c8a3f/1bc7f8a74f6987ee#1bc7f8a74f6987ee
...............................................................
First world's Man+Machine Based Maple Crisis Review (beta 0.1)
http://maple.bug-list.org/maple-crisis.php
(beta 0.2 is already of 500+ pages... selected of the selected)
...............................................................
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level
of support for the products it sells"
...............................................................
DESCRIPTION: None of Maple versions since at least 1994 on
can calculate this CHILD LEVEL input correctly.
TEST CASE: is(1, continuous);
EXPECTED: true
CHECKUP: plot(1, z=1/10^3..10^3);
--------------- (2005) Maple 10.00 ---------------------------
false
--------------- (2004) Maple 9.5.1 ---------------------------
false
--------------- (2004) Maple 9.5 -----------------------------
false
--------------- (2003) Maple 9 -------------------------------
false
--------------- (2002) Maple 8 -------------------------------
false
--------------- (2001) Maple 7 -------------------------------
false
--------------- (2000) Maple 6 -------------------------------
false
--------------- (1997) Maple V Rel 5 -------------------------
false
--------------- (1995) Maple V Rel 4 -------------------------
false
--------------- (1994) Maple V Rel 3 -------------------------
false
---------------------------------------------------------------
...............................................................
DESCRIPTION: None of Maple versions since at least 1994 on
can calculate this CHILD LEVEL input correctly.
TEST CASE: assume(z>0):
is(z/z, continuous);
EXPECTED: true
CHECKUP: plot(z/z, z=1/10^3..10^3);
--------------- (2005) Maple 10.00 ---------------------------
false
--------------- (2004) Maple 9.5.1 ---------------------------
false
--------------- (2004) Maple 9.5 -----------------------------
false
--------------- (2003) Maple 9 -------------------------------
false
--------------- (2002) Maple 8 -------------------------------
false
--------------- (2001) Maple 7 -------------------------------
false
--------------- (2000) Maple 6 -------------------------------
false
--------------- (1997) Maple V Rel 5 -------------------------
false
--------------- (1995) Maple V Rel 4 -------------------------
false
--------------- (1994) Maple V Rel 3 -------------------------
false
---------------------------------------------------------------
alainv...@yahoo.fr
Vladimir Bondarenko a écrit :
> ..Cher Vladimir,
Which brand of math software are you selling?
Alin(ova)...........................................................
Vladimir Bondarenko
We sell none brand of math software whatsoever.
Sincerely,
Vladimir
--
Vladimir Bondarenko
VM and GEMM architect
Co-founder, CEO, Mathematical Director
http://www.cybertester.com/ Cyber Tester, LLC
http://maple.bug-list.org/ Maple Bugs Encyclopaedia
http://www.CAS-testing.org/ CAS Testing
Robert Israel
Vladimir Bondarenko <v...@cybertester.com> wrote:
>
>DESCRIPTION: None of Maple versions since at least 1994 on
> can calculate this CHILD LEVEL input correctly.
>
>TEST CASE: is(1, continuous);
>
>EXPECTED: true
Maple knows about properties such as "continuous" only for certain
named functions such as sin and exp, which are indices of the
table `property/object`. It has no mechanism to decide whether an
arbitrary function or expression is continuous.
The fact that is(1, continuous) returns false rather than FAIL is
a bug, but asking it to return true is a bit much: this is
functionality that Maple simply doesn't have. And it's not
entirely Maple's fault: there is no algorithm to decide whether an
elementary function, even in some very restricted classes, has a
real zero, and therefore no algorithm to decide whether its reciprocal
is continuous on the reals. See e.g. Paul S. Wang, "The
Undecidability of the Existence of Zeros of Real Elementary Functions",
JACM 21 (1974) 586-589
<http://portal.acm.org/citation.cfm?doid=321850.321856>.
Robert Israel isr...@math.ubc.ca
Department of Mathematics http://www.math.ubc.ca/~israel
University of British Columbia Vancouver, BC, Canada
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level
of support for the products it sells"
................................................................
DESCRIPTION: None of Maple versions since at least 1994 on
can approximate this CHILD LEVEL integral
correctly.
TEST CASE: evalf(Int(1/(exp(-z)*z^20 + 1), z=0..infinity));
EXPECTED: Float(infinity)
CHECKUP: evalf(Int(1/(exp(-z)*z^20 + 1), z=0..10^1000));
.5000000000e1000
--------------- (2005) Maple 10.00 ----------------------------
1.059245633
--------------- (2004) Maple 9.5.1 ----------------------------
1.059245633
--------------- (2004) Maple 9.5 ------------------------------
1.059245633
--------------- (2003) Maple 9 --------------------------------
1.059245633
--------------- (2002) Maple 8 --------------------------------
1.059245633
--------------- (2001) Maple 7 --------------------------------
1.059245633
--------------- (2000) Maple 6 --------------------------------
1.059245633
--------------- (1997) Maple V Rel 5 --------------------------
1.059245633
--------------- (1995) Maple V Rel 4 --------------------------
1.059245633
--------------- (1994) Maple V Rel 3 --------------------------
1.059245633
----------------------------------------------------------------
COMPARE: Mathematica 5.2 warns the customer about the
potential divergence.
NIntegrate[1/(Exp[-z] z^20 + 1), {z,0,Infinity}]
NIntegrate failed to converge to prescribed
accuracy after 7 recursive bisections
1.24065517836 10^3498
................................................................
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells,
next evidences
................................................................
First world's Man+Machine Based Maple Crisis Review (beta 0.1)
http://maple.bug-list.org/maple-crisis.php
(beta 0.2 is already of 500+ pages... selected of the selected)
................................................................
Axel Vogt
We already had such things: hazardous numerics. Increase
precision (then also MMA will return inf I guess) or use
symbolics before numerics. And generally consider some
splitting ]0,inf[ into 2 parts for such stuff.
OwlHoot
Vladimir Bondarenko wrote:
> ...............................................................
>
> http://www.maplesoft.com/support/
>
> "Maplesoft is committed to providing the highest level
> of support for the products it sells"
For Pete's sake, if anyone from Maplesoft is reading this,
can't you just hire this Vladimir Bonkerenko for your testing
department. Anything to shut him up!
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level
of support for the products it sells"
Hell NO.
...............................................................
DESCRIPTION: Yet another Maple regression bug, one of MANY
1000s regression bugs unfixed over many years.
Only Maple 8 of 2002 and Maple 7 of 2000 can
calculate this CHILD multiplication correctly.
TEST CASE: 0 * 10000000!;
EXPECTED: 0
CHECKUP: product(i, i= 0..10000000);
0
--------------- (2005) Maple 10.00 ---------------------------
Error, (in fact) Cannot allocate memory (size=104873984)
--------------- (2004) Maple 9.5.1 ---------------------------
Error, (in fact) Cannot allocate memory (size=104873984)
--------------- (2004) Maple 9.5 -----------------------------
Error, (in fact) Cannot allocate memory (size=104873984)
--------------- (2003) Maple 9 -------------------------------
Error, (in fact) Cannot allocate memory (size=104873984)
--------------- (2002) Maple 8 -------------------------------
0
--------------- (2001) Maple 7 -------------------------------
0
--------------- (2000) Maple 6 -------------------------------
Error, object too large for factorial
--------------- (1997) Maple V Rel 5 -------------------------
Error, object too large
--------------- (1995) Maple V Rel 4 -------------------------
Error, object too large
--------------- (1994) Maple V Rel 3 -------------------------
Error, object too large
---------------------------------------------------------------
COMPARE: Derive 6 and Mathematica 5.2 return the correct
answer.
0*10000000!
0*10000000!
0
0
...............................................................
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells
Maplesoft is committed to providing the highest level
Robert Israel
Vladimir Bondarenko <v...@cybertester.com> wrote:
>DESCRIPTION: Yet another Maple regression bug, one of MANY
> 1000s regression bugs unfixed over many years.
>
> Only Maple 8 of 2002 and Maple 7 of 2000 can
> calculate this CHILD multiplication correctly.
>
>TEST CASE: 0 * 10000000!;
>
>EXPECTED: 0
Remember that computers may be our faithful servants, but ultimately
are not intelligent. They mostly do literally what we ask them to do,
but they can't read minds to figure out our true intentions. When they
do deviate from literally following instructions, it often happens that
the result is a bug. In this case, Maple is simply trying to follow
instructions: take 0, calculate 10000000!, and multiply the two.
Not surprisingly, it comes to grief calculating that enormous
factorial. It didn't notice the shortcut that 0*x = 0, so it didn't
need to calculate the factorial after all. A pity, you say? And what
about Maple 7 and Maple 8? Apparently, automatic simplification there
replaces anything of the form 0*x with 0, without evaluating x.
Well, it's simply not correct to say that 0*x should automatically be
0. What about if (after some computation) x turns out to be infinity or
undefined? Then the result should be undefined, not 0. So the Maple
7 and 8 behaviour turns out to be a bug. I suspect that the automatic
simplification of 0*x to 0 was actually removed to fix this bug, or a
similar one.
Peter Luschny
>> Vladimir Bondarenko <v...@cybertester.com> wrote:
>> DESCRIPTION: Yet another Maple regression bug, one of MANY
>> 1000s regression bugs unfixed over many years.
>> Only Maple 8 of 2002 and Maple 7 of 2000 can
>> calculate this CHILD multiplication correctly.
>> TEST CASE: 0 * 10000000!;
>> EXPECTED: 0
> Remember that computers may be our faithful servants, but ultimately
> are not intelligent. They mostly do literally what we ask them to do,
> but they can't read minds to figure out our true intentions. When they
> do deviate from literally following instructions, it often happens that
> the result is a bug. In this case, Maple is simply trying to follow
> instructions: take 0, calculate 10000000!, and multiply the two.
(*) 10000000! = 1.2024 E 65657059
> Not surprisingly, it comes to grief calculating that enormous
> factorial.
Sounds reasonable, but it is not. It will take some moments, true,
(exactly 487 seconds on my system, using a fairly simple routine
and some freely available arithmetic library), but there is no
reason why a CAS at the state of art should not provide an answer
within this time-frame even on a moderately equipped system like mine (**).
> It didn't notice the shortcut that 0*x = 0, so it didn't
> need to calculate the factorial after all. A pity, you say?
Vladimir said: "Only Maple 8 of 2002 and Maple 7 of 2000 can
calculate this CHILD multiplication correctly."
> And what about
> Maple 7 and Maple 8? Apparently, automatic simplification there
> replaces anything of the form 0*x with 0, without evaluating x.
> Well, it's simply not correct to say that 0*x should automatically be
> 0.
Just for the record: Vladimir did not propose this.
> What about if (after some computation) x turns out to be infinity or
> undefined? Then the result should be undefined, not 0. So the Maple
> 7 and 8 behaviour turns out to be a bug.
Not necessarily. What Maple could do is:
type(100000,nonnegint); -> true
type(0,nonnegint); -> true
This works with my Maple VR5. With this available information (and
the specification of n!) it would be Ok to return 0, wouldn't it?
> I suspect that the automatic
> simplification of 0*x to 0 was actually removed to fix this bug, or a
> similar one.
So if the 'automatic simplification' was an unqualified one
they fixed a bug but did not enhance the CAS. However, they
worsened things, if the implementation of Maple 7 and 8 was a
reasonable one. It seems that you exclude this possibility
altogether. Since you are a profound adept of Maple you have
certainly good reasons for this estimation.
Regards Peter
(*) http://www.luschny.de/math/factorial/fffcalc.html
(**) http://www.luschny.de/math/factorial/benchmark.html
Vladimir Bondarenko
RI> A pity, you say?
No, not a pity.
Yet another example of an idiotic regression bug
showing clearly some big unsolved problems in the
Maplesoft development process.
Sincerely,
Vladimir Bondarenko
VM and GEMM architect
Co-founder, CEO, Mathematical Director
http://www.cybertester.com/ Cyber Tester, LLC
http://maple.bug-list.org/ Maple Bugs Encyclopaedia
http://www.CAS-testing.org/ CAS Testing
isr...@math.ubc.ca
Peter Luschny wrote:
> >Robert Israel wrote:
> >> Vladimir Bondarenko <v...@cybertester.com> wrote:
>
> >> DESCRIPTION: Yet another Maple regression bug, one of MANY
> >> 1000s regression bugs unfixed over many years.
> >> Only Maple 8 of 2002 and Maple 7 of 2000 can
> >> calculate this CHILD multiplication correctly.
> >> TEST CASE: 0 * 10000000!;
> >> EXPECTED: 0
>
> > Remember that computers may be our faithful servants, but ultimately
> > are not intelligent. They mostly do literally what we ask them to do,
> > but they can't read minds to figure out our true intentions. When they
> > do deviate from literally following instructions, it often happens that
> > the result is a bug. In this case, Maple is simply trying to follow
> > instructions: take 0, calculate 10000000!, and multiply the two.
>
> (*) 10000000! = 1.2024 E 65657059
But as an exact integer, so more than 65 million decimal digits.
> > Not surprisingly, it comes to grief calculating that enormous
> > factorial.
>
> Sounds reasonable, but it is not. It will take some moments, true,
> (exactly 487 seconds on my system, using a fairly simple routine
> and some freely available arithmetic library), but there is no
> reason why a CAS at the state of art should not provide an answer
> within this time-frame even on a moderately equipped system like mine (**).
It depends on details of implementation and available resources.
Another
zero or two before the ! and your system would be swamped too.
> > It didn't notice the shortcut that 0*x = 0, so it didn't
> > need to calculate the factorial after all. A pity, you say?
>
> Vladimir said: "Only Maple 8 of 2002 and Maple 7 of 2000 can
> calculate this CHILD multiplication correctly."
>
> > And what about
> > Maple 7 and Maple 8? Apparently, automatic simplification there
> > replaces anything of the form 0*x with 0, without evaluating x.
> > Well, it's simply not correct to say that 0*x should automatically be
> > 0.
>
> Just for the record: Vladimir did not propose this.
He called it a regression bug, which implies that he regards the
previous
behaviour as correct.
> > What about if (after some computation) x turns out to be infinity or
> > undefined? Then the result should be undefined, not 0. So the Maple
> > 7 and 8 behaviour turns out to be a bug.
>
> Not necessarily. What Maple could do is:
>
> type(100000,nonnegint); -> true
> type(0,nonnegint); -> true
>
> This works with my Maple VR5. With this available information (and
> the specification of n!) it would be Ok to return 0, wouldn't it?
Yes in this particular case, but if it was 0 * (some complicated
expression)!
it might not be so simple to determine that the complicated expression
would
return a nonnegint. In general you might not be able to tell that
without actually
doing the calculation. A general strategy of trying to figure out what
type a
calculation would return before doing the calculation might be
expensive in terms
of efficiency.
> > I suspect that the automatic
> > simplification of 0*x to 0 was actually removed to fix this bug, or a
> > similar one.
>
> So if the 'automatic simplification' was an unqualified one
> they fixed a bug but did not enhance the CAS. However, they
> worsened things, if the implementation of Maple 7 and 8 was a
> reasonable one. It seems that you exclude this possibility
> altogether. Since you are a profound adept of Maple you have
> certainly good reasons for this estimation.
When making a change in complicated software, it's very often the case
that some things are worsened while others improve.
Vladimir Bondarenko
RI> Another zero or two before the ! and your system would be
RI> swamped too.
Which is, definitely, a defect.
Why Derive 6 and Mathematica 5.2 can do this instantly
0 * 100000000000000000000000000000000000000000000000000000000!
0 * 100000000000000000000000000000000000000000000000000000000!
0
0
but Maple (save Maple 7/8) fails miserably?
It's because of Maplesoft massive design, implementation and
quality assurance problems.
Sincerely,
Vladimir Bondarenko
VM and GEMM architect
Co-founder, CEO, Mathematical Director
http://www.cybertester.com/ Cyber Tester, LLC
http://maple.bug-list.org/ Maple Bugs Encyclopaedia
http://www.CAS-testing.org/ CAS Testing
Peter Luschny
> Peter Luschny wrote:
>>> Robert Israel wrote:
>>>> Vladimir Bondarenko <v...@cybertester.com> wrote:
>>>> DESCRIPTION: Yet another Maple regression bug, one of MANY
>>>> 1000s regression bugs unfixed over many years.
>>>> Only Maple 8 of 2002 and Maple 7 of 2000 can
>>>> calculate this CHILD multiplication correctly.
>>>> TEST CASE: 0 * 10000000!;
>>>> EXPECTED: 0
>>> Remember that computers may be our faithful servants, but ultimately
>>> are not intelligent. They mostly do literally what we ask them to do,
>>> but they can't read minds to figure out our true intentions. When they
>>> do deviate from literally following instructions, it often happens that
>>> the result is a bug. In this case, Maple is simply trying to follow
>>> instructions: take 0, calculate 10000000!, and multiply the two.
>> (*) 10000000! = 1.2024 E 65657059
> But as an exact integer, so more than 65 million decimal digits.
Sure. But that's not /so/ frightening if we take into account
the progress in hardware and software in the last ten years.
>>> Not surprisingly, it comes to grief calculating that enormous
>>> factorial.
>> Sounds reasonable, but it is not. It will take some moments, true,
>> (exactly 487 seconds on my system, using a fairly simple routine
>> and some freely available arithmetic library), but there is no
>> reason why a CAS at the state of art should not provide an answer
>> within this time-frame even on a moderately equipped system like mine (**).
> It depends on details of implementation and available resources.
> Another zero or two before the ! and your system would be swamped too.
Yes. But Maple could ask the system: How much memory is available?
Maple often told me something like 'object too big' when in fact
the system could offer gigabytes of (virtual, but this does
not matter) memory. In other words: Maple does not scale well.
>>> It didn't notice the shortcut that 0*x = 0, so it didn't
>>> need to calculate the factorial after all. A pity, you say?
>> Vladimir said: "Only Maple 8 of 2002 and Maple 7 of 2000 can
>> calculate this CHILD multiplication correctly."
>>> And what about
>>> Maple 7 and Maple 8? Apparently, automatic simplification there
>>> replaces anything of the form 0*x with 0, without evaluating x.
>>> Well, it's simply not correct to say that 0*x should automatically be
>>> 0.
>> Just for the record: Vladimir did not propose this.
> He called it a regression bug, which implies that he regards the
> previous behaviour as correct.
Right. But he might innocently and friendly assume, that the
correct behavior was based on a correct implementation.
It seems to me, that /your/ assumptions imply that this
was not the case.
>>> What about if (after some computation) x turns out to be infinity or
>>> undefined? Then the result should be undefined, not 0. So the Maple
>>> 7 and 8 behaviour turns out to be a bug.
>> Not necessarily. What Maple could do is:
>>
>> type(100000,nonnegint); -> true
>> type(0,nonnegint); -> true
>>
>> This works with my Maple VR5. With this available information (and
>> the specification of n!) it would be Ok to return 0, wouldn't it?
> Yes in this particular case, but if it was 0 * (some complicated
> expression)! it might not be so simple to determine that the
> complicated expression would return a nonnegint. In general you
> might not be able to tell that without actually doing the
> calculation. A general strategy of trying to figure out what
> type a calculation would return before doing the calculation
> might be expensive in terms of efficiency.
D'accord. In as much as the 'general strategy' is concerned.
But building a real world CAS like Maple you can not stop there.
You might very well handle 'particular cases' in 'particular ways'.
And the not so particular case of a function of type integer -> integer
is certainly the first candidate for special treatment.
>>> I suspect that the automatic
>>> simplification of 0*x to 0 was actually removed to fix this bug, or a
>>> similar one.
>> So if the 'automatic simplification' was an unqualified one
>> they fixed a bug but did not enhance the CAS. However, they
>> worsened things, if the implementation of Maple 7 and 8 was a
>> reasonable one. It seems that you exclude this possibility
>> altogether. Since you are a profound adept of Maple you have
>> certainly good reasons for this estimation.
> When making a change in complicated software, it's very often the case
> that some things are worsened while others improve.
Again, this is true. And Maplesoft is changing its complicated
software very often. The outcome in many basic cases is documented
in many postings of Vladimir.
Let me sum up my view:
(1) Either Maple, claiming to be top of the pops, should
be able to calculate 0 * 10000000! in under 6 minutes on
a moderate equipped computer (I can do it with snoring
Java on my system) ...
(2) ... or, and of course this is the better alternative,
should have a shortcut implementation in arith-ops which
can handle at least the case of 0 * f(n) for a function
f of type integer -> integer.
Regards Peter
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level
of support for the products it sells"
Sez you!
...............................................................
DESCRIPTION: None of Maple versions since at least 1994 on
can approximate this BABY LEVEL input correctly.
Maple returns a meaningless symbol r .
TEST CASE: g := z -> z: evalf(Sum(g, i= 1..1));
EXPECTED: g
CHECKUP: g := z -> z: evalf(value(Sum(g, i= 1..1)));
g
--------------- (2005) Maple 10.00 ---------------------------
r
--------------- (2004) Maple 9.5.1 ---------------------------
r
--------------- (2004) Maple 9.5 -----------------------------
r
--------------- (2003) Maple 9 -------------------------------
r
--------------- (2002) Maple 8 -------------------------------
r
--------------- (2001) Maple 7 -------------------------------
r
--------------- (2000) Maple 6 -------------------------------
r
--------------- (1997) Maple V Rel 5 -------------------------
r
--------------- (1995) Maple V Rel 4 -------------------------
r
--------------- (1994) Maple V Rel 3 -------------------------
r
---------------------------------------------------------------
...............................................................
"What might be so fundamentally wrong at Maplesoft?"
...............................................................
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells,
next evidences
...............................................................
First world's Man+Machine Based Maple Crisis Review (beta 0.1)
http://maple.bug-list.org/maple-crisis.php
(beta 0.2 is already of 550+ pages... selected of the selected)
...............................................................
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level
of support for the products it sells"
Is there now at least 1 reader who still do believe
this Maplesoft's ad bunk?
If yes, here you are.
...............................................................
DESCRIPTION: None of Maple versions since at least 1994 on
can approximate this CHILD LEVEL integral
correctly.
TEST CASE: evalf(Int(1/exp(-z), z= 0..11000));
EXPECTED: .1735005819e4778
CHECKUP: evalf(int(1/exp(-z), z= 0..11000));
.1735005819e4778
--------------- (2005) Maple 10.00 ---------------------------
Int(1/exp(-1.*z),z = 0. .. 11000.)
--------------- (2004) Maple 9.5.1 ---------------------------
Int(1/exp(-1.*z),z = 0. .. 11000.)
--------------- (2004) Maple 9.5 -----------------------------
Int(1/exp(-1.*z),z = 0. .. 11000.)
--------------- (2003) Maple 9 -------------------------------
Int(1/exp(-1.*z),z = 0. .. 11000.)
--------------- (2002) Maple 8 -------------------------------
Int(1/exp(-1.*z),z = 0. .. 11000.)
--------------- (2001) Maple 7 -------------------------------
Int(1/exp(-1.*z),z = 0. .. 11000.)
--------------- (2000) Maple 6 -------------------------------
Error, (in evalf/int) unable to handle singularity
--------------- (1997) Maple V Rel 5 -------------------------
Error, (in evalf/int) unable to handle singularity
--------------- (1995) Maple V Rel 4 -------------------------
Error, (in evalf/int) unable to handle singularity
--------------- (1994) Maple V Rel 3 -------------------------
Error, (in evalf/int) unable to handle singularity
---------------------------------------------------------------
COMPARE: Mathematica 5.2 returns the correct answer.
NIntegrate[1/Exp[-z], {z, 0, 11000}]
1.73500581927 10^4777
Chip Eastham
Hi, Peter:
I am chagrined to interrupt one of Vladimir's finest
threads with a somewhat off-topic and selfish
request, but your website refers to an article(?)
"Divide, Swing, and Conquer the Factorial" without
further bibliographical data that I could readily
discover.
Is it available or perhaps a coming attraction?
thanks, chip
Peter Pein
> ................................................................
>
> http://www.maplesoft.com/support/
>
> "Maplesoft is committed to providing the highest level
> of support for the products it sells"
>
> Is there now at least 1 reader who still do believe
> this Maplesoft's ad bunk?
>
> If yes, here you are.
>
>
> "What might be so fundamentally wrong at Maplesoft?"
>
> http://groups.google.com/group/sci.math.symbolic/browse_frm/thread/2d78bf66fa2632ed/88be93fc688bd7b8?#88be93fc688bd7b8
>
>
> Maplesoft is committed to providing the highest level
> of blatant lie about support for the products it sells
>
> http://groups.google.com/group/sci.math.symbolic/browse_frm/thread/aa28c5e820f55502/3420cbd5725f952e?#3420cbd5725f952e
>
> Maplesoft is committed to providing the highest level
> of blatant lie about support for the products it sells,
> next evidences
>
> http://groups.google.com/group/sci.math.symbolic/browse_frm/thread/e7f7079a987c8a3f/1bc7f8a74f6987ee#1bc7f8a74f6987ee
>
>
> First world's Man+Machine Based Maple Crisis Review (beta 0.1)
>
> http://maple.bug-list.org/maple-crisis.php
>
> (beta 0.2 is already of 550+ pages... selected of the selected)
>
>
Maple 10:
> restart;
> evalf(Int(1/exp(-z), z= 0..11000),17);
4778
0.17350058192777384 10
>
Peter Pein
> ................................................................
>
> http://www.maplesoft.com/support/
>
> "Maplesoft is committed to providing the highest level
> of support for the products it sells"
>
> Is there now at least 1 reader who still do believe
> this Maplesoft's ad bunk?
>
> If yes, here you are.
>
...
There's a funny variant (Maple 10):
restart;
> evalf(Int(simplify(1/exp(-z)),z=0..11000));
Float(infinity)
Axel Vogt
> Vladimir Bondarenko schrieb:
> >
> > DESCRIPTION: None of Maple versions since at least 1994 on
> > can approximate this CHILD LEVEL integral
> > correctly.
> >
> > TEST CASE: evalf(Int(1/exp(-z), z= 0..11000));
> >
> > EXPECTED: .1735005819e4778
> >
> > CHECKUP: evalf(int(1/exp(-z), z= 0..11000));
> >
> > .1735005819e4778
> >
> >
> > --------------- (2005) Maple 10.00 ---------------------------
> > Int(1/exp(-1.*z),z = 0. .. 11000.)
> >
> > NIntegrate[1/Exp[-z], {z, 0, 11000}]
> >
> > 1.73500581927 10^4777
> >
> > ................................................................
> ...
> There's a funny variant (Maple 10):
> restart;
> > evalf(Int(simplify(1/exp(-z)),z=0..11000));
> Float(infinity)
We already had this: large numbers beyond floating point ability.
Note: it is by design that Maple tries to use hardware floats for
less than 14 Digits (one can discuss, whether a user defined flag
would be better). So that is correct.
Except VB for tests and some novices for lack of feeling for numerics
nobody would do that with small Digits.
And as youself noticed: thing are different by switching to say 17
Digits ...
So VB is quite often repeating the same stuff with different faces.
The thing I dislike is however that once one used higher digits
then it seems to be not quite consistent in behaviour.
If one wants to see, wher maple has problems one can just use
infolevel[`evalf/int`]:=1
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level of
support for the products it sells"
He-he... do you still have at least 1 microgram of belief
in this Maplesoft's ad trash?
If yes, - here you are.
...............................................................
DESCRIPTION: Yet another Maple regression bug, one of MANY
1000s regression bugs unfixed over many years.
None of the Maple versions since 2000 on can
approximate this CHILD integral correctly.
TEST CASE: evalf(Int((1+z)^3000, z= 0..50));
EXPECTED: .8726346918e5121
CHECKUP: evalf(int((1+z)^3000, z= 0..50));
.8726346918e5121
--------------- (2005) Maple 10.00 ---------------------------
Int((1.+z)^3000,z = 0. .. 50.)
--------------- (2004) Maple 9.5.1 ---------------------------
Int((1.+z)^3000,z = 0. .. 50.)
--------------- (2004) Maple 9.5 -----------------------------
Int((1.+z)^3000,z = 0. .. 50.)
--------------- (2003) Maple 9 -------------------------------
Int((1.+z)^3000,z = 0. .. 50.)
--------------- (2002) Maple 8 -------------------------------
Int((1.+z)^3000,z = 0. .. 50.)
--------------- (2001) Maple 7 -------------------------------
Int((1.+z)^3000,z = 0. .. 50.)
--------------- (2000) Maple 6 -------------------------------
Error, (in evalf/int) unable to handle singularity
--------------- (1997) Maple V Rel 5 -------------------------
.8726346918e5121
--------------- (1995) Maple V Rel 4 -------------------------
.8726346923e5121
--------------- (1994) Maple V Rel 3 -------------------------
.8726346923e5121
---------------------------------------------------------------
COMPARE: Mathematica 5.2 and MuPAD 4.0 return
the correct answer.
NIntegrate[(1 + z)^3000, {z, 0, 50}]
numeric::int((1+z)^3000, z= 0..50);
8.726346918 e5120
8.7263469181408 10^5120
...............................................................
Welcome to the wide world of idiocy with Maplesoft
http://groups.google.com/group/sci.math.symbolic/msg/43bf80bbfe43cacc
...............................................................
"What might be so fundamentally wrong at Maplesoft?"
...............................................................
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells
Maplesoft is committed to providing the highest level
Axel Vogt
for larger numbers ...
Here you go:
infolevel[`evalf/int`]:=1: Digits:=16;
evalf(Int((1+z)^3000, z= 0..50));
Digits := 16
evalf/int/CreateProc: Trying makeproc
evalf/int/ccquad: n = 2 integral estimate = .4279046911989726990e5124
n = 6 integral estimate = .3667754495991194567e5123
evalf/int/ccquad: n = 18 integral estimate = .3974346984002012028e5122
error = .3913165898883621958e5119
evalf/int/ccquad: n = 54 integral estimate = .7926215435505586204e5121
error = .4029664405416624960e5117
evalf/int/control: integrand evals = 163
apparent singularity in or near interval of integration
evalf/int/control: search for singularities in the interval of integration
evalf/int/control: _DEFAULT method unsuccessful, try _Dexp
evalf/int/control: splitting interval into 0 .. 25 and 25 .. 50
evalf/int/CreateProc: Trying makeproc
evalf/int/quadexp: "applying double-exponential method"
From quadexp, result = .7206945950175800706e4243 integrand evals = 297 error = .7055716736233386044e4227
evalf/int/CreateProc: Trying makeproc
evalf/int/quadexp: "applying double-exponential method"
From quadexp, result = .8726346918152991824e5121 integrand evals = 296 error = .6621638060604144575e5105
5121
0.8726346918152992 10
Peter Luschny
> Peter Pein wrote:
>> Vladimir Bondarenko schrieb:
>>> TEST CASE: evalf(Int(1/exp(-z), z= 0..11000));
>>> EXPECTED: .1735005819e4778
>>> --------------- (2005) Maple 10.00 ---------------------------
>>> Int(1/exp(-1.*z),z = 0. .. 11000.)
> We already had this: large numbers beyond floating point ability.
> Note: it is by design that Maple tries to use hardware floats for
> less than 14 Digits (one can discuss, whether a user defined flag
> would be better). So that is correct.
I do not understand your argument. Based on your statements
please tell me why this works:
> restart;
> limit(Int(1/exp(-z), z=0..n),n=11000);
> evalf(%);
exp(11000) - 1
4778
.1735005819 10
Robert Israel
Peter Luschny <spam...@luschny.de> wrote:
>Axel Vogt schrieb:
>> Peter Pein wrote:
>>> Vladimir Bondarenko schrieb:
>
>>>> TEST CASE: evalf(Int(1/exp(-z), z= 0..11000));
>>>> EXPECTED: .1735005819e4778
>>>> --------------- (2005) Maple 10.00 ---------------------------
>>>> Int(1/exp(-1.*z),z = 0. .. 11000.)
>
>> We already had this: large numbers beyond floating point ability.
>> Note: it is by design that Maple tries to use hardware floats for
>> less than 14 Digits (one can discuss, whether a user defined flag
>> would be better). So that is correct.
>
>I do not understand your argument. Based on your statements
>please tell me why this works:
>
> > restart;
> > limit(Int(1/exp(-z), z=0..n),n=11000);
> > evalf(%);
>
>exp(11000) - 1
"limit" takes the unevaluated integral and evaluates it
symbolically.
VB's complaint has to do with numerical integration, which
is a completely different matter.
Axel Vogt
My first thought for your question was: evalf(Int) =/ = evalf(limit(Int))
in a 'formal' sense.
Using trace(`limit`) helps to understand showstat(`limit`), which prints
the procedure. Staring at the code I think ... it comes from line 38.
Here (within a try - catch) limit evaluates the argument (and proceeds
if no error occures).
In plain words: it takes eval(Int(1/exp(-z), z=0..n),n = 11000 ).
But this is just symbolic integration, thus your result.
Peter Luschny
Actually I stumbled on "large numbers beyond floating point ability".
I thought you meant 'exp(11000) - 1' is beyond the floating point
ability of Maple.
Now I assume you mean the 'default' parameter # in
evalf(Int(1/exp(-z), z=0..11000), #);
Then I agree with you. The default value is not adequate
for this problem and it is indeed the responsibility of
the user to choose an appropriate value.
So here is the mixture I get:
> evalf(Int(1/exp(-z), z=0..11000),24);
> evalf(%);
> evalf(%%,48);
11000
/
| 1
| ---------- dz
| exp(-1. z)
/
0
Error, (in evalf/int) unable to handle singularity
4778
.1735005819 10
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level of
support for the products it sells"
Tell us another.
...............................................................
DESCRIPTION: Yet another Maple regression bug, one of MANY
1000s regression bugs unfixed over many years.
TEST CASE: int(diff(abs(f(I*z)),z), z);
EXPECTED: abs(f(I*z))
-------------------- (2005) Maple 10.00 ----------------------
-f(I*z) <---------------------------------------------- DEFECT
-------------------- (2004) Maple 9.5.1 ----------------------
-f(I*z) <---------------------------------------------- DEFECT
-------------------- (2004) Maple 9.5 ------------------------
-f(I*z) <---------------------------------------------- DEFECT
-------------------- (2003) Maple 9 --------------------------
-f(I*z) <---------------------------------------------- DEFECT
-------------------- (2002) Maple 8 --------------------------
-f(I*z) <---------------------------------------------- DEFECT
-------------------- (2001) Maple 7 --------------------------
-f(I*z) <---------------------------------------------- DEFECT
-------------------- (2000) Maple 6 --------------------------
signum(f(I*z))*f(I*z)
-------------------- (1997) Maple V Rel 5 --------------------
f(I*z) <---------------------------------------------- DEFECT
-------------------- (1995) Maple V Rel 4 --------------------
f(I*z) <---------------------------------------------- DEFECT
-------------------- (1994) Maple V Rel 3 --------------------
int(I*abs(1,f(I*z))*(D(f))(I*z),z)
---------------------------------------------------------------
COMPARE: Mathematica 5.2 returns the correct answer.
Integrate[D[Abs[f[I z]],z], z]
Abs[f[I z]]
...............................................................
"What might be so fundamentally wrong at Maplesoft?"
...............................................................
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells
...............................................................
Maplesoft is committed to providing the highest level
Daniel Lichtblau
Vladimir Bondarenko wrote:
> ...............................................................
Garbage gone...
> [...]
Garbage in...
...garbage out, and further garbage removed (I find myself humming a
tune Pete Seeger used to play at concerts. Maybe still does.)
While one can do definite integration on such objects, Abs(f(x)) has no
derivative or antiderivative in the sense of analytic functions. About
all one can do is resort to some transformation tactics valid only on
the real line, or else an unwarranted formalism, and hope for the best.
Whether that happens to be what you want is largely a matter of luck
(more in wanting something reasonable than in what the software might
do).
Without looking at the code, I'd surmise Mathematica is going the
unjustified formalism route. It transforms D[Abs[f[I*z]],z] to
I*Abs'[f[I*z]]*f'[I*z]. This is fairly meaningless. But a (formal)
antiderivative will be obvious from the (formal) exact differential
nature of the product. All these formalities are, so far as I can tell,
lacking any significant degree of mathematical content.
Daniel Lichtblau
Wolfram Research
Vladimir Bondarenko
DL> But a (formal) antiderivative will be obvious from the
DL> (formal) exact differential nature of the product.
I agree with you that as abs(f(x)) has no derivative or
antiderivative in the sense of analytic functions maybe a
better solution would to return int(diff(abs(f(I*z)),z),z).
But Maple programmers managed to break even the common sense.
Maple starts from a purely real-valued function abs(f(z)),
and, after int(diff(...),z) ends in a complex-valued function
-f(I*z).
Vladimir Bondarenko
Cyber Tester
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level of
support for the products it sells"
Tell it to my old aunt Fanny.
...............................................................
DESCRIPTION: Yet another Maple regression bug, one of MANY
1000s regression bugs unfixed over many years.
TEST CASE: sum(sum(1/(i+i*j)^2, i= 1..infinity),
j= 1..infinity);
EXPECTED: 1/6*Pi^2*(-1+1/6*Pi^2)
1.060874017
CHECKUP: evalf(Sum(Sum(1/(i+i*j)^2, i= 1..infinity),
j= 1..infinity));
1.060874017
--------------- (2005) Maple 10.00 ---------------------------
sum(infinity,j = 1 .. infinity)
--------------- (2004) Maple 9.5.1 ---------------------------
sum(infinity,j = 1 .. infinity)
--------------- (2004) Maple 9.5 -----------------------------
sum(infinity,j = 1 .. infinity)
--------------- (2003) Maple 9 -------------------------------
1/6*Pi^2*(-1+1/6*Pi^2)
--------------- (2002) Maple 8 -------------------------------
1/6*Pi^2*(-1+1/6*Pi^2)
--------------- (2001) Maple 7 -------------------------------
1/6*Pi^2*(-1+1/6*Pi^2)
--------------- (2000) Maple 6 -------------------------------
1/6*Pi^2*(-1+1/6*Pi^2)
--------------- (1997) Maple V Rel 5 -------------------------
1/6*Pi^2*(-1+1/6*Pi^2)
--------------- (1995) Maple V Rel 4 -------------------------
1/6*Pi^2*(-1+1/6*Pi^2)
--------------- (1994) Maple V Rel 3 -------------------------
1/6*Pi^2*(-1+1/6*Pi^2)
---------------------------------------------------------------
COMPARE: Derive 6, Mathematica 5.2, and MuPAD 4.0 return
the correct answer.
SUM(SUM(1/(I+I*j)^2,I,1,inf),j,1,inf)
Sum[1/(i+i*j)^2,{i,1,Infinity},{j,1,Infinity}]
sum(sum(1/(i+i*j)^2,i=1..infinity),j=1..infinity)
pi^2*(pi^2-6)/36
(1/36)*Pi^2*(-6 + Pi^2)
1/36*PI^4 - 1/6*PI^2
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level of
support for the products it sells"
Boys, none of your malarkey.
.................................................................
DESCRIPTION: Yet another Maple regression bug, one of MANY
1000s regression bugs unfixed over many years.
TEST CASE: limit(sinh(sinh(sinh(sinh(z)))), z= infinity);
EXPECTED: infinity
CHECKUP: limit(sinh(sinh(sinh(sinh(z)))), z= 2.);
.4261901733e31227832
-------------------- (2005) Maple 10.00 ------------------------
Maple keeps running after 200000 seconds
-------------------- (2004) Maple 9.5.1 ------------------------
Maple keeps running after 200000 seconds
-------------------- (2004) Maple 9.5 --------------------------
Maple keeps running after 200000 seconds
-------------------- (2003) Maple 9 ----------------------------
Execution stopped: Stack limit reached.
-------------------- (2002) Maple 8 ----------------------------
infinity
-------------------- (2001) Maple 7 ----------------------------
infinity
-------------------- (2000) Maple 6 ----------------------------
infinity
-------------------- (1997) Maple V Rel 5 ----------------------
infinity
-------------------- (1995) Maple V Rel 4 ----------------------
infinity
-------------------- (1994) Maple V Rel 3 ----------------------
infinity
-----------------------------------------------------------------
CONSIDER: Axiom 3, Derive 6, Maxima 5.9.3, and MuPAD 4.0
return the correct answer.
limit(sinh(sinh(sinh(sinh(z)))), z=%plusInfinity)
LIM(SINH(SINH(SINH(SINH(z)))),z,inf)
limit((sinh(sinh(sinh(sinh(z))))), z,inf);
limit(sinh(sinh(sinh(sinh(z)))), z= infinity);
+ infinity
inf
inf
infinity
.................................................................
"What might be so fundamentally wrong at Maplesoft?"
.................................................................
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells
.................................................................
Maplesoft is committed to providing the highest level
of blatant lie about support for the products it sells,
next evidences
.................................................................
First world's Man+Machine Based Maple Crisis Review (beta 0.1)
http://maple.bug-list.org/maple-crisis.php
(beta 0.2 is already of 600+ pages... selected of the selected)
.................................................................
Axel Vogt
Re-using words from the subject of the thread:
this is a idiotic use of a system ...
Vladimir Bondarenko
Nasser Abbasi
"Axel Vogt" <&@axelvogt.de> wrote in message
news:450D03FE...@axelvogt.de...
I agree with Axel that no normal user will probably every need to do that
type of computation.
But the question remains, should a software system, a CAS program in this
case, be able to handle correctly only a typical/normal/expected input and
on those occasions when the user pass it an input that it is not very likely
to receive in a normal operating mode, is it ok for it hang or crash?
By the way, this is not just limited to Maple, the other day I typed the
wrong syntax to Mathematica, and it crashed. Here it is
http://12000.org/tmp/090506/bug_report.htm
(I was told this is being fixed for next Mathematica version).
I myself think a software system (any type of software) should be able and
prepared to handle any input it receives. If it is unable to process the
input, it should reject it in a consistent and delicate manner :)
I also understand that CAS are very complex software, and this make it
harder to do the above. (may be that is why CAS systems need to be more
carefully designed from the bottom up, and be well tested all the time). The
more complex the software, the more testing becomes more important.
Nasser
Vladimir Bondarenko
[Many interesting points! pls see below]
http://groups.google.com/group/sci.math.symbolic/msg/4f3d88fc8ea90867
Hi Nasser,
You raised a VITAL point.
I mean that the point you raised is vital for the mankind's
survival (I kid you not).
NA> should a software system, a CAS program in this case, be
NA> able to handle correctly only a typical/normal/expected
NA> input and on those occasions when the user pass it an
NA> input that it is not very likely to receive in a normal
NA> operating mode, is it ok for it hang or crash?
Precisely!
Consider a secret NORAD computer http://www.norad.mil which
crashed unexpectedly, okay?
(Does Herr Vogt really like this? Me, *certainly* not.)
NA> I myself think a software system (any type of software)
NA> should be able and prepared to handle any input it
NA> receives. If it is unable to process the input, it should
NA> reject it in a consistent and delicate manner :)
Dear friend! Let me, from a far-off Simferopol, give your
hand the warmest squeeze!! ;)
Both Cem Kaner, Professor of Software Engineering and
me, the #1 world's CAS human tester, agree with you 100% !
NA> I also understand that CAS are very complex software,
Oh yes.
NA> and this make it harder to do the above.
Nothing is impossible to a willing heart... plus a powerful
innovative approach ;)
NA> (may be that is why CAS systems need to be more
NA> carefully designed from the bottom up,
1000 times yes!
NA> and be well tested all the time).
10000 times yes! Write your thoughts to Maplesoft ;)
Today ;)) 15% commission guaranteed ;)))
NA> The more complex the software, the more testing
NA> becomes more important.
The more complex the software, the more automated
testing becomes more important. :)
NA> I agree with Axel that no normal user will
NA> probably every need to do that type of
NA> computation.
I am NOT a normal user.
I am a Quality Assurance Engineer ;)
NA> I agree with Axel that no normal user will
NA> probably every need to do that type of
NA> computation.
Have you heard about CECM, okay?
The Borwein brothers,
Dr. Peter Borwein
http://www.cecm.sfu.ca/~pborwein/
Dr. Jonathan Borwein
http://www.cecm.sfu.ca/~jborwein/
the most agreeable Simon Plouffe,
http://www.lacim.uqam.ca/~plouffe/
and some other experimental math stars, okay ?
(Between us the maidens, 'sh... pls do not let the cat
out of the bag: they are also NOT normal users ;)
(They are experimental mathematicians, 'sh, pls ;)))
Sincerely,
Vladimir
--
Vladimir Bondarenko
VM and GEMM architect
Co-founder, CEO, Mathematical Director
http://www.cybertester.com/ Cyber Tester, LLC
http://maple.bug-list.org/ Maple Bugs Encyclopaedia
http://www.CAS-testing.org/ CAS Testing
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level of
support for the products it sells"
Maplesoft IS COMMITTED TO LINING THE POCKETS OF ITS OWNERS.
.................................................................
http://maple.bug-list.org/maple-crisis.php
Maple 10 is an unstable, inconsistent, non-linear, non-uniform,
randomized, self-incompatible environment where fundamental math
properties (uniqueness of the answer for a good-defined problem,
commutativity & linearity property etc) now hold, now fail making
Maple breaking down grotesquely.
.................................................................
DESCRIPTION: Yet another Maple regression bug, one of MANY
1000s regression bugs unfixed over many years.
Side effect: Using the CauchyPrincipalValue option
changes the value of the different calculation.
TEST CASE: restart; int(exp(-abs(z))*sin(z)/z, z=0..infinity);
restart; int(exp(-abs(z))*sin(z)/z, z= -infinity..
infinity, CauchyPrincipalValue):
int(exp(-abs(z))*sin(z)/z, z=0..infinity);
EXPECTED: 1/4*Pi # same output for the same input
1/4*Pi # same output for the same input
CHECKUP: evalf(Int(exp(-abs(z))*sin(z)/z, z=0..infinity));
--------------- (2005) Maple 10.00 -----------------------------
SIDE EFFECT
limit(1/2*I*Ei(1,(1-I)*z)-1/2*I*Ei(1,(1+I)*z)+1/2*I*ln(1-I)-1/2*I
*ln(1+I),z = infinity)
-3/4*Pi
--------------- (2004) Maple 9.5.1 -----------------------------
SIDE EFFECT
limit(1/2*I*Ei(1,(1-I)*z)-1/2*I*Ei(1,(1+I)*z)+1/2*I*ln(1-I)-1/2*I
*ln(1+I),z = infinity)
-3/4*Pi
--------------- (2004) Maple 9.5 -------------------------------
SIDE EFFECT
limit(1/2*I*Ei(1,(1-I)*z)-1/2*I*Ei(1,(1+I)*z)+1/2*I*ln(1-I)-1/2*I
*ln(1+I),z = infinity)
-3/4*Pi
--------------- (2003) Maple 9 ---------------------------------
SIDE EFFECT
limit(1/2*I*Ei(1,(1-I)*z)-1/2*I*Ei(1,(1+I)*z)+1/2*I*ln(1-I)-1/2*I
*ln(1+I),z = infinity)
-3/4*Pi
--------------- (2002) Maple 8 ---------------------------------
SIDE EFFECT
limit(1/2*I*Ei(1,(1-I)*z)-1/2*I*Ei(1,(1+I)*z)+1/2*I*ln(1-I)-1/2*I
*ln(1+I),z = infinity)
1/2*I*ln(-1+I)-1/2*I*ln(-1-I)
--------------- (2001) Maple 7 ---------------------------------
SIDE EFFECT
limit(1/2*I*Ei(1,(1-I)*z)-1/2*I*Ei(1,(1+I)*z)+1/2*I*ln(1-I)-1/2*I
*ln(1+I),z = infinity)
1/2*I*ln(-1+I)-1/2*I*ln(-1-I)
--------------- (2000) Maple 6 ---------------------------------
int(exp(-abs(z))*sin(z)/z,z = 0 .. infinity)
int(exp(-abs(z))*sin(z)/z,z = 0 .. infinity)
--------------- (1997) Maple V Rel 5 ---------------------------
int(exp(-abs(z))*sin(z)/z,z = 0 .. infinity)
int(exp(-abs(z))*sin(z)/z,z = 0 .. infinity)
--------------- (1995) Maple V Rel 4 ---------------------------
int(exp(-abs(z))*sin(z)/z,z = 0 .. infinity)
int(exp(-abs(z))*sin(z)/z,z = 0 .. infinity)
--------------- (1994) Maple V Rel 3 ---------------------------
int(exp(-abs(z))*sin(z)/z,z = 0 .. infinity)
int(exp(-abs(z))*sin(z)/z,z = 0 .. infinity)
-----------------------------------------------------------------
.................................................................
Maplesoft: Propagating math crass ignorance worldwide
Vladimir Bondarenko
http://www.maplesoft.com/support/
"Maplesoft is committed to providing the highest level of
support for the products it sells"
HELL NO.
Maplesoft IS COMMITTED TO LINING THE POCKETS OF ITS OWNERS.
.................................................................
http://maple.bug-list.org/maple-crisis.php
Maple 10 is an unstable, inconsistent, non-linear, non-uniform,
randomized, self-incompatible environment where fundamental math
properties (uniqueness of the answer for a good-defined problem,
commutativity & linearity property etc) now hold, now fail making
Maple breaking down grotesquely.
.................................................................
Maple 10> int(sum(sqrt(z+_R), _R= RootOf(_Z^2+1)), z= 0..1);
-_R*(-1)^(1/4)+2/3*_R^(3/2)+(1+I)^(1/2)+(1+I)^(1/2)*
_R-2/3*(1+_R)^(3/2)
# = f(_R) Boom, boom, boom!
... Years, years, years of Maplesoft's yackety-yak...
Maple V 3> int(sum(sqrt(z+_R), _R= RootOf(_Z^2+1)), z= 0..1);
sum((1+_R)^(1/2),_R = RootOf(_Z^2+1))-2/3*(1+_R)^(3/2
)+sum((1+_R)^(1/2),_R = RootOf(_Z^2+1))*_R-sum(_R^(1/
2),_R = RootOf(_Z^2+1))*_R+2/3*_R^(3/2)
# = f(_R) Boom, boom, boom!
.................................................................
DESCRIPTION: None of Maple versions since at least 1994 on can
calculate this CHILD LEVEL integral correctly.
TEST CASE: evalf( int(sum(sqrt(z+_R), _R= RootOf(_Z^2+1)),
z= 0..1) );
EXPECTED: 1.800934711
CHECKUP: evalf( sqrt(16*sqrt(2)/9-16/9)+2*sqrt(2)/3 );
evalf(int(convert(sum(sqrt(z+_R),
_R= RootOf(_Z^2+1)), radical), z= 0..1));
1.800934711
1.800934712 + 0.*I
--------------- (2005) Maple 10.00 -----------------------------
(.3915773318-.2520169206*I)*_R+.6666666667*_R^(3/2)+1.098684113+.
4550898606*I-.6666666667*(1.+_R)^(3/2)
--------------- (2004) Maple 9.5.1 -----------------------------
(.3915773318-.2520169206*I)*_R+.6666666667*_R^(3/2)+1.098684113+.
4550898606*I-.6666666667*(1.+_R)^(3/2)
--------------- (2004) Maple 9.5 -------------------------------
(.3915773318-.2520169206*I)*_R+.6666666667*_R^(3/2)+1.098684113+.
4550898606*I-.6666666667*(1.+_R)^(3/2)
--------------- (2003) Maple 9 ---------------------------------
(.3915773318-.2520169206*I)*_R+.6666666667*_R^(3/2)+1.098684113+.
4550898606*I-.6666666667*(1.+_R)^(3/2)
--------------- (2002) Maple 8 ---------------------------------
2.197368227+0.*I+(.783154665+0.*I)*_R-.6666666667*(1.+_R)^(3/2)+.
6666666667*_R^(3/2)
--------------- (2001) Maple 7 ---------------------------------
-.6666666667*(1.+_R)^(1/2)*_R+2.197368227+0.*I-.6666666667*(1.+_R
)^(1/2)+(.783154665+0.*I)*_R+.6666666667*_R^(3/2)
--------------- (2000) Maple 6 ---------------------------------
-.6666666667*(1.+_R)^(1/2)*_R+2.197368227+0.*I-.6666666667*(1.+_R
)^(1/2)+(.783154665+0.*I)*_R+.6666666667*_R^(3/2)
--------------- (1997) Maple V Rel 5 ---------------------------
1.800934712 # it's just evalf( unevaluated integral ) ...
--------------- (1995) Maple V Rel 4 ---------------------------
1.800934712 # it's just evalf( unevaluated integral ) ...
--------------- (1994) Maple V Rel 3 ---------------------------
2.197368227-.6666666667*(1.+_R)^(3/2)+.783154665*_R+.6666666667*_
R^(3/2)
Peter Luschny
> "Maplesoft is committed to providing the highest level .."
Hi Vladimir, hallo Nasser!
How Maple wasted about 5 minutes of my time using it to create
a simple plot. What I did was executing this command:
plot([DDLogLG(x,1.0314743165),1/(x+2)], x=-0.95..6.5,
y=-1..1,color=[red,green],tickmarks=[3,3,3]);
It took about 5 minutes. Then there came this error message:
Error, (in plot/options2d) unknown or bad argument, tickmarks = [3, 3, 3]
Well, I made a mistake. Since it was a 2dim plot the last option
should read "tickmarks = [3, 3]". Ok.
But why does not Maple check the options *before* executing the
computations for the plot?
Welcome to the wide world of idiocy with Maplesoft?
Walter Roberson
Peter Luschny <spam...@luschny.de> wrote:
>How Maple wasted about 5 minutes of my time using it to create
>a simple plot. What I did was executing this command:
>plot([DDLogLG(x,1.0314743165),1/(x+2)], x=-0.95..6.5,
>y=-1..1,color=[red,green],tickmarks=[3,3,3]);
>It took about 5 minutes. Then there came this error message:
>Error, (in plot/options2d) unknown or bad argument, tickmarks = [3, 3, 3]
>But why does not Maple check the options *before* executing the
>computations for the plot?
Is it certain that it wasn't the DDLogLG(x,1.0314743165) part
that took the 5 minutes? For routines with normal evaluation
semantics, Maple evaluates each argument before calling the
function.
Also along the same line, is it possible that x already had
a value? The x would have been evaluated during evaluation
of the first argument. plot() does *not* have the special
evaluation semantics of examining the dummy variable names and
automatically making them local in the expression arguments.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson