@Hahn Hahn The strange derivative output that you showed is definitely caused by the absence of a multiplication sign between (c-x) and (q-e).

@C_R The only way to remove points is for the person who gave the points to reclick the same icon before the item is deleted. After the item is deleted, points can't be changed.

@Preben Alsholm I understood your point already, and, indeed, I almost posted a similiar Question, so I'm glad that you did. I think it would be good to let it stand for a few days so that others may understand also. You can delete it when you feel it's appropriate to do so.

Any Moderator can delete a thread, but only you can deselect Best Answer to remove the 7 points.

@Christian Wolinski I also disagree, strongly, with your reasoning. Some reasons:

• subsop is a builtin (i.e. kernel) command so it can postpone automatic simplification until it exits.
• subs is capable of doing simultaneous substitutions, as shown in my Answer.
• Regardless of who wrote the subsop help page, it's clear to me that the designed intention was simultaneous substitution. Even if there were an external help-page writer, throwing in the word "simultaneous" seems an unlikely mistake.
• You wrote, "a new expression with 2 elements is formed: a*(rest of expression). There is no operand 3 and 4." 
  If (rest of expression) is type `*`, as it is in this case, I don't think it'd be considered a single operand separated from a. (And certainly that's not possible if automatic simplification is happening between substitutions (which may be happening unintentionally, due to a bug).)

So it seems that your reasoning depends on both the presence and absence of automatic simplification happening between the individual substitutions. 

@srwarner I don't know what you're talking about in your latest Reply. There is no contradiction in the first two assume commands above.

@rzarouf acer used eps = 0.00001; you used eps = 0.1. That makes his pseudospectral regions much smaller than yours. Essentially, they're only visible as the eigenvalue itself.

@srwarner Suppose that x = 0 and y = 0. Do you agree that in that case, your three assumptions are true: 0 <= 0, -5*0 <= 0, -5*0 <= 0? Do you agree that the final inequality, -5*0 < -5*0, is false? Then there's no bug.

@srwarner The results shown in your most-recent Reply are mathematically correct. In all cases shown, the 2nd and 3rd assumptions change nothing. Make sure that you do restart before each test to clear old assumptions.

To convince yourself that these results are correct, assign numeric values to x and y such that the assumptions are true.

@srwarner I get this:

restart:
assume(x<=y, 0<=x, 0<=y);
is(-5*x <= -5*y);
                             false
is(-5*(x <= y));
                              true

@srwarner The distribution of the -5 happens first, as you expect. The expression thus becomes -5*y <= -5*x. Under the assumption x <= y, that statement is definitely true.

I don't see how this Question has anything to do with associativity. Did you mean distributivity?

@nm Multiplying an inequality by a negative number reverses the direction of the inequality. That math is correct! There is no bug here.

@awass You wrote:

• When the question of equality of two vectors refers to their storage locations rather than to their values that is VERY far from the obvious mathematical meaning.

The issue is much more subtle than that (subtle referring to your original title). The assessment of equality by the usual `=` operator is---in almost all cases (not just vectors, matrices, etc.) except possibly for objects that overload the `=` operator---determined by storage location. The crux of the matter is, as astutely pointed out by @igor.v.proskurin , whether the data structures being compared are mutable or immutable. Part of the kernel's automatic simplification process for newly created immutable structures is to check whether the structure already exists in the session. If it already exists, then the newly created one simply becomes a pointer to the already-existing one. Thus, immmutable structures that are equal necessarily have the same storage location.

@mmcdara I'll look at your code in detail in about 12 hours. Indeed, I think it's an interesting application.

Regarding op(op(...)): The anomaly that you obtained is precisely one of the two reasons why I said "to work in the most generality, op(op(T)) should be changed to op(2, eval(T))." It's merely a coincidence that the inner eval can sometimes be op; albeit, it's a coincidence that's more likely than the others mentioned in this thread.

@mmcdara You wrote:

• I don't see here any advantage in using 'pairs' instead of op(op(T)).

Yes, I think that they're the same, and, indeed, I think I'll use it. But, to work in the most generality, op(op(T)) should be changed to op(2, eval(T)).
 

• Maybe this can be made simpler?

  max_index = lhs(sort([indices(T,'pairs')], key=(x -> rhs(x)))[-1]);

Yes: In addition to the change to op(2, eval(T)), you can change (x -> rhs(x)) to rhs.

 

• T := table([ 1=23, 2=36, 3=14 ]);:
  max_index = sort([entries(T)], output=permutation)[-1]

That one also only works by coincidence. In this case, the coincidence is that the table's indices are the same as the indices of its list of pairs.

• # You can use sort to find the largest index corresponding to a given order
  ind := indices(T, nolist);
                           [1, 3], [3, 2]
  max_index = sort([ind], key=(x -> x[2]))[-1];
                          max_index = [3, 2]

Your comment in this box is true but irrelevant: The only order that matters is 
key= (x-> T[x]).

You must've accidentally changed something while posting. The result is 
max_index = [1, 3].