@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].

@mmcdara Your example only works for a coincidental reason: 3 is the largest index. That it's the index of the largest entry isn't being considered. 

But something workable could be made by using the pairs option to indices or entries.

@ Vote up. I wanted to let you know two things for your assuming clause. The first is that it can be shortened to (m, k, a, t) >~ 0. The second is that and is never needed: The commas imply and.

Also, it should be pointed out that evalc assumes that all variables are real, and that's likely why it helps in this case. You probably already know this, but the OP may not.

@sand15 The OP did say that the transform is with respect to x. 

My Answer initially had x and t reversed when showing that diff@fourier was already implemented. But that had no effect on my implementation of fourier@diff.

@Thomas Richard That's not a screenshot. It's the hideous result of using the Maple Math tool in the MaplePrimes editor. It's the one immediately to the right of the upload arrow.

@imparter You posted a Question about 10 days ago asking about solving a finite difference scheme. That's the way to do this.

@Gabriel Barcellos 

Expressions are composed of operands contained in something I'll call a container. In some simple cases, it may not seem like a "container" in the usual sense of the word, but that's the best word that I can come up with for this elementary discussion. There are only a few fundamental types for these containers, and it'll only be the type of the container rather than the container itself that we'll need to consider.

A simple example is a list, for example, L:= [3, x+y, 7]. It's operands are the elements. They command op will return them:

op(L);
               3, x + y, 7 

In most cases, the type of container is returned by op(0, ...):

op(0, L);
                list

The fundamental container types that should be understood for this particular Question thread are `+`, `*`, `^`, and function.

Type `+`:

A:= x + y - z:  op(A);
             x, y, -z
op(0,  A);
              `+`

Expressions whose primary operation is subtraction of 2 or more operands are also considered to be type `+`. Because of algebraic associativity, `+` expressions can have 2 or more operands. 

Type `*`:

P:= -x*y/z:  op(P);
             -1, x, y, 1/z
op(0, P);
             `*`

Note that the unary negation of the expression introduces -1 as a distinct operand. Expressions whose primary operation is division are also type `*` unless their numerator is 1 or their numerator and denominator are both integers. Because of associativity, `*` expressions can have 2 or more operands.

Type function:

F:= Tanh(x, y, z):  #Tanh is just made up for this example.
op(F);
              x, y, z 
op(0, F);
              Tanh

So, operand 0 of a function is the function's name rather than the literal word function.

To be continued...