@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.

@dharr 

Well… not really. I didn’t know that a differential equation was named after Bessel, who, much to my shame, was from my hometown. Until now, I had associated Bessel with astronomy, Airy and circular phenomena. 

Now I looked him up and everything fits much better together.

Thank you for mentioning this!

@janhardo

Thank you for providing AI answers. I am an AI laggard and did not recognize it straight away. The summary charts you provided looked like conference posters and are very helpful provided that the content is correct.

For me the AI output is difficult to verify. I have a few questions:

• an I assume that the summary charts summarize the underlying code exactly?
• Would it be possible to request code that formats more in a Maple style? A simple Maple command (e.g. plot command) does not need to be put in a procedure (and formatted like a procedure). It would also be nice to have explanatory text formatted as Maple text and not as code comments.
• Is it possible to produce a tabulated summary chart of the results clearly distinguishing ICBC and heatflux? Even with hidden input I am losing track./li>
• Which tools are you using?
• I have noticed in your previous answer that the output does not change if BC4 is not defined. Is that still the case for all the ICBC variants?

@ecterrab 

If ExaktAI can get us to the point where a step by step solution of differential equations can be verified, this would be a huge improvement. Here is an IBVP where verifying an AI solution was not possible for me (in a rasonable ammount of time). The comparision to the human made solution is interesting in itself.