@hirnyk That is implied at the end of the longer Answer above, I think.

But the subtlety is that you are creating y after having loaded RealDomain (or even just its `^` exports). An issue suggested by the longer Answer is whether the following would work for the poster's (or any other) example,

with(RealDomain):

y := ... something complicated

plot(y, k=...);

If the above goes wrong and does not properly construct y then substitution of :-`^` by RealDomain:-`^` into y, after computing y without having loaded all or any part of RealDomain, may work.

@hirnyk That is implied at the end of the longer Answer above, I think.

But the subtlety is that you are creating y after having loaded RealDomain (or even just its `^` exports). An issue suggested by the longer Answer is whether the following would work for the poster's (or any other) example,

with(RealDomain):

y := ... something complicated

plot(y, k=...);

If the above goes wrong and does not properly construct y then substitution of :-`^` by RealDomain:-`^` into y, after computing y without having loaded all or any part of RealDomain, may work.

@Christopher2222 

Maybe you had sprintf in mind? (There is no syntax precisely like you describe, unless one fakes it with a wrapping call to StringTools:-CharacterMap or similar.)

> WhatDay:=proc(Year,Month,Day)
>     StringTools:-ParseTime("%Y-%m-%d",
>                            sprintf("%d-%d-%d",Year,Month,Day)
>                            )['weekDayName'];
> end proc:

> WhatDay(2010,9,9);

                           "Thursday"

@Christopher2222 

Maybe you had sprintf in mind? (There is no syntax precisely like you describe, unless one fakes it with a wrapping call to StringTools:-CharacterMap or similar.)

> WhatDay:=proc(Year,Month,Day)
>     StringTools:-ParseTime("%Y-%m-%d",
>                            sprintf("%d-%d-%d",Year,Month,Day)
>                            )['weekDayName'];
> end proc:

> WhatDay(2010,9,9);

                           "Thursday"

Maybe you had sprintf in mind?

> WhatDay:=proc(Year,Month,Day)
>     StringTools:-ParseTime("%Y-%m-%d",
>                            sprintf("%d-%d-%d",Year,Month,Day)
>                            )['weekDayName'];
> end proc:

> WhatDay(2010,9,9);

                           "Thursday"

acer

@Joe Riel 

When I first saw this topic the first thing that occurred to me was to redefine `assuming` in the equality case. But I discounted it since I was convinced that it would break some existing functionality. As we know, currently 'assuming' places temporary assumptions by replacing by local names with assumptions on them. So then 'is' works, but there is no evaluated substitution (and evalb checks don't ensue, and all kinds of other stuff doesn't come about, etc).

I suspect that there is some class of problem which would behave significantly differently if actual temporary assignment were done instead of merely temporary assumptions, when using such a new `assuming` in the equality case. But alas I have no significant example at hand of "breakage" -- just a gut feeling. ;) So one question is: would such examples (of now differing functioning) always be a good enhancement to `assuming`? Or could there be some undesirable breakage in some (rare?) current usage? Sure, this sounds like an all round improvement, but what about code that relies on the current behaviour? This is mostly why I considered that `using` may be a better choice of infix operator for such new functionality, instead of highjacking `assuming`.

And, of course, highjacking is quite the wrong term. Maybe it's a great fit.

It's a neat piece of syntactic sugar.

But perhaps `assigning` is not the best choice of word, as it doesn't hang as nicely as it might as an English statement. How about `using` instead? Eg,

plot(a*sin(x),x=0..b) &using a=-2,b=7;

I note that what you are proposing seems to function like the following, which already works and relies on the word  `use`.

use a=-2,b=7 in plot(a*sin(x),x=0..b); end use;

It would be nicer with (both 1D and 2D) parser support, to accept the infix operator without its being prefixed by `&`. And, as you mentioned if it had a high enough precedence to work even without round-bracket grouping of the substitution terms. Ie.

plot(a*sin(x),x=0..b) using a=-2,b=7;

which seems quite natural.

acer

It seems to work as expected in the Classic GUI of Maple 14.

It seems to work as expected in the Classic GUI of Maple 14.

Thanks for comments. But I should mention that I knew full well what caused it; and that cause is not so interesting as the fact that the slowdown is very severe. It's a huge amount of overhead to impose (unnecessarily) on the inexperienced user in the default environment. Most users will not realize that their code has this performance penalty.

Do not for a moment forget that what is happening is not a initial parsing slowdown, but an ongoing computational slowdown. And that is far more remarkable as an effect of typesetting merely of the code and not of the output. And it is non-negligible -- each application of that dot-lookalike takes as much time as a 2x2 Matrix multiplication!

Working around the problem by using prefix operators is not the answer for the majority of users. The experienced user will likely have no trouble finding that or other deft workarounds. But the nonexpert user, who is most susceptible to whether or not the default environment is effective and naturally efficient, will likely not even realize that there is any avoidable performance issue. For the majority of users the solution to this issue is to not use 2D Math input mode for writing procedures.

acer

It was really unclear (to me) whether the OP just wanted to easily create a 3x2 Matrix from a list and have the scanning be done by column, or whether the goal was to produce something specifically with C order.

There seemed to be the possibility that she only really wanted the scanning of the flat listdata by columns. (Doug seems to have inferred that, and ignored what would then be the C_order red-herring). In that case, the underlying "order" that Maple is using to store the data internally is irrelevant, and the OP should most certainly not be trying to get cheap transposition just by flipping the order. It seemed as if the OP might not realize that the orcer=C_order refers to the internal storage in memory and not how the data appears and gets printed.

The other possibility is that the OP wanted not only the data in A to be injected (scanned)  into a Matrix by columns, but that she also very specifically wanted C_order storage underneath. (Who knows, maybe the OP wanted to use ImageTools instead of LinearAlgebra and failed to clarify it).

It is confusing that the Matrix constructor reads a flat list as a row-scan, and never as a column-scan unless the list is split. I mean it seems almost a bug that this does not work,

A:=[$1..6]:
Matrix(3,2,A,scan=columns);

while this does work,

A:=[$1..6]:
Matrix(3,2,[ListTools:-LengthSplit(A,3)],scan=columns);

Fortunately, the answer that I gave (and I see since submission that Preben's is essentially the same) does not get garbled if one also slaps on an order=C_order option. So hopefully it works whatever the OP's actual goal was.

In case anyone cares, here's a tip. Do not try and transpose a Matrix by just flipping the order, even for square Matrices. It may print like what you want, but internally it is not, and it won't always get treated as you expect by LinearAlgebra.

M:=Matrix([[1.0,2.0],[3.0,4.0]],datatype=float[8]);
rtable_options(M,order=C_order); # acts inplace on M
M;

And don't get beguiled into expecting that inplace 'order' flipping will "transpose" as neatly for nonsquare Matrices, just because it seems to work for square Matrices..

BTW, ArrayTools has lots of nifty exports for manipulation. I was able to cook up another three ways to get the effect that Erik showed, using mixes of DataTranspose and Reshape. But I advise using some of those only if one understands the storage vs display distinction.

acer

It was really unclear (to me) whether the OP just wanted to easily create a 3x2 Matrix from a list and have the scanning be done by column, or whether the goal was to produce something specifically with C order.

There seemed to be the possibility that she only really wanted the scanning of the flat listdata by columns. (Doug seems to have inferred that, and ignored what would then be the C_order red-herring). In that case, the underlying "order" that Maple is using to store the data internally is irrelevant, and the OP should most certainly not be trying to get cheap transposition just by flipping the order. It seemed as if the OP might not realize that the orcer=C_order refers to the internal storage in memory and not how the data appears and gets printed.

The other possibility is that the OP wanted not only the data in A to be injected (scanned)  into a Matrix by columns, but that she also very specifically wanted C_order storage underneath. (Who knows, maybe the OP wanted to use ImageTools instead of LinearAlgebra and failed to clarify it).

It is confusing that the Matrix constructor reads a flat list as a row-scan, and never as a column-scan unless the list is split. I mean it seems almost a bug that this does not work,

A:=[$1..6]:
Matrix(3,2,A,scan=columns);

while this does work,

A:=[$1..6]:
Matrix(3,2,[ListTools:-LengthSplit(A,3)],scan=columns);

Fortunately, the answer that I gave (and I see since submission that Preben's is essentially the same) does not get garbled if one also slaps on an order=C_order option. So hopefully it works whatever the OP's actual goal was.

In case anyone cares, here's a tip. Do not try and transpose a Matrix by just flipping the order, even for square Matrices. It may print like what you want, but internally it is not, and it won't always get treated as you expect by LinearAlgebra.

M:=Matrix([[1.0,2.0],[3.0,4.0]],datatype=float[8]);
rtable_options(M,order=C_order); # acts inplace on M
M;

And don't get beguiled into expecting that inplace 'order' flipping will "transpose" as neatly for nonsquare Matrices, just because it seems to work for square Matrices..

BTW, ArrayTools has lots of nifty exports for manipulation. I was able to cook up another three ways to get the effect that Erik showed, using mixes of DataTranspose and Reshape. But I advise using some of those only if one understands the storage vs display distinction.

acer

If you look carefully enough at the results resturned by `solve` in both my and John's earlier answers you should be able to see that they do in fact contain such formulae. That is, they contain answers of the form a=..., b=... in terms of X.

But the right-hand-sides of those answers like {a=..,b=...} in terms of X are implicit RootOfs, and not explicit arithmetic formulae in terms of radicals.

You may not like that implicit RootOf form. But as I showed it is useful. Using evalf or fsolve following substitution of X by a float value (as I showed using evalf), all the roots for any given numeric X can be obtained. Hence, you can much more easily and reliably obtain all the roots of those RootOfs involving simple polynomials in X (for any given numeric X) than you can obtain roots of the system of equations using fsolve (for any given numeric X).

The extra RootFinding:-Parametric bit I added in my worksheet, before the `solve` stuff, was to show how many roots (ie. distinct sets of values for a,b,c,d) there are for separate ranges of real-valued parameter  X.

acer

Something has gone wrong with the last two paragraphs of the original post.

At some earlier date, those two paragraphs likely mentioned setting values for kernelopts(prettyprint). But the text's meaning is now slightly garbled, as if instances of that term had disappeared from the text.

For those wondering, labelling can be turned enabled in the Standard GUI by first setting the value of the `prettyprint` interface setting to either 1 or 2. For example, by issuing,

interface(prettyprint=1):

Now, enabled labeling doesn't usually produce as nice results in Standard. Oh, sure, it allows results to be neatly displayed, whereas without it those results would be practically unviewable. But enabling it also seems to wreck proper breaking of other, non-labeled terms in long lines. And so huge, long lines can appear, sometimes in displayed nonscalar objects' output. And, as John mentioned, the mechanism tends to choose common subexpressions for labeling which are awkwardly too short. Presumably that is why labeling is not enabled by default in Standard: it works too poorly.

But labeling should be an important aspect of functionality in any good CAS's user interface, and it really ought to be properly ported from commandline/Classic to Standard. After all, the Standard GUI was introduced seven years and six major releases ago.

Unfortunately, most Standard users don't realize what great stuff they are missing out on... because they've never seen the alternative. There are lots of simple symbolic solving examples where the unlabeled output either exceeds the permitted display length at the default settings or is too long to be sensibly legible.

acer

Thanks, John. I had also considered using `eliminate`.

But I figured that the OP might be interested in knowing how many solutions lay in the various regions for X along the real line.

As a wise man once told me: people asking (vague) questions about parametric systems are almost always going to be disappointed by answers based upon guesses as to what they really want.

Hey! You and your fancy commandline/Classic subexpression labeling. You made my Windows Standard GUI "go away" with your semi-colon. ;)

> sol:=eliminate({a*b^2-b+c-d-3, a^3*b^2-b+c-d^3+4, 
>      a^4+b^3-b^2+c-d+2, 2*a*b^2-b+c-d-1-X}, {a,b,c,d}):

> sol2:= SolveTools:-PolynomialSystem( {a*b^2-b+c-d-3, a^3*b^2-b+c-d^3+4, 
>    a^4+b^3-b^2+c-d+2, 2*a*b^2-b+c-d-1-X}, {a,b,c,d}, domain=parametric):

> length(sol), length(sol2);
                        5183500, 1398546

I suppose that I'd have to read the SolveTools help-page to figure out how to pick apart the essentially unviewable answer in the Standard GUI, and substitute in values for X, etc. It's ridiculous that the result sol2 can be viewed ok -- without the Standard GUI turning to sludge and finally printing something near unreadable -- but only after issuing something like,

> interface(prettyprint=1);

acer