You could also set (per session) a new default for output that combines units to those dimensions (eg. volume/time).

Download un_useun.mw

Matrix(convert(Q,listlist))

Is this the kind of effect you're after?

nb. It's printing the results to the terminal. Adjust if wanted with strings programmatically returned.

Download CG_ex.mw

I don't see any attempt at calling BarChart (or ColumnGraph) in your worksheet. What did you try and what is the result you expect?

Are you perhaps wanting to do something like, say,

   BarChart(frequences, view = [0 .. ceil(1.08*max(Weights)), default])

or,

   ColumnGraph(frequences, view = 0 .. ceil(1.08*max(Weights)))

or,

   ColumnGraph(map(e -> nprintf(`#mn("%a",fontweight="bold",mathcolor="Red");`, lhs(e)) = rhs(e), frequences), view = 0 .. ceil(1.08*max(Weights)), gridlines)

or a similar effect for BarChart, etc. (Or you could utilize the many options of those commands to change spacing, widths, etc.)

S4_Statistiques_Descriptives_AxeTravail_Complet_ac.mw

That last one produces something like the following, btw,

Your boundary conditions for the plots pltU[j] where you are calling it u(y) = D(psi) are, in fact,

     D(psi)(-1) = 0
     D(psi)(1) = .2e-1

That comes directly from your code,

    D(psi)(1 + x^2/2) = 2*H,
    D(psi)(-1 - x^2/2) = 0

where your parameter data uses x=0 and H=0.01.

So, your claim that "...according to the BCs, they should start from 1" is false, for u(y)=D(psi).

Your plots pltU[j] each show the range y=-1..1, and all use u(-1)=D(psi)(-1)=0 and u(1)=D(psi)(1)=0.02 just as your formulas dictate. They each "start" at y=-1 with boundary value u(-1)=D(psi)(-1)=0.

First let's have a look at an approach using a slightly different "simplification" of the equations, and then simplifying under a simpler extra assumption.

Then we can consider some weaknesses which might be interfering (internally) with the natural attempt using these short assumptions (and why the system seems to need an unnecessarily longer form of the rho-1>beta  assumption).

Download solve_ineq_assump_ex.mw

I'll be submitting the various weaknessess in a bug report (if nobody else has).

For example, to import your two files with sparse storage and float[8] double precision data,

M := ImportMatrix("test-km-1_MASS2.txt", source=MATLAB, format=entries, datatype=float[8]):

K := ImportMatrix("test-km-1_STIF2.txt", source=MATLAB, format=entries, datatype=float[8]):

After that, I can optionally check that they're been imported with storage=sparse and datatype=float[8] (ie. hardware double precision).

rtable_options(M, storage), rtable_options(M, datatype);

            sparse, float[8]

rtable_options(M, storage), rtable_options(K, datatype);

             sparse, float[8]

For plots, the typeset option allows you to get multiple things (text, math, etc) rendered in sequence together but without comma separators.

with(Typesetting,':-mtext'):
plot(x^2,'title'=':-typeset'(mtext("sorta",'fontfamily'="Courier",'size'=30),
                             mtext(" kinda",'fontfamily'="Helvetica",'size'=20),
                             mtext(" works\n",'size'=10)));

ps. I also added some quotes, to guard against the situation in which some of the unprotected global names were assigned values. (mint)

One way is to utilize the plots:-listplot command, with the useunits option.

testSheetHorseShoe_ac.mw

That attachment produce the following, amongst a few other plots.

The plot command works with Maple's usual scheme for procedure calls, and its arguments are evaluated up-front, ie. before the plot routine receieves them.

So when you call,

   plot(kk(3,m)[1], ...)

then the call kk(3,m) gets evaluated up-front, ie. before m gets any actual numeric values.

But when m is just a symbolic name then the sort actions inside your kk procedure don't act the same way (for generic name m) as they would for all the numeric values of m.

The key thing, then, is to delay the evalutation of the argument k(3,m)[1] passed to the plot command until such time as name m gets actual numeric values. That avoids the so-called premature evaluation.

This is a very common user-issue.

Below, I show you code for two ways to delay that evaluation, for your plot attempts. The underlying problem and its possible alternatives are the same here for plot3d as they are for plot, so I'll leave those for you to adjust according to whichever approach you choose.

Download gra423_Omega_ac.mw

nb. You could also delay the evaluation with single right-ticks (aka unevaluation quotes), by instead doing it as,
      plot( 'kk(3,m)'[1], ... )
but I didn't show that above because quotes seems to confused some people (and also because the uneval-quotes are ephemeral; if you pass around an expression with them then they vanish, upon intermediate evaluation...). Definitely not the best choice.

ps. There are several kinds of ways in which the issue of premature evaluation can be an issue. Another common case is where an error message occurs when the plotted procedure call gets accidentally evaluated. As you can see from that link, that error is common enough that it has its own special page. Your situation is more insidious because instead of a helpful error and stoppage your code merely procedes with wrong values (which for another example might possibly be overlooked).

Using implicitplot3d for generating a plot of a plane is a relatively very inefficient way to do it.

But first, to address your particular query: No, you don't need the plots:-display call, and that's not actually what made it work for you. What made it work for you is that your large plot structure by default needs a separate printing, without being in an assignment statement, in order for the GUI to render the plot. See the attachment below, for an example.

A more efficient way to construct the 3D plot of the plane would be to use the plot3d command with the minimal grid=[2,2] option. (Using a small plot structure will get better GUI performance if you have to rotate it much, or use it in an animation, or export it, or transform it, or right-click adjust it much, etc.)

Download 2025-05-18_Q_display_a_simple_plane_ac.mw

nb. For this example, the plt0 structure is about 1000 times larger than P.

Here are a few ways, producing either Matrices or DataFrames. Choose which you'd prefer.

The key bit seems to be removal of the datatype=truefalse from the inner Matrix, so that arbitrary substitutions can be made. That datatype restricts what kind of value can the stored entries can take.

I've split these into a few steps, both to show an idea of what's going on as well as to allow you to just take the generated Matrix rather than the new DataFrame (if you prefer).

Download TT_dt.mw

You can use Or(x<1,x>1), to forestall difficulties with assuming x<>1 (both at once, which can sometimes accidentally turn into `false`).

Download odetest_challange_may_15_2025_ac.mw

ps. I do not recommend using simplify(...,symbolic), if you really care about whether the result is correct.

It's pretty easy to just do the brute force check, with a double seq/loop, and quite quick for just going up to 100.

So, for a fun alternative,

Download sol_fac.mw

Since N=7 is small there are even more lightweight and very fast alternative approaches. (Even the cost of the F procedure calls is slightly wasteful here.) Perhaps the nice typesetting of the solutions is the more interesting bit here, and naturally you can use that no matter how you compute the solutions.

Another way, for the second problem,

Download test1_ac.mw