There are two main ways to get a subscripted name.

One involves a double-underscore (so-called Literal Subscript), and another involves an indexed name (so-called Indexed Subscript). The actual constructs for those would be g__n and g[n], respectively.

The ScientificConstants package uses the latter, ie. indexed names, to refer to its constants.

In 2D Input mode you can get the typeset subscripted form for input with the keystrokes,
    g Ctl-Shift-underscore n      (Windows, Linux)
    g Cmd-Shift-underscore n    (Mac OSX)

For example, using those keystrokes,

Download 2dmath_indexed_entry.mw

You can also enter g[n], literally, in either 1D or 2D input modes.

See this Help-page for 2D Input ketyboard shortcuts.

You wrote,

Consider the expression 5m+x. This expression works in
Units:-Simple but not in Units:-Standard.

Units:-Simple adds a quantity 5m to a quantity without units.
But why can one add a quantity with units to a quantity
without units?

Units:-Standard tries to add a quantity 5m to a quantity
that is assumed to have units. What units are assumed?

The point is that the name x might be evaluated later on at some value involving some unit of dimension length.

One can evaluate x (in expressions containing x) with pretty much whatever value you want, in general. And for the expression 5*Unit(m)+x some later value like 3*Unit(mm) or 8*Unit(km) is quite fine. So the expression 5*Unit(m)+x can be allowed. So that's one thing that the newer Units:-Simple does, which the older Units:-Standard does not: it allows such an addition.

You asked, "What units are assumed?" But it's not some specific unit that's taken. It's the dimension of length that is taken.

And with the notion that the x in expression 5*Unit(m)+x can be considered as having dimension length, further dimensionall anaylsis is possible. That dimensional analysis may help with further symbolic manipulation.  That dimensional analysis can also help in the front- and back-ends of commands that are taught to understand units more, eg. plot, fsolve, etc.

Since you have Units:-Simple loaded, you don't need to do combine(...,units) or simplify to get the simpler units you originally showed.

You can instead accomplish your simplification/combining of units, directly upon substitution, by merely using eval instead of subs.

I also show how the J/mol form can be attained, in two ways.

Download Units_-_Subs_zent2.mw

I just use with(Units) to get Units:-Simple as default. (That's not showing in the sheet as inlined in this forum.)

ps. If you inadvertantly create an expression with over-complicated units then you can use combine(...,units) on it.

If you specifically want to avoid additional non-units-related simplifications/changes then IMO combine(..,units) is better than calling simplify. nb. also, simplify doesn't handle your original subs result in 2022.

Is this the kind of thing that you're after?

Download acf_ex2.mw

It looks as if you might be encountering premature evaluation of the first argument you're passing to NonlinearFit.

You are passing,
   p__eng1(C__10, C__01, kappa, lambda)
which will evaluate with all its arguments as mere names without numeric values. That may cause the call to solve inside procedure r to return a list, which could be where those square-brackets are coming into it.

What might work instead is to prevent that evaluation until the parameters get actual numeric values. So you could instead try passing,
  'p__eng1'(C_10, C__01, kappa, lambda)
to delay the its evaluation.

It would be easier to test outselves if you supplied the actual data (file) which you are importing. (Possibly attached here as a .zip file, depending on its filename extension). It's also difficult to tell whether fsolve might get better speed than solve here, without the actual data.

First, if you want to use capital D as a variable at the top level like this you could issue,
   local D:
at the start of your worksheet. (Or use a different letter. The protected name D is the name of the differential operator and doing otherwise will run into issues.)

Also, fix your syntax and remove errant [...] as C_R suggests.

Thenm try using solve here instead of isolate, supplying assumptions if you have them.

Eg,

   solve(T4, rho) assuming 0 < 4*Co*D^2*theta

etc, instead of,

    isolate(T4,rho)

as one example.

Another example might be, say,

   solve(D2, rho) assuming 0 < delta*D

ps. Your problem is mainly your choice to try isolate which is not the right command here. It's not related to whether you use eval.

Download minimize_ex_2022.2.mw

ps. You may wish to subsequently unassign that environment variable, if you don't want it to affect later solve calls,
    _EnvExplicit := '_EnvExplicit':

pps. I will submit a bug report.

You can add,

   axis[2]=[location=high]

to you plot options, to get the effect of the tickmarks and label on the other/right/upper side of the vertical axis position on the right.

Or you could add,

   axis[2] = [location=low]

if you'd prefer the label/tickmarks to the left/lower of the vertical axis positioned on the left. (This combination happens to render similar to axes=frame.)

For the images above I also altered your size, just to make it all a bit smaller. In the following attachment the same effect is attained using your original size setting (so you can examine that, to see the automatic tickmark values actually generated).

axis_label_on_wrong_side_of_axis_ac.mw

Here is your original axis effect, that you did not want,

@Ronan In light of a few followup comments it seems that you already had a decent mechanism for adding spacing above or below the symbol, including multiple depths.

And it seems you also want to deal with another problem: that the name you wanted to show/render was already assigned a value.

Note. lowercase `typeset` does nothing to avoid an assigned name evaluating to its assigned value. Rather, that lowercase `typeset` serves mainly to allow you to mix math & text nicely, in plotting contexts.

But Typesetting:-Typeset can indeed turn a name (even if assigned) into a form that will not subsequently evaluate to a value assigned to that name.

So it seems to me that all you need is that Typeset along with "\n" newline characters. eg,

     typeset(Typeset(thename),"\n")

though naturally you can also have the newlines before/above, or multples.

Obscure stuff like that `mover` seem like quite unnecessary over-complication. And it needs more effort to shoehorn in a general expression. And it gets quite awkward (nested) for adding multiple vertical spacing above and below.

ps. single right click uneval quotes alone (to prevent evaluation of an assigned name, eg. 'gamma2') is not generally adequate here, since accidental full evaluation of the plot structure ruins it.

There are many errors in your "chelishkov_comparison" worksheet. Here are some adjutments,

chelishkov_comparison_ac.mw

I don't understand what you intend with your Matrix arithmetic in the other worksheet. It doesn't make sense to me.

@Earl I missed this before:

You have the assignment,

   libname := "C:\\Users\\earls\\OneDrive\\Documents\\Earl's documents":

which is not OK (unless you've made a full copy of the stock .mla Library archive in that location, eg maple.mla).

What you likely intended was something like,

  libname := "C:\\Users\\earls\\OneDrive\\Documents\\Earl's documents",libname:

which prepends your location to the stock location. That's what I mean by "augment libname" earlier.

As you had it originally, Maple is not able to find its own stock .mla Library files (unless you made the very usual move of actually copying them to that personal folder).

Try `ODEtools/odeadv`, for showstat or stopat.

The ConditionNumber command in the LinearAlgebra package computes or estimates the conditioning w.r.t. solving a linear system Ax=b where A is a Matrix.

You wrote,
    alias(eparm=CirclePramUHG);
but the submodule's export is named CircleParmUHG.

2024-06-29_use_alias_in_a_Sub_Package_ac.mw

nb. You don't have to load the package for your aliases to work.
2024-06-29_use_alias_in_a_Sub_Package_acc.mw

 (alias: love it, or leave it...)

Whether some expression merely contains 1 is not equivalent to whether it equals 1. You shouldn't be using something like that as your check.

You could utilize,
    ormap(`=`, [op(S[1])], 1)
or,
    ormap(is, [op(S[1])], 1)
depending on whether you want to recognize (as 1!) things which are mathemetically equal (a.e.) to 1 but not literally in the form of 1.  Eg, (x^2-1)/((x-1)*(x+1)).

Here I use ormap rather than `or`, so that it efficiently bails out as soon as any first instance is detected.

Download 2024-06-27_Q_check_inside_typeset_ac.mw

ps. You had a comment about an alternative you'd tried yet which didn't work ok. In principal that was actually much more sound, ie. a test for actual equivalence to 1. Your instinct to try it was good. The problem there was just that your op syntax was faulty. Instead of the faulty,
   op(S[1][i])
you could have had,
   op(i,S[1])
Then it would have worked as you intended.
   2024-06-27_Q_check_inside_typeset_acc.mw
Note however that it is wrapped in a check that is less efficient as well as slightly over-verbose.

[edit] That code would treat a FAIL (from ormap) as if it were a false. If you're ok with that (and I'd guess that is so) then you don't need a special guard against FAIL in that block. The if would handle a FAIL from ormap like a false. I would guess that you'd prefer not to accept a FAIL like a true here. Also, these don't throw an error.

if ormap(is,[false,false,FAIL,true]) then boo; else blech end if;
             boo

if ormap(is,[false,false,FAIL,false]) then boo; else blech end if;
            blech