21433 Reputation

29 Badges

15 years, 114 days

Social Networks and Content at

MaplePrimes Activity

These are replies submitted by acer

In Maple 2015.2 this command crashes the kernel:


and that seems to be what happens in your example.

That command does not crash in Maple 2016.2 and Maple 2020.1, as far as I can see so far.

At ten characters  sort(<[]>)  is pretty short, but not a record.

@binbagsss  Here are equations that you provided. The first equation you stated in your Question. The rest you provided in one of your posts on stackoverflow. You can easily change them.

eq1 :=  Uo/(sqrt(Go*Ho)) = Fr:
eq2 := (rho*Go*Ho^2)/sigma = W:
eq3 := St = (To*Uo)/Ho:
eq4 := Ca = (mu*Uo)/sigma:
eq5 := mu/sqrt(rho*sigma*Ho) = Oh:

The following deals with mu/To*Ho which is one of your input examples. It is a "one-liner".

eval( mu/To*Ho, [eliminate({eq1,eq2,eq3,eq4},{Go,Ho,To,Uo})][1,1] );

                            Ca sigma

The following deals with Go*Ho/Uo^2 which is your other input example. It is done the same as the example above.

eval( Go*Ho/Uo^2, [eliminate({eq1,eq2,eq3,eq4}, {Go,Ho,To,Uo})][1,1] );

The following adds the 5th equation to the example above, and shows that the answer is not unique.

eval( Go*Ho/Uo^2, [eliminate({eq1,eq2,eq3,eq4,eq5}, {Go,Ho,To,Uo})][1,1] );
                             W Oh 

The non-uniqueness of the answer is because of Maths, not because of Maple. When the input example has more than one answer (ie. more than one dimensionless representation) then only you can resolve the ambiguity. Only you could decide which equations should be used.

@Joel19 I assigned the result from ImportMatrix to the name M, and you have assigned it to name A.

But you didn't adjust other places in the code that used the name M. Those need agree with your earlier choice.

@vv Thank you.

@Carl Love You wrote, "My opinion is that all algebraic equations eq given as input to any Maple program should be preprocessed with (lhs-rhs)(eq)."

As a blanket suggestion even just for user programming, and despite the fact that it might be useful in the context of Rouben's approach to this problem, that doesn't sound like a very good idea.

There are many cases in which an algebraic equation is sensibly and usefully used to represent a substitution/evaluation rule or an identity/equivalence/lookup. The lhs-rhs action would remove that wanted information.

@Kitonum The order of results from RealDomain:-solve is not guaranteed here, so extracting the y-values from Sol individually by position is problematic.

In Maple 2020.1 I get the reverse order using that code, which makes the final Area result negative, ie. an incorrect answer.

simplify(fnormal(int(g[1]-f[1], y=op([2,2],Sol[2])..op([2,2],Sol[1]))),zero);


As I realize that you know, there are lots of ways to extract the min and max values, eg. one possible fix-up is:

ymin,ymax := [min,max](map[2](eval,y,[Sol]))[];
simplify(fnormal(int(g[1]-f[1], y=ymin..ymax)), zero);

@mmcdara You can submit a Software Change Request directly from this forum by using the forms on its SCR page. (The format is more like a Bug Report, but whoever reads it will likely understand if you phrase it as a Feature Request, aka Request For Enhancement.)

I don't quite understand why not to mention up front in the Mapleprimes Question if you need a solution specifically in terms of the Maplets Plotter.

@Joel19 You can add this option, after a comma, into the end of the plot(...) call.

     labels=[b, ""]

where "" is the empty string (ie. two doublequotes).

How should it handle abs(1,x) ?

@Bland3 I don't understand precisely why you are trying to write your own procedures for mimicing axes and tickmarks and tickmark labels.

It would help if you could state clearly what aspect of those things is not supported by the plot,axis and plot,tickmarks options. Specific examples and detailed descriptions of what you have not been able to accomplish using those would be helpful.

There are (of course) some aspects of functionality that are not provided by the current plotting options. But your attached worksheet(s) don't make it clear and explicit which if any of those you are trying to add and provide.

Given how the significant effort it would be to reproduce properly even the existing functionality I think that it would be prudent to first ensure that the functionalities you want are not currently achievable.

For example, the following things can be achieved with the current functionality, although it requires some creativity to come up with the solutions -- the documentation examples are skimpy.
  - all tickmark labels in common representation (scientific/engineering/reflated float format)
  - forced tickmark labels mixed with forced tickmark positions (ie. some in common location, some blank labels at some tickmarks, etc)
  - common font size and color for each axis's tickmark labels (but different per axis)
  - different font size and color for some tickmark labels along a common axis

Could you provide specific examples for most of the pieces of functionality for plotting axes which you have not been able to achieve?

There may be little point is getting it to run, at present, since the current performance of the Intel MKL BLAS gemm and gemv are so good.

The small number of CUDA enabled LinearAlgebra functions (Matrix-Matrix multiply and Matrix-Vector multiply) are so fast that the transfer time to upload/download the data to/from the GPU obscures the computation time.

Having said that, I see a few ideas for the future (although I think I wrote something similar a few years ago...).

1) Get one of the fuller LAPACK compilations (in GPU, of course) to work. The last time I checked there were a couple of candidates. But at that time neither had yet finished doing or optimizing the svd and nonsymmetric eigen-solvers, which have the higher complexity algorithms and longer computation times so that transfer-every-time wouldn't hide the benefits.

2) Make new "foreign DAG" MatrixVector in Maple whose hardware data lives on the card. (And procs to push up, and pull down, such beasts.) Then compound linear-algebra operations could be done on those, with the transfer overhead seen only at front and end of the computation.

3) Write BLAS and LAPACK direct front end packages in Maple. Have these access MKL or CUDA, as chosen. Bonus points for CodeGeneration or Compiler:-Compile of procs that use these.

These are all interesting, but it's unclear that the benefit would be in high enough demand. It might be tricky to justify these over, say, a new fast hardware quad-precision BLAS/LAPACK.

@chrisc Does it improve if you close the left panel (the "palette" pane)?

How about the right panel (the content-menus)?

Do you perhaps mean the Standard Java GUI?

@Carl Love 

You wrote, "It is obvious that the proper evaluation of F(G(e1, e2)) assuming a1, a2 requires that the assumptions be applied before F(G(e1, e2)) is evaluated."  But that aspect that you describe as obvious seems to be crux of what surprised the OP -- ie. the fact that all instances of name `x` within the unevaluated expression are temporarily replaced with an assumed name, prior to any part of F(G(e1,e2)) being evaluated. Hence the replacement with assumed names happens before even G(e1,e2) is computed.

That is the ususal evaluation model of `assuming`. It is (IMO) conveyed by the first sentence in the Desciption of the Help page for that command. The entirety of the first argument is evaluated under the assumptions placed on the names present.

@Kitonum Yes, but regardless of the strength of `solve`, isn't it zero over that wider domain?

I don't see why examination of the domains of subexpressions (radicals, csgn, ln, etc) present in some *particular* representation should always be an adequate and correct methodology. Their individual imaginary contributions may cancel for some x. Just because we don't know how to simplify/manipulate the expression into a representation where it clarifies differently doesnt mean that the expression might not be real-valued on a larger domain.

1 2 3 4 5 6 7 Last Page 1 of 450