The following factored form is simpler than that obtained by
applying just evalf, or evalf and simplify, or expand and evalf, etc.

Download worksheet_ac.mw

@Khair Muhammad Saraz 

Is this anything like the kind of static 3d plot you're after, for your followup example?

I can only guess, since you haven't explicitly described what you're actually after.

dq_code_1_acc.mw

Does it help to use an assumption on n?

Using Maple 2022.2, and guessing at your intention,

Download rsolve_ex_simp.mw

If you put assumptions on only x, then coulditbe(y=1) evaluates to true. There's nothing preventing y from being equal to one, there.

You're also seeing behaviour of coulditbe and RETURN. The int procedure never actually gets invoked here. The arguments to the call are evaluated up front. The int procedure never gets the opportunity to make any inference that y is between 0 and the assumed x, or make that assumption internally.

Download return_ex2.mw

But the bit about evaluation of arguments is more key here than RETURN quirks. The first argunment to int is evaluated before int does work. Even if you had f(coulditbe(y=1)) instead then that too would be evaluated before int got to do any computation (except automatic simplification), including making any inference or further assumption on the variable of integration.

The main thing happening here is that the int procedure gets the standard evaluation rules for procedure calls. Its arguments are evaluated up front. So the coulditbe is evaluated before any connection between y and assumed x can be made by int.

Download eval_rules_int_assuming.mw

And so delaying evaluation of the integrand would get the original example as the OP expected, because the int procedure would then get to examine the passed range and place further assumptions upon the variable of integration before the integrand got evaluated.

Download eval_rules_int_2.mw

It's not easy to give a Library command special evaluation rules, (eg. using type uneval for a procedure parameter) so that some of its arguments are not evaluated up front. Doing so would allow int to place assumptions on the variable of integration before its first argument the integrand were evaluated. It's very hard to make that work properly, in all corner-cases, for a complicated Library procedure. (In contrast, the add command is a kernel built-in, and the kernel can get it just right...)

The behaviour exhibited in the Question is not related to the "depth" that assuming can penetrate. The assuming mechanism would/should not utilize a range found in some general function call's arguments, to make a further assumptions. That would be misplaced as a general rule, though it might be reasonable as an int-specific action. [edit: Something like this might actually be going on, because assuming does have delayed evaluation.]

If you mean an object in Maple's own technical use of the term, then yes.

The object module can have its own ModulePrint command. (Unfortunately there's only one example on the ModulePrint Help page, and it's not a very interesting example.)

Here are a couple of examples from the GroupTheory package.

Download ModulePrint_ex1.mw

The lack of automatic combining/simplification of units in the resulting Vector seems related to using elementwise +~ . If I instead use good ol' map then it automatically combines. I'll submit a report about that aspect.

I'd have expected to see a result where the Res2 entries were in terms of Unit(s) the default unit for dimension length in the default SI system.

If I set the default unit for dimension length to minutes (instead of seconds in the default SI system) then the top-level arithmetic automatically gets to Unit(min) here.

QuestionMP_ac.mw

I don't know how that'd pan out for more involved examples that you might have.

The following attachment contains as much as I was able to recover.

Fysik_1_F24_-_Opgaveregning_ac3.mw

Your original was last saved with Maple 2023. I suggest you upgrade to Maple 2024, if possible, as it seems to have less instances of this kind of problem.

Up until Maple 2022.2 simplify would apply the custom routine separately to any non-numeric side of an equation. It has never worked on an equation as a whole; only on both sides separately.

Hence, even when the extension mechanism was previously working, your example's (rhs-lhs) is misplaced since the custom procedure doesn't receive a whole equation.

Here I use M2022.2,

Download simp_ext_1.mw

Download simp_ext_3.mw

So even where that classic extension mechanism for simplify was functioning it seems like not what you're after, because of this mapping to both sides of equations rather than treating them whole.

In Maple 2023.2 and 2024.0 those examples are not invoking the custom routine at all. (I haven't tracked down the precise reason, perhaps in `simplify/do`. It does check that `simplify/denom` is the name of a procedure, rather than throw an error about an unexpected argument to simplify. I will submit a bug report against that regression, but as explained a fix for that wouldn't help your example.)

The mechanism (when previously not busted) does operate on unevaluated function calls to nodenom. simp_ext_4.mw But that just makes more acute the following query, which could be asked regardless: What would be the benefit to you of calling simplify(eq, nodenom) when you could just as easily name the custom proc something shorter and apply it directly?

Are these the kinds of things you're trying to accomplish?

Download indets_ex.mw

If your Matrix M is datatype=float[8] then you could accelerate using either evalhf or Compile.

I use one of dharr's quicker procedures for the evalhf variant, but now faster.

The Compiled version is about 30 times faster than the "original"; it varies by run, and version.

I keep the original non-hardware-datatype constructions only for comparison.

Download tests_ac1.mw

These are just toy examples, deliberately intended for illustration and comparison rather than some "best" way to do the computation. (Please don't respond with a better way to do it. That's not my point.)

One possibility is to split out your purely floating-point and evalhf'able computations into their own dedicated procedure(s), and then do any non-evalhf'able or symbolic operations separately. I don't bother showing that for the following example, because it's trivial.

But sometimes such splitting involves complicated rewriting of one's existing procedures (which already mix those two aspects in more involved ways). Sometimes one of the following simpler code revisions is possible instead of such inconvenience.

Download hfloat_evalhf_none.mw

2024-05-14_Q_Data_Table_Limit_Equation_lentgh_ac.mw

You asked, "What is the problem?"

The problem is that the answer depends on the variables. The answer changes according to the signs of both a and b, even if all of a,b,h are taken as real.

Download trip_int_ex.mw

Your call InitState(5,5) calls Coherent(1,Pi/2,5) and that returns a 1-Vector.

Your call Coherent(5) returns a 5-Vector.

You've set up both InitState and Coherent with keyword parameters. You haven't set it up with optional ordered parameters.

When your InitState calls Coherent(1,Pi/2,5) then that "1" becomes the value of n_max (the first required positional parameter). The other two arguments, Pi/2 and 5, are thrown away. In particular, that's not the way to pass them along for the zeta and phi keyword parameters of your Coherent.

Perhaps you instead intended something like this?

InitState := proc({zeta:=1,phi:=Pi/2,L:=1,sigma:=0.01,beta:=0.02,k0:=-5*Pi},d1,d2) 
  local z1, Z0;
  z1 := Coherent(d1,':-zeta'=zeta,':-phi'=phi);
end proc:

That would utilize the value of d1 for the required parameter of Coherent. It would also pass along the values of zeta and phi to Coherent.

See next attachment for more detail.

test3_2_ac.mw

If you wanted to use optional ordered parameters instead of keyword options then you'd also have to shift the required positional parameters to the front. See next attachment. Notice the absence of {...} braces around the declarations.

test3_2_acc.mw

See also here.

Your previous Question was marked as Maple 2023, so I'm guessing that's the version you're using now.

In Maple 2024.0 the plot3d command supports the colorbar option (introduced for 2D plots in M2023).

But in fact one can attach a COLBAR plotting substructure into a PLOT3D plotting structure, even in M2023.

In the following example the image of the plot is from a single file that I manually exported using right-click. That single image file contains both surface and colorbar.

Here I used the 2D contourplot command as a quick way to construct the colorbar. But it sound as if you've already constructed your own 2D color-bar (for use in your Tabulate). Just wrap that 2D color-bar plot in a call to COLBAR, display that to the desired smaller size, and add that as a last argument to the PLOT3D structure.

Download colrbar3d.mw