@alex_01 Sorry, but you are mistaken about dr and du. They are variables of the linear objective and constraints, just like all the w[i], and as such will not appear by name in the Matrix form.

The Matrix form is simply a shorthand, compressed notation consisting of all the float coefficients of the linear combinations and the bounds. (That's one reason for admitting that form -- only the coefficients are needed, as the general form of the equations and expressions is known.)

If you find yourself trying to write one of the names of the variables anywhere in the Matrix form of an LP problem, then you've gone taken a misstep.

I would agree that the subject of clearly documenting how to get all the various input forms acceptable by Optimization routines is something that could fill out a whole Example worksheet.

Sorry, that I don't have more time now.

@alex_01 Sorry, but you are mistaken about dr and du. They are variables of the linear objective and constraints, just like all the w[i], and as such will not appear by name in the Matrix form.

The Matrix form is simply a shorthand, compressed notation consisting of all the float coefficients of the linear combinations and the bounds. (That's one reason for admitting that form -- only the coefficients are needed, as the general form of the equations and expressions is known.)

If you find yourself trying to write one of the names of the variables anywhere in the Matrix form of an LP problem, then you've gone taken a misstep.

I would agree that the subject of clearly documenting how to get all the various input forms acceptable by Optimization routines is something that could fill out a whole Example worksheet.

Sorry, that I don't have more time now.

@alex_01 The whole efficiency question for Matrix-form vs algebraic-form has to do with the problem setup, not with the actual solving stage.

The Optimization routine converts the algebraic form into Matrix form, before passing it externally to the compiled solver. The external, compiled solver only knows how to work with the Matrix form which is comprised purely of collections of floating-point numbers.

The inefficiency is thus in the forming of the algebraic form, in the storing of the algebraic form entities in Maple (takes more memory than does the Matrix form), and in the decomposing of the algebraic form into the Matrix form.

If you can formulate the problem directly in Matrix form, then you have saved resources. If, however, you form it in algebraic form, only to then manually convert it to Matrix form yourself, then you have saved nothing over what Optimization itself would do internally.

Perhaps your problems will not be huge enough for all this to matter so much?

Good luck, and a Happy New Year to you and yours!

@alex_01 The whole efficiency question for Matrix-form vs algebraic-form has to do with the problem setup, not with the actual solving stage.

The Optimization routine converts the algebraic form into Matrix form, before passing it externally to the compiled solver. The external, compiled solver only knows how to work with the Matrix form which is comprised purely of collections of floating-point numbers.

The inefficiency is thus in the forming of the algebraic form, in the storing of the algebraic form entities in Maple (takes more memory than does the Matrix form), and in the decomposing of the algebraic form into the Matrix form.

If you can formulate the problem directly in Matrix form, then you have saved resources. If, however, you form it in algebraic form, only to then manually convert it to Matrix form yourself, then you have saved nothing over what Optimization itself would do internally.

Perhaps your problems will not be huge enough for all this to matter so much?

Good luck, and a Happy New Year to you and yours!

Since maplemint balks on the module references in `Reg`, you can use this entry point to mint.

That produces the following, most of which indicate serious problems with the coding of SReg:-Reg itself.

mint(SReg:-Reg);

Procedure Reg( Data ) on line 1
  These names were used as global names but were not declared:  Adj, B, Df, 
      MSResidual, Nobs, Nx, Ny, Parameter, Pvalue, R, RegressionSS, 
      ResidualSS, Square, StDevResidual, StError, TotalSS, Tstat, Value, 
      XXXXXXXX, a, b, degreesoffreedom, output, parametervector, 
      residualmeansquare, residualstandarddeviation, residualsumofsquares, 
      rtablesize, solutionmodule, square, standarderrors, x, xx

Unprotected option names such as residualstandarddeviation should get uneval quotes, in case they were assigned values at a higher scope. Names like `a`, etc, used in the formula passed to `Fit`, could be declared local and handled properly -- again, because they could evaluate to something else if assigned already at a higher scope. As coded, these are bugs in the code, and will cause it to fail in otherwise reasonable circumstances.

If code is going to be posted to the Application Center, for other people to use, then it'd be so much better to ensure as much as reasonably possible that it works properly and is robust.

You asked how to find out what global names were in use, so that they might be unassigned before calling code such as this. This is approaching the whole issue backwards. People should be free to use pretty much whatever unprotected global names they choose, and it's the fault of the procedure if it collides.

There are some assumptions about the nature of the data, which should be documented, for this to make better sense.

The programming is more questionable. Apart from from global side-effects on x and xx, there is also an effect on interface(rtablesize) (after one call, even if Standard treats it like an environment variable erratically).

Why does it print u1 and u2 when it could instead just return them both? If returned, then they'd also get printed. If only printed, then nobody gets to access the contents of u1 or u2 (because the proc is only returning NULL).

It'd be less dubious to set a looser evalf/Int tolerance with its epsilon option for `prob`, and to apply evalf(...,6) after the all the numeric computation is complted, than is the current method of doing everything wrapped in that super low Digits setting.

If the code had been run through mint, then other problems (eg, with global name collision) would be discovered.

The bug is only in the pop-up "Matrix Browser", which shows a Vector[row] subtype of rtable as if it were a Vector[column].

Nothing has been shown here to be wrong with the Vector[row]() constructor command, or the Vector[row] rtable object.

You can invoke the Brower to view the object by double left-click, or by right-click to get the "Browse" command from the context-sensitive menu.

More accurate wording would be, "Bug for Vector[row]..." instead of "Bug in Vector[row]..."

Also, the Browser has the same problem for size < 10, if you Browse it with right-click context-menu action (double left-click doesn't invoke the broswer is rtablesize is great enough for the output to show the explicit contents of the Vector).

The problem seems to be only in the orientation of the view.

Changes to the Vector[row] entries seem to work fine and apply to the original Vector[row] object.

Does that Application Center item require MapleSim, or will it provide a solution in only Maple?

Does that Application Center item require MapleSim, or will it provide a solution in only Maple?

Just for fun,

restart:
with(StringTools):

#T:=select(IsPalindrome,Generate(6,"0123456789")):  # slower

T:=[seq(cat(t,Reverse(t)), t in Generate(3,"0123456789"))]:

T:=map(parse,T):
T:=select(t->t>=100000,T): # comment out, to allow leading zeros
T:=sort(T):

G:=infinity:
for i from 2 to nops(T) do
   Y := abs(T[i]-T[i-1]);
   if G>Y then
      G,P := Y,[T[i],T[i-1]];
   end if;
end do:

G,P;

                      11, [200002, 199991]

@JerseyJohn Sure, you could just assign exp(1) to the name e, in the usual way assignments are done. Or you could use `alias`, or `macro`.

But those are not as nice looking as simply using command-completion. Suppose you are typing input in default 2D Math mode. You type in exp and then you hit (on MS-Windows) the keys -. Up comes a popup, and you just hit to accept the top choice. The typed `exp` has become upright roman font e, and its value is exp(1). It is typeset for input just like exp(1) displays by default in output.

Another consideration: if you use command-completion then input that displays as e^x is really exp(x) internally. Because of this fact, input like e^ln(x) will immediately resolve to just x. Hooray. This will not happen if you use `alias`. If you use `alias`(or regular assignment) for name e then the input displayed as e^x will actually be exp(1)^x internally. And input like e^ln(x) will not produce just x, unless you also apply the `simplify` or `combine` command.

Hence I would recommend using command-completion, or the Expression palette entry, to get the roman e as the base of the natural logarithm in 2D Math input.

@JerseyJohn Sure, you could just assign exp(1) to the name e, in the usual way assignments are done. Or you could use `alias`, or `macro`.

But those are not as nice looking as simply using command-completion. Suppose you are typing input in default 2D Math mode. You type in exp and then you hit (on MS-Windows) the keys -. Up comes a popup, and you just hit to accept the top choice. The typed `exp` has become upright roman font e, and its value is exp(1). It is typeset for input just like exp(1) displays by default in output.

Another consideration: if you use command-completion then input that displays as e^x is really exp(x) internally. Because of this fact, input like e^ln(x) will immediately resolve to just x. Hooray. This will not happen if you use `alias`. If you use `alias`(or regular assignment) for name e then the input displayed as e^x will actually be exp(1)^x internally. And input like e^ln(x) will not produce just x, unless you also apply the `simplify` or `combine` command.

Hence I would recommend using command-completion, or the Expression palette entry, to get the roman e as the base of the natural logarithm in 2D Math input.

It's on Maplesoft's FAQ pages, here.

It's number 10 on Robert Israel's list of The Top 10 Maple Errors.

There is a room for Maple to improve, though.

No mention is made in that FAQ entry of the (obvious, to us) fact that 2D Math output displays exp(1) using the single character  in another font (Roman, I guess, unlike regular variable names which display in italic). That's one reason why this problem comes up frequently; it's natural to try and input what you see as output. The font distinction is easy for a new user to miss.

That Maplesoft FAQ entry mentions that exp(1) can be inserted using the appropriate entry from the Expression Palette. But it doesn't point out that this is one way to get the typeset look or in 2D Math input mode. The typical new user and reader of that FAQ is unlikely to realize this.

Another possible improvement for that FAQ entry would be mentioning that command-completion can be used to promote exp(1) to  in situ. (Actually, there is some goofiness to this,with the completion pop-up's left column showing exp_M , whatever that is supposed to mean, corresponding to the  choice.)

Also, the 2D Math input parser/typestting mechanism doesn't automatically promote exp(1) to when it is typed normally. Why can't the GUI autopromote exp( similarly to how it handles sin ? Type in the letters s i n in 2D entry mode and the font switches. If the next letter is u then the font switches back. So why can't the typed characters e x p ( get autopromoted to the typeset with the cursor positioned in the superscript location? Sure, that might be aggresive and controversial, doing away with the need for command-completion. But why not go all the way with the wysiwig aspects?

It's not strictly true to say that Maple interprets e as just another name or variable. For 2D Math, that differs with font.

It's worth being fussy about detail, for a frequently asked question.

It's on Maplesoft's FAQ pages, here.

It's number 10 on Robert Israel's list of The Top 10 Maple Errors.

There is a room for Maple to improve, though.

No mention is made in that FAQ entry of the (obvious, to us) fact that 2D Math output displays exp(1) using the single character  in another font (Roman, I guess, unlike regular variable names which display in italic). That's one reason why this problem comes up frequently; it's natural to try and input what you see as output. The font distinction is easy for a new user to miss.

That Maplesoft FAQ entry mentions that exp(1) can be inserted using the appropriate entry from the Expression Palette. But it doesn't point out that this is one way to get the typeset look or in 2D Math input mode. The typical new user and reader of that FAQ is unlikely to realize this.

Another possible improvement for that FAQ entry would be mentioning that command-completion can be used to promote exp(1) to  in situ. (Actually, there is some goofiness to this,with the completion pop-up's left column showing exp_M , whatever that is supposed to mean, corresponding to the  choice.)

Also, the 2D Math input parser/typestting mechanism doesn't automatically promote exp(1) to when it is typed normally. Why can't the GUI autopromote exp( similarly to how it handles sin ? Type in the letters s i n in 2D entry mode and the font switches. If the next letter is u then the font switches back. So why can't the typed characters e x p ( get autopromoted to the typeset with the cursor positioned in the superscript location? Sure, that might be aggresive and controversial, doing away with the need for command-completion. But why not go all the way with the wysiwig aspects?

It's not strictly true to say that Maple interprets e as just another name or variable. For 2D Math, that differs with font.

It's worth being fussy about detail, for a frequently asked question.

Also, if the escaped local isn't due to a mistake (ie. was intentional..) then you can still test against x^2 by converting to global.

eg, if the expression with x*x is assigned to name `ee`, then you can call

convert(ee,`global`);