@Kitonum But this is not even close to the OP's proposed result.

@sand15athome The following may be already totally obvious to you. But, just in case you don't know...

PLOT isn't a command of the Maple language; it's just an inert data structure that's interpreted by the GUI. (So, perhaps it can be considered a command to the GUI, but to the Maple kernel it's inert.) All commands that produce static (i.e., non-animated) 2-D plots have this data structure as their output. As long as you're aware of all that, I think that it's fine to write your own procedures that produce PLOT output; indeed, I often find it necessary.

@TomM Good work investigating this.

I made your ideas into a procedure. I use randomly selected complex evaluation points selected over a square centered at the origin of user-specified dimension (defaults to 4x4).

Download unifloat.mw

@tomleslie I think that you may be right---that unlike dsolve, pdsolve's solution procedures don't contain the (correct) partial derivatives. However, Maple says that the requested derivative is 0---it doesn't produce an empty plot or give an error message. It also gives 0 if you use the pds:-value method.

@vv And the value of that Stieltjes integral is not 0?

Can you give an example of a function which can be represented in Maple or any computer-algebra system for which the Stieltjes integral is different from the "normal" integral?

@tomleslie And your formula works for any base if you change the 10 and use a log-based formula for the length. I'm almost sure that this would be faster than the non-base-10 digit-reversal formula that I posted above, regardless of the length; but I don't feel like testing it right now.

In the meantime, here's my any-base digit-reversal:

revNumB:= proc(x::nonnegint, b::And(posint, Not(1)))
local y:= x, r:= irem(y, b, 'y');
     while y <> 0 do
          r:= b*r + irem(y, b, 'y')
     end do
end proc:

@tomleslie The [1,1] in your op[1,1] does nothing. The extreme liberalness of Maple syntax allows you to put a meaningless index on a function that doesn't expect an index. You could change [1,1] to [foo] for example.

@vv You wrote:

P.S. Do you have an example where a local for the variable in seq is mandatory? (probably only for multiple kernels [or threads?] in some circumstances).

The status of the bound variable of seq, add, and mul is the same. Here are two examples of what can go wrong:

Download local.mw

AFAIK, these are the only examples.

Regarding op(x) vs. x[]:

restart:
L:= [['rand()'] $ 2^23]:
gc(): CodeTools:-Usage([seq(x[], x= L)]):
memory used=64.00MiB, alloc change=64.00MiB, cpu time=1000.00ms, real time=1000.00ms, gc time=0ns
gc(): CodeTools:-Usage([seq(op(x), x= L)]):
memory used=64.00MiB, alloc change=64.00MiB, cpu time=1.72s, real time=1.72s, gc time=0ns
gc(): CodeTools:-Usage(map(x-> x[], L)):
memory used=0.50GiB, alloc change=64.00MiB, cpu time=18.05s, real time=7.82s, gc time=12.14s
gc(): CodeTools:-Usage(map(op, L)):
memory used=0.50GiB, alloc change=64.00MiB, cpu time=14.42s, real time=6.82s, gc time=9.80s
gc(): CodeTools:-Usage(op~(L)):
memory used=384.00MiB, alloc change=64.00MiB, cpu time=12.50s, real time=5.66s, gc time=9.12s

But the most-important conclusion from the above is that seq is much faster than any form of mapping. This is very unfortunate because seq has the most awkward syntax.

@smo4291990 The procs and do loops that you've shown so far are not quite correct. They're almost correct, but computers don't do "almost" (yet). So let's perfect your procs and do loops first. Please write a proc with a do loop that does anything of your choice. Use some reasonable style of indentation; don't write it inline (i.e., as part of a sentence). State what the procedure does.

If you follow my instructions, I promise that I'll work through this exercise with you.

@vv

Vote up.

I was able to improve your procedure, making it

• take less time and memory,
• handle the degenerate cases k > n and k = 0, and
• more robust by doing type checking and by using a local variable.

Here's the code:

#VV's method, modified by Carl
rcomb2:= proc(n::nonnegint, k::nonnegint)
local i;
     if k > n then ()
     elif k=0 then []
     else
          proc(n,k,p:= [])
               if k=n then [seq(1..n), p[]]
               elif k=1 then seq([i,p[]], i= 1..n)
               else thisproc(n-1, k, p), thisproc(n-1, k-1, [n,p[]])
               fi
          end proc(n,k)
     fi
end proc:

With these modifications, the above is a tiny bit faster than my seq method, but uses more memory. I modified my Answer above to include both your original version and my modification in the overall comparison.

@vv Your rcomb seems to produce the correct number of tuples, but most of them are shorter than they should be:

rcomb(5,3);

     [1, 2, 3], [1, 2], [1, 3], [2, 3], [1, 2], [1, 3], [2, 3], [1, 4], [2, 4], [3, 4]

@Joe Riel Since I thought about it so long and hard, please let me know if you know of any way that uses the OP's simple recursion, but using tables or rtables rather than sets or lists.

@sand15athome 

So, I see that you figured out how to use ||, which allows you to combine some features of both indices and subscripts. In general, there are a few drawbacks to using ||, but they don't apply to your situation. The two drawbacks that I can think of to using || are

• variables created with || are always global, and
• if you use hundreds or thousands of such variables, you will notice a slowdown that won't happen if you use indexed variables.

Here is your worksheet with my ideas for improvement:

Download WhatHappensHere3.mw

@vv

With Maple, modifying the code for experimentation is easy. Maple's arbitrary-length integer arithmetic is quite fast; it uses GMP. Maple's memory management isn't the greatest, but at least you get automatic garbage collection on parallel processors. I suspect that things like reversing the digits of an arbitary-length integer in an arbitrary base are very tedious in C.

If I was going to write a program intended to run for weeks or months operating on numbers with millions of digits, I'd use C. But I'd definitely write that program first in Maple, perfect it, and then hand translate it to C.