I found a way with simplify which factors the units out of the inner integral and the warning disapears

Download Unit_of_t-2.mw

@Jankel 

The one bellow is from a Windows installation version 2022.2 (on a 4K display at 250% scaling on a 15.6 display).

Java in combination with making Maple available on three operating systems could be a reason why rendering it not always the same in all possible combinations of hard and software. Other potential candidates to look at are, compatabilty settings (properties of Maple executable), graphics cards (type and settings) and font scaling in the operating system.

Under Windows I see other rendering issues which appear when changing displays while Maple is running (you see it bellow: + button are larger than in your screen shot and the question mark does not render well). Program restart is sometimes required and in some rare cases even a system restart. With newer Windows versions the situation has substantially improved.

On my machine it does not look like a font scaling issue (I testesd it also with 125% on a larger display) but I wanted to make you aware on other sublte changes in rendering that could give you a hint under which conditions changes in font rendering happens.

@zenterix 

If sinc(x)=sin(x)/x was transcendental you should have gotten at least one answer.

I have checked help(solve, detail) and I am not so sure any more about Maple retruning no Output. At least one solution should have been returned according to:

The solve command returns all solutions for polynomial equations. In general for transcendental equations, the solve command returns only one solution, but does not set _SolutionsMayBeLost to true. To force the solve command to return the entire set of solutions for all inverse transcendental functions, provide the solve option allsolutions = true or set the environment variable _EnvAllSolutions := true.

@zenterix 

I can only guess that allsolution is not needed in most cases (I don't use it by default). Take phi=arctan(y,x) as another expamle for a solution. Most users would probably prefer it instead of the general solution

There is allways room for improvement. The fact that Maple did not return anything in your example even though there are solutions is debatable. It would be nice to distinguish from a user perspective between no solution and too many when Maple produces no Output.

I have to admit: By convenience I did use the context panel (plus right click show command) to find the appropriate solve command for sin(x)/x.  This was pretty user friendly.

@Carl Love @acer

Sorry, I did not get a notification for your replies and only could check for answers today.

Physics:-Version() gives:

`The "Physics Updates" version in the MapleCloud is 1343 and is the same as the version installed in this computer, created 2022, November 2, 11:29 hours Pacific Time.`

Interestingly, a parameter set with units in a simliar example from @ecterrab on equation(6) worked

@WhiteNoise 

I thought converting your working Heaviside version to piecewise might give a clue what must be changed in the piecewise definition to make it work. As you can see it’s not working either. Converting this back to Heaviside gives an expression that does not evaluate at all because of the now appearing units in the Heaviside function.

Could you elaborate why Heaviside is not an option in the general case? I think this forum can help you with a solution that converts a general piecewise case to a Heaviside solution with dimensionless arguments.

You should contact support if no one else can help. Piecewise with units should work.  

Download UnitProblemSecondVersion-_convert_piecewise.mw

@acer 

Best: better than a sequence of two commands (or your nested version). I was hoping for a single command.

Improve in the sense to include the case sqrt(m*something)/m^-1 when combine,radical,symbolic is called (altough I try to avoid the symbolic option).

Thumbs up for including the m>0 as a relation for solve instead of adding an assumption to the command (what I tried)! This makes totally sense. I will leave the question open why the assume facilty does not do it automatically. I assume that there will be too many exceptions to deal with in the R^n space.

Many thanks!

@ecterrab 

Very nice feature! Is it possible to make it work with ODESteps?

arbconst_with_ODESteps.mw

@Carl Love 

I wrote an addendum under my reply  "No ranges or assumptions".

I hope that fixes my hasty deletion.

@Carl Love 

Thank you for clarifiying. I overlooked the extra dot. I will delete my reply. There is nothing to investigate.

@jediknight 

I cannot fully reproduce the output of your code snippets (see attached). Consider the upload option (green arrow in the editor if you hit reply) if you want others reproduce what you observe.
Have you tried using maximize without ranges or appropriate assumptions? It might work with your version.

maximize seems to have troubles with the expression of GainQ1 in combination with the ranges you provided also in Maple 22

snippets_recap.mw

Update (after deletion of reply):

Maximize has no troubles. It correctly calculated Top_of_Q1 for degenrated ranges.
The deleted file with my wrong interpretation of the ranges from my side for completeness  maximize_wrong_maximum.mw
 

@jediknight
This assignment is causing the problem wx:=solve(GainQ1=Top_of_Q1);

Each time you execute this line

     Top_of_Q1:=eval(maximize(GainQ1),wx=0.1..2);wx:=solve(GainQ1=Top_of_Q1);

GainQ1 changes. This changes Top_of_Q1 which changes wx. And so on...

Here is an alternative way Maple offers without assignments (i.e. `:=`), where you get an equation for wx(Top_of_Q1). Using this way you will hardly run into errors related to unintened assignments.

Download WO_assignment.mw

@Joe Riel 

Including a code optimization option in the custom component template (and making the intermediate variables disappear in the parameter pane) would be much more convenient than my separate Maple worksheet or inserting the commands into the template. Also, every user of a custom component could benefit from code optimization without having to learn the required Maple commands.

I would definitely use it!

@acer

If its by design, I will make the type specification my default. In my example the value of la is smaller than 0.5 which leads to errors of 50% and more (red C code vs Maple code in green).

By the way, codegen also has an undocumented design “feature”. When codegen is used in my original worksheet instead of CodeGeneration, the parameters defined as outputs appear as “passed by reference” in the C code. This works also with other names than outputs. Very handy. With CodeGeneration[C], “passed by referenced” must defined manually. (Since codegen is deprecated I will not ask, how codegen magically predicts what the outputs are.)

Thank you for the clarification!

@acer 

Sorry for the confusion.  

I found the type double as a synonym for float[8] here: help(type, float[8]). If the parser replaces it with float[8] I don't see a problem (if...).

The comment is more of a personal note. I meant: Type definition to double was added to get all parameters defined as double in the C code output of a subsequent call to CodeGeneration.

What is still not clear to me:

In the equation list there is one equation (t54 = 1 + 200 * la) that can be interpreted as integer relation. This could be the reason why CodeGeneration defines “t54” and “la” as int.

What I just tried: When this equation is inserted into an evalf call, "t54" and "la" are defined as double in the C code (without requiring your solution).

codegen neither requires your solution nor evalf workarounds (which make the code less clean).

With these observations I would ask now: Is this (assumed) interpretation of such equations a design feature or something unintended (i.e., something that should be reported)?