@digerdiga Trying your original code in Maple 2016, I don't get a crash.

@digerdiga No, it has nothing to do with the log. If you use int, then every time that you call the procedure, it will attempt to do the integral symbolically first. That attempt will fail and will be in vane---a complete waste of time.

@digerdiga No, Int is not really needed. But compare the time difference between using Int and int.

Would you please provide a derivation/justification for your second rule: h(x+y)=(x/(x+y))*h(x)+(y/(x+y))*h(y)?

When combined with the other rules, it seems to imply (1+1/z)^z = 1/(1+z) (where z = x/y), which is ridiculous because it has no h nor is it true for all z. (I did that very quickly, and mostly in my head, so I may have made a mistake.)

@DSkoog Okay, I see that the conversion from numeric to float via datatype= float is a special case of data coercion that DataSeries seem to inherit from their underlying representation as rtables. And I see that dtype is also an object member independent from the underlying rtable. I can't see yet what purpose that serves. (But I do see that the rtable may have datatype = float[8] with the corresponding dtype being simply float.)

I see that there are two roughly orthogonal operations at work here: the very common operation of converting the data and the uncommon operation changing the dtype of the container (uncommon because datatype = anything is appropriate for the vast majority of uses). The conversion of the data can be handled by mapping the appropriate conversion command. (And note that your example mapping operation, ((x)->convert(x,name))~(DS), is better done as convert~(DS, name).) The relabeling is appropriately handled by the object constructor DataSeries(...).

There's two very separate things that would bother me about the proposed command SubsDatatype: The first, and most irksome, is that the equivalent doesn't exist for rtables. If I were a new user, I'd have trouble remembering that. The second is that I, even as an old user, won't be able to remember the possible second arguments to SubsDatatype.

These are just some things to consider. I'm not totally opposed to the new command.

@Christopher2222 I give an upvote to every zero-reputation user who posts a legitimate Question.

@DSkoog 

I'm really sorry to be such a downer about this, but the proposed command

SubsDatatype(DS, float)

has an end result identical to the existing command

DataSeries(DS, datatype= float).

The existing command seems logical enough: It matches a nearly identical command for Matrices. I deduced its existence on my first try. Sometimes having fewer commands makes a language easier to learn. The proposed command lacks a property that I call "orthogonality".

@samluv I wasn't implying that you should remove the constants because they play no role. I was implying that the fact that they can be proven to play no role as written shows that the conditions themselves must be written wrong. And now that you've supplied the original conditions, I think that I see part of what's wrong. It looks like many of the conditions are specified in terms of second derivatives, not first. And I think that you must think that D[2] means a second derivative. No, it means the first derivative wrt the second variable. So, if the function is w(x,y) then w[x,x] (the second derivative wrt x) is denoted in Maple as D[1,1](w), and this restricted to x=a would be D[1,1](w)(a,y). Likewise, the second derivative wrt y is D[2,2](w), and the mixed second derivative is D[1,2](w) or D[2,1](w) (it makes no difference which).

Now we still have the problem that w = 0, everywhere, is obviously a solution to the problem.

Your "original" boundary conditions have B[1,6] and B[2,6]. I don't see any Bs in your Maple statement of the problem.

@samluv w(0,y) = 0 is the correct way to specify a condition on the whole edge x = 0. But note what I said above about your four first-derivative conditions.

Why would there be a built-in function for something that is so trivial to construct from the existing built-in functions?

Anyway, your function can be replaced by parse~:

toNumeric:= parse~;

Note that by simple factoring any condition of the form A*f(x,y) - B*f(x,y) = 0 (where A and B are arbitrary constants) simplifies to f(x,y) = 0. Your last four conditions are of this form. So the constants are playing no role in the conditions. This is consistent with Tom Leslie's finding.

Once you correct that problem, I think that you want two of those D[2]s to be D[1].

@awass 

I'd rather use the quotes once---inside the procedure---than need to use quotes every time that I invoke the procedure; so I don't consider your alternative a simplification.

A numeric is manifestly a rational number: an integer, fraction, or float. A realcons is something that would become numeric if evalf were applied to it. In the case at hand, it wouldn't matter if you used realcons instead of numeric because evalf is used inside the procedure. Types have help pages: See ?type,numeric and ?type,realcons.

A bound variable with a common name like t that isn't declared local is a dangerous and foolish thing. If you were to assign a value to t for some unrelated reason, then your procedure would stop working. Maple makes an exception for the bound variables in seq, add, and mul. These are given some special protected status that's almost as good as being local.

I'm not a Groebner user, but randpoly is my go-to for constructing examples.

@mskalsi You need to freeze & thaw the g(u[x]):

thaw([coeffs(subs(g(u[x])= freeze(g(u[x])), %), du)]);

This can also be done by frontend:

frontend(coeffs, [%], [{`+`, `*`}, {}], du);

@9009134 I agree with Preben. In this case, it's difficult or impossible the remove the RootOfs before numeric values are substituted for the parameters.