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.

@9009134 The option explicit means something different when used with a dsolve command than with a solve command. For dsolve, use implicit.

What makes you think that the result is close to 12.319?

@Mac Dude Surely I am neither saying that all Indians are spammers nor that all spam comes from India!

There is no need to look at any logs or ferret out anything. That would be a waste of time. There is nothing special about MaplePrimes. Any message board on the Internet which doesn't block spam will be flooded by it. Spammers are not trying to target MaplePrimes users, or to sell them anything, or to advertise to them. It's all about Search Engine Optimization (SEO). The techniques for blocking spam on message boards are well known; they just need to be implemented here.