@Thomas Richard Yes, and I don't see how the example can work in Maple 16 unless one uses Diff instead of diff (in which case it works in Maple 18 too).

Looking at the second line of output in Kitonum's comment shows a gray d/dx which means inert Diff, so I don't see how that 1D input shown with lowercase diff could produce that shown 2D output with the inert d/dx.

@Markiyan Hirnyk That's right. The given penalty is zero over a region. That's why I bothered to mention that something might be missing, which might lead to that point suggested by the Asker (or another point along that edge).

You're just repeating (badly) what I already mentioned.

@Markiyan Hirnyk Yes, that was reasons I showed that "FWIW" plot! That is, if we disregard the `penalty` in the Question and instead focus of the multiobjective {f1,f2} and look at their optimizing directions (it's all linear) then we could expect that some answer should be tight up againt that very constraint.

In fact I bothered to point it out explicitly in my first response (I figured that the readership could recognize the constraint divided by 3). I had it (quoting as, 

# Your suggested value also lies on the edge of that region.
eval( x2<=-2/3*x1+2, [x1 = 1.551123, x2 = 0.965918] );
                           0.965918 <= 0.965918000

The interior point I referred to is the one that `Minimize` returned, for the originally posted penalty. That's the point I consider dubious, not the other two. Just read more carefully the paragraph in my Answer that appears right before the red code.

I coded for the given penalty... because that was what was asked. But the penalty itself seems off. I bothered to say all this before, but I guess that you decide to not notice.

@Markiyan Hirnyk Well, it's not very complicated, as an example. {g1<=0,g2<=0,g3<=0} define the triangle as feasible region. The LP problem of minimizing only f1 or only f2 just lead to solutions at the expected corners. Nothing surprising. And the point returned for minimizing the posted `penalty` isn't even on the boundary, while both f2 and f2 are optimized in directions as shown in my "FWIW" plot. So clearly the interior point "solution" is not good. What I wonder is whether the penalty is not correctly constructed, or some other aspect or demand not respected. The paper seems to claim their penalty will produce something which is a pareto minimum w.r.t. {f1,f2}, but that does not seem true of that interior point.

I thought it was clear that the interior point was not right, and that something related to the paper had to be cleared up. That's why I posted it.

@Markiyan Hirnyk That was obvious, I thought. Note that the result suggested by the Asker, and the one given by you and ascribed to DirectSearch, lie on the triangular region which minimizes the objective (penalty) as given.

The question originally asked has minimal value of zero as a region. Is it not so, for the question originally posed?

I just finished editing an additional paragraphs of thoughts on it, while you were responding.

FWIW,

plots:-display(
  plots:-inequal(sol,x1=-1..4,x2=-1..3,color=blue),
  plots:-pointplot([[1.551123, 0.965918]],symbol=solidcircle,
                     symbolsize=15,color=red),
  plots:-pointplot([[1.17067, 1.21955]],symbol=solidcircle,
                     symbolsize=15,color=green),
  plots:-pointplot([eval([x1,x2],ans[2])],symbol=solidcircle,
                     symbolsize=15,color=black),
  plottools:-arrow([0, 0], [3, 3/2], .05, .1, .1, color=green),
  plottools:-arrow([0, 0], [1, 4], .05, .1, .1, color=green),
  gridlines=false);

@janhardo I am not aware of any way to lock a document block.

How about either uploading a Document in which there is a plot you don't understand, or supplying a URL that points at one? Youc could do either of those in a followup Comment in this thread on Mapleprimes. Then we could try and figure out your issue.

By the way, plots can also be copied and pasted in a Document or Worksheet. It is possible to paste in a (previously and elsewhere generated) plot and have no source present that would reproduce it in the sheet.

Did you intend assignment with

csvfile := Matrix(30,7);

rather than your

csvfile = Matrix(30,7);

acer

@oldstudent While it isn't specifically a Mapleprimes thing, the Maple Portal has material designed for new Maple users.

Note that the Portal is quite heavy on Document mode, 2D Math input, and (mouse driven) "clickable math", while some users discover a marked preference for Worksheet mode, 1D notation input, and programmatic approaches.

Assignment is performed using := and not by using = which just forms an equation. So your code is not actually assigning to the names a, b, and c.

acer

@ber9erud Each time you invoke `assume(p,real)` you affect how Maple interprets your subsequent references to `p`. And the earlier instances of `p` assigned to various expressions will be different from the latter ones. The problem would also occur if you made that invocation at the top-level (not in a procedure) multiple times within the loop. The issue is with the repetition of the call, rather than whether it is done inside a procedure call.

@Markiyan Hirnyk Does this mean that you're not going to answer my question about how you got that output in your first comment to my Answer, with the display as calls to `%+`?

Anyway, it's not clear what your "that" refers to. Do you mean the original question, or something to do with ``() specifically, or some typeset display-only mechanism for Maple 11, or...?

The following produces the same results, and displays them the same, in the Std GUIs of both Maple 11.02 and Maple 18.01. It produces a display with the real and imaginary parts separated as requested, but without extra bracketing in the 2D Math output. And the result is still subject to further computation.

restart:

c := a+I*b:

H:=proc(ee)
 (evalc(Re(ee)))+I*(evalc(Im(ee)));
end proc:

`print/%H`:= proc(ee)
     eval( 'Typesetting:-Typeset'(evalc(Re(ee)))
           + 'Typesetting:-Typeset'(evalc(Im(ee)))*I );
end proc:

For the given example one can evaluate at a point either before or after applying `value`,

`%H`( c^2 );

eval( value(%), [a=1,b=2] );

abs( % );

`%H`( c^2 );

eval( %, [a=1,b=2] );

abs( value(%) );

And now taking abs of the symbolic quantity,

`%H`( c^2 );

abs( value(%) ) assuming real;

`%H`( c^2 );

value( abs( % ) ) assuming real;

There are several ways to approach this topic. I see some different disadvantages to both the ``() and the InertForm approaches. I more often find that I want output with which I can continue to compute, but alongside customized prettyprinting. Somewhat similar kinds have questions have come up several times before.

Can you supply a definition of P_Chain, so that we could run the whole sheet?

Why are you using deprecated lowercase `array` instead of capitalized `Array`?

acer

@Markiyan Hirnyk I did mention that aspect in my comment, but as it may not have been crystal clear enough I will edit. Indeed I agreed that it is an important distinction.

By the way, your first comment in reply to my Answer shows output (as images) that does not conform to what I see in the Std GUI when using InertForm:-Display. Your output images show function calls to `%+`, perhaps as 2D Math. Is that an unfortunate consequence of inlining it on this site? However in your second comment your inlined image does show a displayed result from InertForm:-Display that typesets as I usually see it. Did you paste in, or do something else differently, the second time?

@Markiyan Hirnyk The two approaches certainly have different usages, and different advantages and disadvantages. No doubt about it. Neither is perfect.

Using ``() one has to live with the extra parentheses which look articificial, or else go to more effort with special `print/` mechanisms, or deal with italic vs upright fonts, etc. And while it's easy to use `expand` to remove instances of ``(), it's a pain if you want to use `expand` in more usual ways and leave the ``() untouched, etc. Whenever I use this mechanism I find it wanting: it's too fragile or finicky in the presence of multiple `expand` calls, and the bracketing is unattractive.

It should be no surprise that the InertForm package deals with displaying forms that are, umm, mostly inert. So indeed it is a disadvantage that the displayed result is just that -- display rather than output for further direct computation. Indeed this introduces an unnatural break, since one cannot simply use `%` in the usual way, following a call to Display. Having said that, I would accomplish substitutions as you attempted before wrapping with `Display`. Eg,

restart:
c:=a+b*I:
expr:=c^2:
U := `%+`(evalc(Re(expr)),evalc(I*Im(expr))):
with(InertForm):

Display( eval(U,[a=1,b=2]) );
Display( eval(U,[a=1,b=2]), inert=false );

eval(``(Re(c^2))+I*``(Im(c^2)), [a=1,b=2]);

There's a certain ad hoc lack of grace to all these approaches, I would say. Fine-grained and powerful printing control and the continued ability to manipulate expressions in all usual ways -- that'd be something to write home about.

@Alejandro Jakubi I made no claim that Maple has it perfect, nor that there is some objective perfection. I find the notion that there is a single way to do it "properly" to be flawed. You are being disingenuous by stating that I claimed that Maple's default was the right way. I claimed no such thing.

It's not even clear whether the OP had recognized that the bottom of the original plot corresponded to y=2 rather than to y=0.