@acer Yes, the change only explains why procedure g works. The fact that g works while f doesn't leads to confusion if one is trying to follow the documented syntax.

My previous Reply was meant totally as an aside to provide additional information and not in any way meant as a criticism of your Answer.

My guess is that the hack was put in to help obscure the distinction between table-based and module-based packages. A side effect is that it also affects any table with a name index. Perhaps no harm will come from this.

@acer Furthermore, the semantics of :- have changed (without notice!) such that if T is any table (not necessarily a package) and N is any index of T of type name, then T:-N is the same as T[N] on lookup! And even weirder: If T:-N is being assigned to, a new and difficult-to-access index 'N' is placed in T. Execute this:

restart:
T:= table([N=7]):
T:-N;
T:-N:= 11;
T:-N;
T[N];
T['N'];
T[''N''];
{indices(T)};
eval(%);

These changes are not supported by the help page ?:-; indeed that page contradicts the new behavior. My guess is that whoever put this hack in the kernel was ashamed of having done it.

This explains why the OP's procedure g works even though orthopoly is a table.

@Markiyan Hirnyk 

Your example raises an interesting question. Should a proposed solution to an ODE without specified initial conditions be considered correct if it doesn't include arbitrary constants of integration? Apparently the author of odetest had no consistent answer to that. Note that if you simply remove C1 rather than replacing it with 1 (equivalent to setting C1=0), odetest still fails. On the other hand, odetest(y(x)=0, diff(y(x),x) = y(x)) passes.

I still think that my Answer provides an effective workaround (rather than a complete solution) for the situation presented by the OP. The situation is afterall a bug.

@tomleslie Threads:-Sleep works fine in ordinary (non-multi-processing) code. Its use does not require the use of any other command from Threads.

@digerdiga Can the variable x be assumed to be real? Knowing that would substantially reduce the complexity of the problem.

@taro I'm not saying that the literal expression D(x) will return 0, nor am I saying that the statement "D(x) always returns 0" is true. But all of these do return 0:

D(5);                              #or use _any_ other number
eval(D(t), t= 5);             #Use _any_ name other than x
eval(D(t), {l= 3, t= 5});  #                    "
eval('D'(x), x= 5);
eval('D(x)', x= 5);

And these plots will be identically 0 over any range:

plot(D, -5..5);
plot(D(t), t= -5..5);

So, I, myself, am not saying "D(x) always returns 0". Rather, I'm saying that repeated attempts of the type shown above would reasonably lead a new user to say "D(x) always returns 0". I can't fault that user for thinking that. Given the experience of the examples above, it seems reasonable in its own right. Plus that user may have been misled by help or examples (not necessarily official help or examples) that make one think that f(x):= ... is a proper way to define a function.

So, do you now understand what I said in my previous Reply?

@Kitonum Well, it's not just a name. Surely a user of your experience level knows that D is a library procedure, the differential operator. So, whether or not one assigns a value to D(x), all these: D(0.1), D(0.01), D(any specific constant), will return 0 due to D's original definition as the differential operator. This leads the OP to believe and to say (with good reason!) that "D(x) always returns 0", even though the literal expression D(x) may return some other value.

The upshot or takeaway or moral is: Don't use the syntax f(x):= to define a procedure or function. It's not safe, even though 2D input allows it.

@Adam Ledger Adam, you are confusing the limit of a sequence being infinity (or some might call it its divergence to infinity) with its limit superior being infinity. Consider the sequence

f:= n-> piecewise(n::even, 0, n::odd, n);

This sequence is a canonical example of what you call "oscillating from infinity to 0 an infinite number of times." Its limit superior is infinity, but its limit per se does not exist.

Here's a rigorous definition for the limit superior of a real-valued sequence a(n) being infinity: For all M in N there exists n in N such that a(n) > M. Compare with a rigorous definition of its limit being infinity: For all M in N there exists m in N such that for all n in N[m..], a(n) > M (where N[m..] is the set of natural numbers greater than m).

In the original problem, don't let the weirdness of the constant log10(Pi) distract you. All that matters is that log10(Pi) < 1/2. This is a case where a more-general proposition may be easier to prove:

• Proposition: Let a and b be any real constants with a > b, and let f:= (k::posint)-> floor(a*(k-1)) - floor(b*k). Then for all n in Z, {k in N | f(k) = n} is finite.

@Kitonum D(x):= ... assigns a value to the remember table of existing library procedure D (without error or warning).

@laurent Thanks, Laurent. I should've also mentioned that an assuming clause is usually a better alternative to assume(...) when one wants a temporary assumption. 

@David Sycamore All of the { } that appear in Tom's post are erroneous. I guess that they're just typos, because I'm sure that he knows better. You can bracket an explicit list of values with square brackets [ ] or angle brackets < >. (If you use angle brackets, you'll create what Maple calls a Vector. It's not important to understand the distinction between a list and a Vector at this point; either will work fine in this case. If you use curly braces { }, you'll create what Maple calls a set. That's not good in this case because you can't control the order that items appear in a set.)

Once your list of x values has been entered, there are numerous ways to apply f to each of them. Do you have the code of the procedure f? Is it already in a script or Maple worksheet? Does it take a single argument (the xs in this case)?

@Annonymouse Thanks, the notifications are no problem.

The nops simply counts the number of entries in a list or set. Since that's what you wanted to plot, it must be used. I was not trying to address any memory issues. Are the lists produced by the (7,7) case very large? It may be that it's not possible to simultaneously maintain all the lists in memory at once. You'd need to post the code that gives the memory error for me to figure out more.

@David Sycamore You asked:

• The data does not exist yet in Maple, I have yet to learn how to do that. Can I incorporate it into the script or must it be a separate file?

You can type it directly into the script. That is the easiest thing to do. Previous suggestions, such as ImportMatrix, were based on the supposition that your data were already in some file, separate from Maple. You can type it into the script numerous ways. I think that the easiest is

MyData:= <
      3,          37; #You can put comments at the ends of lines.
     #You can put comments between lines.
      5,          94;
      ... etc ...
     199,       307  >:

Maple doesn't care about the spacing or line breaks; they're just used for clarity. However, it does care about the punctuation.
     

  

Lest there be any confusion about it, I must point out that this is not a Maple-specific problem; it affects floating-point computation in all languages. At least Maple offers a few ways to fix the problem, albeit ad hoc: symbolic simplification/conversion or increased precision.

@David Sycamore I'm sorry if this seems too obvious to even say, but I don't know what else to advise: Why don't you simply type the numbers into a Maple worksheet?