You're right: It shouldn't return NULL. I'd consider a case where it returns NULL a bug. For a transformation, Maple should return either an expression or an error message. The returned expression may be the same as the input expression (we call it returning unevaluated) if the computation is too complicated to perform. So, would you please show the expression for which you get NULL output? For the example that I tried, I get unevaluated output:

inttrans:-mellin(LerchPhi(z, 1, 2), z, s);

     mellin(LerchPhi(z, 1, 2), z, s)

@Østerbro 

These versions remove the repetition of the input:

Display:= proc(e::uneval)
uses T= Typesetting;
local
     pre:= subsindets(e, uneval(name), eval, 1),
     r:= eval(pre),
     Ty_pre:= T:-Typeset(e)
;    
     if indets(pre, And(name, satisfies(u-> u<>eval(u)))) = {} then
          print(r)
     else
          print(
               evalindets(                    
                    subs("⁢"= "*", Ty_pre),  
                    specfunc(string, T:-mi),
                    proc(n)
                    local pn:= eval(parse(op(n)));
                         if pn::numeric then T:-mn(sprintf("%a", pn))
                         else T:-Typeset(T:-EV(pn))
                         end if 
                    end proc
               ) =
               evalf(r)
          )
     end if;
     r
end proc:

And the same thing for what Acer called the "weaker" version:

Display:= proc(e::uneval)
uses T= Typesetting;
local
     pre:= subsindets(e, uneval(name), eval, 1),
     r:= eval(pre),
     Ty_pre:= T:-Typeset(e)
;    
     if indets(pre, And(name, satisfies(u-> u<>eval(u)))) = {} then
          print(r)
     else
          print(
               evalindets(                    
                    subs("⁢"= "*", Ty_pre),  
                    specfunc(string, T:-mi),
                    proc(n)
                    local pn:= eval(parse(op(n)));
                         if pn::numeric then
                              T:-mn(sprintf("%a", pn))
                         elif type(pn, numeric &* 'specfunc'('anything', Units:-Unit)) then
                              T:-Typeset(T:-EV(pn))
                         else n
                         end if  
                    end proc
               ) =
               evalf(r)
          )
     end if;
     r
end proc:

@Østerbro Of the two versions of Display that Acer posted in his most-recent Reply, which are you using in your most-recent .pdf file?

@Vic Oh, I see now that you said Maple 16, not Maple 2016 (the current version). I misread that as Maple 2016. I don't think the downloaded Iterator will work with Maple 16. Not sure.

@Vic It comes prepackaged with Maple 2016. If you have Maple 2015 or Maple 18, you can download it for free from the Maple Applications Center.

@Vic You don't need to consider a < b because you only need to search forward of the current position. You can change your procedure to this:

ListProcess:= proc(A::list)
local k,b;
     for k to nops(A)-1 do
          if member(A[k][[2,1]], A[k+1..], 'b') and b::odd then return end if
     end do;
     A
end proc:

@Vic You'll definitely want to use the CartesianProduct from the Iterator package rather than the cartprod from the combinat package. The former is much faster. This'll also use an Array rather than a list for A, which'll produce less garbage to collect.

You don't have to do anything to have the garbage collected; Maple does it automatically. However, you should be aware of what percentage of your total time is being spent on it. CodeTools:-Usage will provide this information. You can run your procedure on, say, 10,000 lists and look at the gc time.

@Preben Alsholm Thanks, it works. I should've seen that both high-order derivatives were only in the second equation, but I didn't.

@Vic 

The first version is horribly, horribly inefficient. Please don't use it. I only included it as an example to show how you could break out of multiple loops.

p::[posint$2] is a type-checking expression. It is a boolean expression that is true iff p is a list of two positive integers. x$2 is equivalent to x,x for any x.

In order to precisely maintain the logic of your original loops, I needed to make sure that both members of p are integers less than or equal to n; that's what the max(p) <= n is for. But you may already know a priori that every member of A is a list of two positive integers both less than or equal to n. In that case, you don't need to check.

Are all your pairs distinct (i.e., not equal) elements? If so, then please construct for me an example A for which a < b isn't true. If you can't construct such an example, then it's a waste of time to check a < b. If you do have pairs p such that p[1]=p[2], then you'll have a=b. Those should be handled as a special case; it'd be a waste to do the position search in that case. And, as I see it now, it's impossible to have b < a.

Regardless of needing to break out of loops, you will ultimately need to use procedures. It'll be best if you start thinking in terms of procedures now.

You can sometimes get some information by setting infolevel[all]:= 5. Sometimes this will be an overwhelming amount of information, and you can use an integer 1 - 4 instead of 5. Note that the infolevel setting will stay in effect until you reset it to 0. The all can be replaced with specific procedure names, such as int. Here's an example:

infolevel[all]:= 5:
int(1/x^3, x= -1..1);

This produces about two pages of output, which I won't transcribe here, with the final result being undefined.

Now, looking at this output, I can see that `simplify/do` is called several times. I'm curious why. In particular, I'd like to know what arguments it was called with. This can be found with trace:

restart:   #You must restart for this to work.
infolevel[all]:= 5:
trace(`simplify/do`):   #Procedure names with special characters (like /) must be quoted.
int(1/x^3, x= -1..1);

You'll want to turn off tracing when you're done. You can either do a restart, or untrace(`simplify/do`).

@torabi What makes you think that this latest system needs only seven BCs? It still needs eight. If you were able to convert it to a form that could be converted to a first-order system, you'd immediately get an error saying that you need eight BCs.

I don't know how to put this system into a form that can be converted to a first-order system. The usual trick is to solve for the highest-order derivatives and take one of the solution branches. But solve returns NULL in this case:

solve(sys, {diff(w(x),x$4), diff(psi(x),x$3)});

@torabi The differential order of the system is seven, and you have one parameter, so you need eight boundary conditions. There are six in bcs, therefore two more must come from extra_bcs.

I took out approxsoln because it's possible to get a solution (in fact, 25 solutions) without it. Note that approxsoln doesn't change the solution at all; it only helps the problem get started. And I guessed that it was just something leftover from a previous problem. Feel free to put it back; it won't make a big difference.

The 25 numbers on the second-to-last line are your values of omega2. You didn't say before that you needed them sorted. I added code to do that. The final line are the indices into res that correspond to the sorted values of omega2. In other words, the last line shows the value of b corresponding to each value of omega2.

warning-3.mw

@Adam Ledger Your request in the original post was

im just curious to know how this one measures up in terms of computational efficiency...if anyone has the time to give it a try and let me know what they think ie faster more logical way about it any feed back is appreciated....

And that's what I did, but you don't seem to appreciate it; rather, you seem to take offense. I showed you how your function could be transcribed into more-normal Maple, still containing essentially a delta function. Then I rewrote it in a much-simpler, more-logical, more-efficient way without a delta function.

I didn't say that the delta function is worthless. I said that it had no practical computational value, meaning that you shouldn't use it in code, and that it had no theoretical computational value, meaning that you shouldn't use it in pseudocode either. The point is to think in terms of control structures, like if statements, which are more logical and less arithmetical.

This is covered on this Wikipedia page.

@Adam Ledger I recommend the book Prime Numbers: A Computational Perspective by Richard Crandall and Carl Pomerance. The algorithms are in pseudocode.

You should narrow your study to one of the following problems:

1. Prime detection: detecting whether an integer is prime
2. Prime counting: counting all the primes less than a certain number
3. Prime listing: listing all the primes less than a certain number

To see the code of a Maple procedure, use showstat:

showstat(isprime);

The command select is in the kernel, so you can't see it. However, it is a triviality which adds no significant time to the command. It is equivalent to

Select:= (B, L::{list,set})->
     `if`(L::list, `[]`, `{}`)(seq(`if`(B(x, _rest), x, NULL), x= L))
:

but it runs faster because it's in the kernel.

To time a Maple procedure and save the time, use CodeTools:-Usage with the output option:

T[n]:= CodeTools:-Usage(P(n), output= realtime);

You can replace realtime with cputime. This'll give you a different timing. Which one is more meaningful is debatable, but it's how they grow with n (asymptotic time complexity) that matters most. That's unlikely to change if you switch between realtime and cputime. Make sure that n is large enough to give you a meaningful timing. Times of 16 ms or less for Maple code are usually meaningless, or at least difficult to interpret correctly.

You should make an empirical study of the asymptotic time complexity of your algorithms. The first step to this is to make a log-log plot of n vs. T[n] using T[n] as defined above. Looking at the ratios of the times of two different algorithms before knowing their time complexity is not very meaningful. Ratios would be more meaningful if you were comparing different implementations of the same algorithm.

The delta function is a convenience for mathematical notation and has little to no practical or even theoretical computational value. You should try to erase it from your mind and instead think in terms of if and select statements and other control structures.

The Legendre prime-counting formula that you gave is mostly of theoretical interest; it has little practical computational value. Read the linked MathWorld page, and follow the links to Meissel's formula and Lehmer's formula. These formulas are more practical.