@ali_shakiba 

My current interpretation of the intention of the developer is: solve the equation cos(Pi/k)=0, finding k=2/(1+2*_Z1), _Z1 integer. Then, check whether all the solutions of this equation were found, and if so, whether any of these solutions is an integer in 3..infinity. If so, corresponding to false, it returns 0. If this is what it was meant, the code fails to do that, as there is a logical mismatch between the posible returns of solve(...,allsolutions) and the interpretation made by coulditbe of its input. Look how the assumption of integer is handled internally:

> r:=solve(cos(Pi/k),k,allsolutions);
                                         2
                                r := ----------
                                     1 + 2 _Z2~
> about(op(indets(%,suffixed(_Z,integer))));
Originally _Z2, renamed _Z2~:
  is assumed to be: integer
> trace(is):
> ormap(coulditbe,r,AndProp('integer',RealRange(3,infinity)));
{--> enter is, args = 1/(1+2*_Z2), Non(integer)
                                     false
<-- exit is (now in unknown) = false}
{--> enter is, args = 1/(1+2*_Z2), Non(RealRange(3,infinity))
                                     false
<-- exit is (now in unknown) = false}
                                      true

For instance, it looks like the assumption of integer is not taken into account in the second call to is, as its result of false can hold only in the interval (-1/2,-1/3]:

> is(1/(1+2*Z), Non(RealRange(3,infinity))) assuming Z::integer;
                                     false
> is(1/(1+2*Z), Non(RealRange(3,infinity))) ;
                                     false
> solve(1/(1+2*Z)>=3) ;
                          RealRange(Open(-1/2), -1/3)

Meaning that this code "concludes" wrongly that there is a value of k, root of cos(Pi/k), integer and in 3..infinity.

So, care has to be taken with products going through the same computational path. For example:

> P := Product(cos(Pi/(4*k^4)), k = 2 .. infinity): 
> value(P);
                                       0
> evalf(P);
                                  0.9987427471

@Carl Love 

I guess that, in this context, these symbols represent DAGs:

> sscanf(sprintf("#%m%m",a,b),"%m")[];
                                      a/b
> sscanf(sprintf("'%m%m",a,b),"%m")[];
                                      a::b
> sscanf(sprintf("/%m%m",2,4),"%m")[];
                                     2 = 4
> sscanf(sprintf("$%m%m",a,b),"%m")[];
                                  Float(a, b)
> sscanf(sprintf("^%m%m",a,b),"%m")[];
Error, (in sscanf) invalid COMPLEX dag length

On Linux 32-bit I observe this memory leak starting from Maple 13.02.

@PatrickT 

The key post to read when you have such technological questions is "The Plan". I quote Bryon:

Migration to a Windows architecture & cosmetic update
As most of you know, MaplePrimes currently runs on a platform called Drupal.  Drupal was, and is, a great social networking platform, but it is written in PHP and our in-house proficiency in that language has diminished over the past few years, and this causes resource struggles when we want to work on Primes.  To remedy this, we are going to switch the architecture to use the standard Windows/Visual Studio platform that we use for our other web endeavours.  Among other things, one of the primary benefits of this change is that we will have increased capacity within our web development team to troubleshoot and update the site. Coupled with the architecture update will be an entirely new look and feel for the web site.

So, I wonder where is their web development team...

@PatrickT 

This is yet another regression bug (the list is long...). I have met it several times in recent edits with my two accounts. In my experience, the changes are made once submited, but to see them you have to load the thread page anew (bypassing the window/tab containing the editor).

@dholtzman 

One problem with issue reports is that there is no open issue tracker system for Maple. So, only Maplesoft could answer for sure (I do not remember a similar report right now, but a thorough search should be made).

1) The maplet device is basically the Standard GUI device at the stage of Maple 12 or so, time before Windows 8. So, It might be a significant change of Windows 8 wrt earlier versions, unless it is an issue with your graphics card (or some interaction of all these factors).

2) If you are using Maple 17.01, the first thing to try is update to Maple 17.02. Chances are that the relevant code was fixed wrt this issue.

4) Not unexpected. I understand that development of code for 2D and 3D sometimes follow quite different timelines.

@itsme 

No, this is science, basically, Mathematics, CS, etc. There is no such thing as "automagic" here, even though marketing guys might pretend selling it that way. I think that the first question is whether there is an algorithm to find symbolically "all" the roots satisfying the stated property. The next question is what is the actual implementation in Maple.

The answers are unclear to me. I wonder whether there is such algorithm, or good heuristics, at least  (on similar issues, look e.g. at this thread about undecidability and trigonometric identities). And code documentation (algorithms, heuristics, implementation details) is missing for the users. 

So, at this point, I do not have enough information to qualify this issue. Yet, I would say that, minimally, a warning should be issued about the failure to return the required solutions.

@Joe Riel 

May be that it is this reported issue?

@Joe Riel 

On Linux, it works selecting text on Emacs and pasting on this editor, by pressing the middle button of the mouse. I understand that this is the PRIMARY mode.

@dholtzman 

I am inclined to think that it is a bug. However, it is not clear to me whether you have tried with the maplet device, and if so, what output you have got. The result, in either direction, could provide another piece of information. 

Except for trying with a different version of the graphics driver, if it is a bug, you will depend on Maplesoft for providing a fix for Maple 17. By the way, is it Maple 17.02 or what?

Why the same code, run in Maple 17.02 CLI (%%Creator: Maple) generates eps files of about 10KB, while run in Maple 17.02 Standard GUI (%%Creator: FreeHEP Graphics2D Driver) generates eps files of about 90KB? What improvement could need/justify a 9-fold increase in size?

@sunit

It depends on what exactly "a function like  that" means... What I can say is that the method cook uses in this case a custom pattern matcher for integrands of the following form:

> kernelopts(opaquemodules=false):
> showstat(IntegrationTools:-Definite:-Integrators:-Cook:-DoPattern3,22);
IntegrationTools:-Definite:-Integrators:-Cook:-DoPattern3 := proc(t, ta, tb, param, model, Bessellabel, $)
local cof, b, bJ, bY, c, kJ, kY, np1, s, sp, w, u, ndiff, BJ, BY, C, KJ, KY, W, U, MODEL, S, SP, bJfl, bYfl, cfl, np1fl, sfl, ufl, bJtype, bYtype, ctype, np1type, utype, stype, fltypetemp, failtemp, res, DoHgeom, DoIt, DoH;
       ...
  22   MODEL := exp(-U*t^S)*t^W*BesselJ(BJ,C*t^SP)^KJ*BesselY(BY,C*t^SP)^KY;
       ...
end proc

So, it could be conjectured that if it produces a wrong result for the simple case of your example, then it will produce also wrong results for all or many integrands of the above form. However, this conjecture should be checked, and I have not done such check. Also, it should be checked what result produces the first method that succeeds (if any).

Certainly, it would be much easier to answer such questions if the full documentation of the algorithms and code were available to the users...

@Joe Riel 

As said by Will, an option for restoring chronological ordering of answers to a question was introduced last year (after years of complains). But the problem here is about chronological ordering of comments. Since the last changes to this site, their sorting keeps changing in an apparently random way after each loading of the thread page. For long threads like the one pointed out by Carl, this problem makes too inconvenient (at least for me) to continue with a technical discussion here. That is why I decided that it was best to move this exchange with John by private mail (I may forward to Carl, of course).

But an even more serious regression problem with this site is comments that have directly disappeared. And there are many more regression problems: missing uploaded files, wrong formating, failing links to comments, etc. And most of the problems intended to be fixed by those changes were not fixed.

In short, in my vision, this site is falling appart. And the point to discuss is the state of this site, not whether I participate or not. But indeed, this situation is a reason for me to keep reducing my participation.

By the way, who is working on this site (the technical team) if Will is not?

@John Fredsted 

I have complained by mail to Bryon many times about many regression bugs and failing new features, since the last changes. Sometimes he has answered, saying he would do something, but did not in most cases. On some occasions in the past, he has said that they are always short of time. But if you observe this site, it is full of needless features, that make it too complex and inefficient. Obviously, a reasonable system manager would go implementing a system whose complexity is such that can be properly maintained with the available resources. The obvious consequence is a system in a permanent broken state. Not much different than the Standard GUI, in fact. A corporate culture, I guess... 

@John Fredsted 

I will answer to you by private mail as soon as possible. I prefer moving away, as this site is falling appart. In particular, the disorder on threads like this one is untolerable for me.