Try it under the assumption that x>0 .

restart;

f:=(x,z)->ln(x^z);

                                      / z\
                     f := (x, z) -> ln\x /

simplify(f(x,2)) assuming x>0;

                            2 ln(x)

Now consider a value for x such as -1/3 . Notice that your expected formula doesn't produce the same result.

ln((-1/3)^2), 2*ln(-1/3);

                  -2 ln(3), -2 ln(3) + 2 I Pi

Your Question was, "Can a Data Table be used as an input in a procedure?"

If I understand the question properly, then my Answer is as follows. The name of the unique Array/rtable/Matrix/Vector associated with a particular DataTable can be the argument to a procedure call, as can the unique string identity of a particular DataTable.

Now on to your bullet points, which seem to be more about having an Array associated with a DataTable be returned from a procedure call:

Issue 3)

When your procedure BiPolyNum returns a copy of the Array ary then it is deliberately breaking any connection with the DataTable associated with ary.

Subsequent changes in the DataTable (made manually) will not be accompanied by any changes in the Array returned by BiPolyNum as copy(ary). And vice versa.

So, if you expect the returned Array and the DataTable to be associated, then don't use copy on the return value.

Issue 2)

This is the same as issue 3), except you're not using a procedure. But your copy(ary) is still not going to be associated with the DataTable. A DataTable is associated with only one rtable (Array, say). A copy of that Array won't be associated with the DataTable.

Issue 1)

I'll check whether I can reproduce the lag. You could submit a bug report. I suggest submitting a bug report in which you've inserted the DataTable by hand, via the Components palette, so that it's clear that the issue has nothing to do with the DocumentTools commands.

That's not 1D Math output.

It's 2D Math output where the bodies of the operators are showing prefix form rather than infix form.

It's likely that it's related to your use of Units:-Standard , since the rebound arithmetic operators in that package will return calls to the global operators.

It's not clearly a bug. What you're seeing is the bodies of procedures. It's not clear why they *ought* always to pretty-print exactly the same as do plain output expressions. But we might be able to suggest a change to make it happen...

It would make most sense for you to upload an actual Document, which contained all the inputs. (We'd also be able to tell which mnor and major version you're using. There are have been some related changes since Maple 2016.)

You can programmatically insert a new (invisible, so-called) Task Region right after the currently focused Execution Group or Document Block (paragraph). And you can programmatically construct the contents that will go into it.

And that includes contents like Embedded Components such as Math Containers. See the help page for topic,

    DocumentTools,Components,MathContainer

You can also programmatically replace the contents of a previously inserted Task Region.

But an insertion of a new Task Region can only be done from overt code. It cannot be done from within a Button. It can only be inserted below the current Execution Group or Document Block. It cannot be done to some other execution group elsewhere in the sheet.

Part of your description makes it sound like you want "day of the year" to be the independent data and "amount of chemical" to be the dependent data. That makes sense to me, and it's what I show below.

When you write that you want, "day of the year vs amount of chemical" then there may be a confusion in terminology. Usually one talks of plotting dependent quantity vs independent quanity.

restart;

A:=Array([[10,283.2],[21,293.3],[27,294.4],[103,300.7],[211,302.1]]):
M:=Matrix(A);

chem_formula:=13.0+7.0*sqrt(273+temp);
chem_func:=unapply(chem_formula, temp);

M[1..-1,1]; # the day numbers (in the year)

M[1..-1,2]; # the temperatures

map(chem_func, M[1..-1,2]); # the chemical amounts

plot( <M[1..-1,1] | map(chem_func, M[1..-1,2])>,
      view=[1..365, default] );

Download divid.mw

[edited] This kind of question has been asked several times before -- enough that people have written short re-usable procedures for it. So, you could use A.Jakubi's dividend procedure (and optionally pass it a sorting post-processor similar to what I used above).

Download dividend_ex.mw

You can check that the floats agree under rounding (to less digits), as Kitonum suggested.

Or you can increase the working precision, and then round down to current (default 10) Digits.

Or you can use testfloat to get details, and optionally use testfloat to do a coarser comparison.

Download float_comparison.mw

In your code to produce the "A" you assign to the name x, like x:=Alist[i][1] . Then you try and construct the "D" while using x as if it were an unassigned name. That won't work. There likely are other issues with the code, which is quite disorganized.

You can keep all your variables organized by using a procedure's local names for dummy variables.

You should be able to produce an unrotated "A" with just three polygons, and without any (white) occluding background, in one line of code. Even better, construct a procedure that returns the plot structure for an "A" (upright, with lower left corner at the origin).

Here's an example. (You could add a color like "gray" to the polygons, of course.) 

plot_letterA.mw

interface( rtablesize = 11 ):  # or higher

w := (x, y) -> piecewise(y <= .5, -2*tanh(y-.25), .5 < y, 2*tanh(.75-y)):

Matrix( 11, 11, (i,j) -> w(i-1,j-1) );

First note that a sequence of items is different from a list of items.

restart;

f := proc()
  print(sprintf( "nargs = %a", nargs ));
  print(sprintf( "args[1] = %a", args[1] ));
  return NULL;
end proc:

f( 1,2,3,4,5 );
                          "nargs = 5"
                         "args[1] = 1"

f( [1,2,3,4,5] );
                          "nargs = 1"
                  "args[1] = [1, 2, 3, 4, 5]"

When f above is passed a sequence of 5 numbers then the number of arguments is 5, and the first argument is just 1. (nargs stands for number of arguments, and args stands for arguments.)

But when f above is passed a list with 5 entries then the number of arguments passed to f is just 1, and the first argument is the whole list.

Your maximum procedure and example call didn't work as intended because you passed it a single list (so nargs is just 1), whereas you've written it to work with a sequence.

Here are some versions that work (several other variations are possible). The first works when passed a sequence of numeric items, and the second works when passed a list of numeric items. I also give a third (which is a minor variation on the second) where the procedure's first parameter L is explicitly declared.

restart;

maximum := proc()
 local r, i;
 r := args[1];
 for i from 2 to nargs do
   if args[i] > r then
     r := args[i];
   end if;
 end do;
 r;
end proc:

maximum( 6,9,4,1 );
                               9

restart;

maximum := proc()
 local r, i, L;
 L := args[1];
 r := L[1];
 for i from 2 to nops(L) do
   if L[i] > r then
     r := L[i];
   end if;
 end do;
 r;
end proc:

maximum( [6,9,4,1] );
                               9

restart;

maximum := proc(L)
 local r, i;
 r := L[1];
 for i from 2 to nops(L) do
   if L[i] > r then
     r := L[i];
   end if;
 end do;
 r;
end proc:

maximum( [6,9,4,1] );
                               9

Secondly, note that the following two lists are NOT similar. One is a list of lists and the other is a list of scalars. The first is a list of 6 lists (each with 2 scalar entries). The second is a list with 12 scalar entries. You cannot operate on them in the exact same manner. BTW, if you changed your trailing colons to semicolons then your output wouldn't be suppressed and you'd be able to more easily see this for yourself.

LC_L:=[[0,0],[0,h],[w,h],[w,w],[b,w],[b,0]];

    LC_L := [[0, 0], [0, h], [w, h], [w, w], [b, w], [b, 0]]

LC_L2:=[(0,0),(0,h),(w,h),(w,w),(b,w),(b,0)];

         LC_L2 := [0, 0, 0, h, w, h, w, w, b, w, b, 0]

Note that round brackets do not produce a structure in any way similar to how square brackets or squiggly brackets do. Square brackets [...] construct a list. Squiggly brackets {...} construct a set. But round brackets serve as delimiters, eg. to mark the scope of arithmetic operations. Round brackets do not construct separate substructures which are subsequently accessible separately using the op command or indexed referencing.

note: round brackets also serve to denote a function call, eg f(x,y), but that's not really relevant to the points made here.

[edited]
A few more subtleties worth knowing: You can index into an expression sequence. But as soon as you pass the expression sequence to a procedure then within that procedure it (normally) gets treated as separate arguments instead of as a unified sequence.

restart;

# A list is stored as a container which could hold an
# expression sequence (amogst other things).
expr := a,b,c,d,e:

expr;
                         a, b, c, d, e

L := [expr]:

L;
                        [a, b, c, d, e]

op(L);
                         a, b, c, d, e

# `op` sees six arguments here, the 3, followed by `a`, and `b`, etc.
op(3, expr);
Error, invalid input: op expects 1 or 2 arguments, but received 6

op(3, L);
                               c

# We can unambiguously index (reference) into the sequence.
expr[2];
                               b

L[2];
                               b

# But once passed to procedure `G`, the sequence is seen as multiple
# arguments, rather than as a single argument.
G := proc(U)
  U[2];
end proc:

# Parameter `U` of `G` takes on the value of the first argument passed.
# Here, that first argument is the list `L`.
G( L );
                               b

# Parameter `U` of `G` takes on the value of the first argument passed.
# Here, that first argument is just `a` and not the whole sequence.
G( expr );
                              a[2]

The largest known Mersenne primes have been found using a program named Prime95. It has been highly optimized over the years, with multicore support and use of AVX2 and FMA3 chipset extensions.

The 50th known Mersenne prime (2^77232917-1) took the Prime95 software 6 days to find on a quad-core Intel i5-6600 @3.3Ghz.

I suspect that one important question is whether isprime knows that your trying to do a primality test of a number with the particular form (ie, 2^p-1), and whether it would use a special approach if it did. So Maple might not end up doing something like this and, even if it did, the implementation would very likely not be nearly as well optimized as Prime95. So your machine might well take orders of magnitude more resources than did the machine which actually found the 50th known Mersenne prime.

It looks like you're using Maple 16.00.
 

Here's something...

Download 2_2.mw

Since you're interested in performance you should not be calling diff each time you call w2.

Try this,

w2:=unapply(diff(v2(x,y),x)-diff(u2(x,y),y),
            [x,y]);

If either diff(v2(x,y),x) or diff(u2(x,y),y) return something which contains something other than what you called an "explicit function" or an unevaluated diff call, etc, then show us the full example.

[edited] Below is an example where both u2(x,y) and diff(u2(x,y),y) return unevaluated for nonnumeric arguments x and y. In this case the above approach will not work. So the question becomes, how to evaluate the derivative of this "black box" (non-explicit) function numerically? One way is to use the fdiff command, and variant on that idea is to use evalf(D[..](...)) which has a kernel hook into fdiff.

Since you want the whole call to w2 to run under fast evalhf mode (since v2 might still run under it) then I'll use eval to allow the call to evalf(D[..](...)) to be called from within evalhf.

Download evalf_D.mw

If either of your u2 or v2 is the solution to a numeric pde problem (ie. coming from pdsolve numeric) then you might want to consider that the derivatives in question might be obtainable from the original differential equations (as some function of their terms, all supplied by the pdsolve solution). If so then that would likely be more numerically robust than using fdiff which is a numeric differentiation command and brings with it yet another layer of rough discretization.

The curves meet where the two expressions attain the same value, ie. where the difference of the two expressions is zero. So you're looking for the roots of BesselJ(0,x) - BesselJ(1,x) .

Student:-Calculus1:-Roots(BesselJ(0, x)-BesselJ(1, x), x=0..10, numeric);

            [1.434695651, 4.680102554, 7.836002335]

Here's a slightly more detailed look at it, considering just the first of the three roots:

ans := Student:-Calculus1:-Roots(BesselJ(0, x)-BesselJ(1, x), x=0..10, numeric);

         ans := [1.434695651, 4.680102554, 7.836002335]

x=ans[1];
                        x = 1.434695651

# Evaluate both expressions at that point. They are effectively equal.

eval( [ BesselJ(0, x), BesselJ(1, x)] , x=ans[1] );

                  [0.5479464494, 0.5479464495]

# Evaluate their difference at that point. It is effectively zero.

eval( BesselJ(0, x)-BesselJ(1, x), x=ans[1] );

                                 -10
                            -1 10   

That is not a bug.

By default LinearAlgebra arithmetic commands operate in hardware double precision. The computation of the 2nd entry in your result is similar to this:

restart;

HFloat(1.99987);

                        1.99987000000000
HFloat(-2.);

                              -2.

evalhf(HFloat(1.99987) + HFloat(-2.));

                    -0.000129999999999963478

Vector([%], datatype=float[8]);

                [-0.000129999999999963]

Note that neither 1.99987 nor -0.00013 is expressible as a hardware double precision float with "infinite" precision.

lprint( HFloat(1.99987) );
  HFloat(1.99987000000000004)

lprint( HFloat(-0.00013) );
  HFloat(-0.129999999999999989e-3)

If you want numeric LinearAlgebra operating with base-10 floats and "machine epsilon" like 10^(-Digits), rather with base-2 hardware floats with "machine epsilon" like evalhf(DBL_EPSILON), then you can force LinearAlgebra to operate in software floats rather than its default of hardware double precision floats.

You can do that by setting the UseHardwareFloats Maple envionment variable to false, or by raising Digits higher than 15 and leaving UseHardwareFloats at its default setting of deduced.

Download LA_Add_hw_sw.mw