@Carl Love 

My key challenge here (again…) is that I do not have gained enough (intuitive) understanding of Maple’s evaluation process yet. Maple's evaluation machinery is still a grey box for me.

My current interpretation of your code: Your call to local declares check as local name and then assigns params to check. By calling assign(check), check fully evaluates to params. Then assign is  executed with the argument params. What makes this different form calling assign(params) directly? Do the names in params inherit locality from check? Is there anything that explains what happens in your code in ?local_scopes (which I consulted before writing the post).

Also, Acer mentioned a second `assign` call in my code. However, I can only identify one `assign` call. This tells me that I miss something what is going on in my code.

From the attached attempts I conclude that the declaration params::uneval is essential. Therefore, type checking cannot be performed in the parameter declaration of the procedure and must be done inside the procedure. Is that correct?

local_assignement_attempts.mw

@Carl Love 

I wanded to achieve what

local b:=2,c:=3,d:=4;

does without doing it explicitly as in janhardo's example.

I also tried 

local assign(params[]);

Instead of print I could have used a type/local check

@acer 

I have rewritten my original post. The objective is to only assign locally without entering the parameter names explictly.
The example I have given is not the best one. I was supposed to show an attempt of declaring local names before assigning them to values using the assign command.

@acer 

I upvoted as well. What made me hesitating with my version was the use of sets and "minus" which AI considred clear and concise (which I did not, hence the post).

What I realized when it comes to simplicity, a level of understanding of Maple's language should be indicated. I did not. AI so far boils Maple code down to an ordinary computer language. It looses all its beauty.

My current favorite is this modification

remove((p -> convert(p,'unit_free')=convert(simplify(p),'unit_free'))@rhs, [L]);

only because I like one-liners.
This is more than debateable because it removed the name of the helper function which can be used to explain the action of the helper function, makeing further code comments dispensible in the best case. Understandable code without comments is a strong criteria for simplicity.

@dharr

I am still undecided.

“Simple” can be interpreted in two ways: either that as little code as possible is used, or that the code is understandable. I will focus on the second interpretation in the following:

I had a version with evalb that created a list with true and false values. I did not like it very much because looking up which parameters were not in SI base units was not obvious at a glance. Applying remove the way you did makes it much easier.
Because I was somehow preconditioned, I decided to ask Maple AI which of the two version is easier to understand. The AI pointed towards two elements that are not easily understandable in your version, which are the type declaration and evalb. AI provided improved versions which all did not work… which led me to use a large model … which consumed a quarter of this month credits, still throwing errors. AI also proposed a “simpler” version of mine by splitting up processing steps in several statements. For me, this is a bit too much of simplicity.

However, I also noticed in my attempts that one extra statement can improve readability and simplicity allot. Defining a new one-argument function (as inbaseunits) also enables function composition. My attempts to define a real functional operator (separating functions from arguments) have definitely not led to anything simple. Here is where I stopped:

((((`{}`@op)@(`~`[round]))@(`~`[op]))@simplify)(`~`[`-`~([(Units:-Split)@rhs], [((Units:-Split)@simplify)@rhs])]([params]));

Functional programming driven ad absurdum.

The reason in this case, I think, is that there is no single argument function that extracts only the coefficient of a physical quantity. Again, an indexed version of op (i.e. op[i]) would have helped.

So, as of today I am undecided about my favorite version, but it looks like that two-liners can provide a good compromise of the above two interpretations of simple.

@janhardo 

This new worksheet is easier to follow than the previous AI worksheets you provided. Some more thoughts:

• Since the solutions are symbolic, I am wondering why numerical values for parameters are used right from the beginning. Personally, if possible, I would go for the general solution with assumptions on the parameters and then investigate particular solutions.
• I am also wondering whether a skilled programmer would implement part of the code as modules. Shouldn't simple procedures handle (all the input) equally good with less overhead?  
• I would also pretty print essential input as the pde in 2D-Math. AI does not really exploit the benefits of using Maple. The whole output formatting looks inconsistent. I am more and more inclined to say that beauty of well-made Maple documents is not achieved by todays AI. For me, there is no joy of studying AI output.
• Also parameters are not defined and what they physically represent is not explained. Typical input errors like inconsistent units are not handled. “k” in the pde and “k” in the boundary conditions are not the same physical quantities (thermal diffusivity vs. thermal conductivity).
• Maple provides sophisticated functionality for symbolically handling expressions with units but the AI is not profiting from it.
• Explanatory text passages are only provided as code comments but not as Maple text passages.

Maybe with improved prompts some of the above could be fixed.

It’s still 1D heat conduction what we are discussing but it completes the picture of options. Ultimately, I want to modulate spatially and temporarily the heat distribution in an easy way. It looks like that I have to do it myself numerically. I will use symbolical solutions to verify the output and Maple units to guarantee as much as possible consistent and meaningful input. I will also use 2D-Math for better readability and clarity of input and output.

Thank you all for your contributions!

@dharr

Thank you for clarifying the list and simplification questions.

I am currently modifying code that required parameters in SI base units. For better readability and clarity, I thought of adding units to values and then removing them to make my old code work. To avoid data lookup errors (some references use KJ instead of J for example) I thought of a consistency check before removing the units. Hence the questions. I did not think any further. Now I have realised the that simplify as I have used it in my code construct removes unit inconsistencies and makes the check pointless if simplify is applied before convert/unit_free.

So, for the case of numerical integration the check is not needed, but the question remains whether such a check cannot be done in a simpler way.

@dharr @Ronan

I think this a little bug combining unit brakets  and the arrow operator. In all other cases quotes (name ticks or uneval quotes) are removed from the output and names are printed in roman. 

The altered output is unrelated to the piecewise function. 

Converting the 2D-Math Input to 1D-Math creates the same effect.

piecewise_and_arrow_operator.mw

@dharr 

No I did not want them there. I am lasy and use  instead of Units:-Unit and type without uneval quotes. This has always worked so far. Maby I have been lucky because I avoid the assigment operator as much as I can. 

@dharr

This is what I get when converting your input back to 2D-Math

I would have expected the arrow operator to procude the same results as MakeFunction. I do not understand what is going on here.
piecewise without the arrow converts nicely back and forth.

Is that something to report?

@Ronan

Yes it does! Even without ticks it works.

What I do nt understand is the following:
Originally I entered the piecewise function in 2d-Math using  from the favourite menu and typed without ticks. Maple added the ticks in the output.

When I convert now your code snippet with backquotes from 1D-Math back to 2D, the ticks (unevaluation quotes) are back in the output but not in the input.

So far I tought that putting unevaluation quotes around names in the Unit command or using  is good practise.

@dharr

I'm also more interested in investigating problems than in optimizing algorithms. Most, if not all, of my cases can be solved nowadays —at worst—using brute-force methods with a little waiting time thanks to Moores law. However, what I do not like is using code that I do not understand, may it be AI generated or tools with not sufficiently documented parameters.

I leave unverified traces here, if someone likes to drill down further on elastic coordinates:

• P. Shi and J. McPhee, "Polynomial Shape Functions and Numerical Methods for Flexible Multibody Dynamics", Mechanics of Structures and Machines, vol.29, no.1, pp.43-64, 2000.
• Allegedly, the term elastic (perhaps as flexible or deformation) coordinate was introduced in the book "Dynamics of Multibody Systems" by S. A. Shabana to separate a body's rigid, macroscopic motion from its internal, flexible deformations.

Thank you for sharing the differential quadrature method.

@dharr

Do I understand correctly that the a problem is reformulated in a way that weighting coefficients of a function (suitably well chosen to approximate the unknown function for all time instances) are integrated?

This would require a priory knowledge (like BesselJ in our previous discussion).

If this interpretation is correct, then the method should be quite similar to what Maplesoft has implemented for "continuous" components like flexible beams and the, for me, mysterious elastic coordinates

are not the classical shape function of finite elements (which use states at the element boundaries at nodes that have coordinates).
A Maple worksheet like yours, which illustrates that elastic coordinates (in my opinion, a misnomer) are nothing more than weighting coefficients of functions that approximate a state of bending, could put an end to the speculation.

@nm 

The overview and examples were very helpfull. 

I could refine searches. There seem to be Phyton implementations that do the discretisation step. 

(without further checking:

sympy.calculus.finite_diff).

If the generated equations are not indexed (one index per indepent variable) those tools are not what I am looking for.