Yes, the elementwise solution using tilde was in the earlier response as the last line of code.

acer

Yes, the elementwise solution using tilde was in the earlier response as the last line of code.

acer

Are you asking for a way to generate the objective and constraints, as equations, in a programmatic way -- given say general formulae for them?

Or are you asking for a way to generate the Matrix form, given an an objective and a varying number of constraints in a varying number of variables?

Or are you asking both such questions, or some other question?

acer

@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