This question is about a particularity of a widely used function, which looks like a bug at the first glance, but is not (after carefully studying the help page).

The function “add” (a built-in function with special evaluation rules) is intended to be used on sequences. If for any reason (in a procedure for example) a sequence degenerates to a single scalar expression and add is applied to it, the expression can change. This is most likely undesired. In the case below (simplified from a real case that happened to me) a product is transformed into a nonsense sum.

data := 1.*Unit(m);
accu_length := add(data);
data := data, 2.*Unit(m);
accu_length := add(data);
                       data := 1. Unit(m)

                  accu_length := 1. + Unit(m)

                 data := 1. Unit(m), 2. Unit(m)

                   accu_length := 3. Unit(m)

It is quite likely that the above unit error will be noticed. In the following case it is more likely that a change in value remains unnoticed.

data := 2/5;
add(data);
                                   2
                           data := -
                                   5

                               7

I was wondering whether Maple could issue a warning to prevent this use error of add, when certain types of expressions are passed to add.
Alternatively Maple could return the expression unchanged. So far, I have not found a case where it makes sense to apply add to operands of a scalar expression (excluding set, list, array, ... ).

This leads to the question of whether this functionality (add working on a scalar expression) is needed at all. I tried a few and none of them is useful

[a = b, a^b, a@b, a/b, sin(a), int(f(x), x), a[b]];
map(add, %);
        [        b       a                            ]
        [a = b, a , a@b, -, sin(a), int(f(x), x), a[b]]
        [                b                            ]

          [                         1                ]
          [a + b, a + b, a + b, a + -, a, f(x) + x, b]
          [                         b                ]

Anything else which could make sense?

For constants I prefer subscripts over indeces.

I noticed that numbers in subscripts are printed in italic. This is against a common prettyprint convention, where variables are in italic and numbers are in roman. In the example below "1" can easily be misread as "l" (which is probably one of the reasons for this convention)

Is there a way to get numbers printed in roman in subscripts? To force roman print I tried

t__`#mo("1");`
Error, missing operator or `;`

In 2d-Math the convention is respected in the input but not in the outut

With the new GUI:
I get all files (*.*) listed by default.
Other file types to filter are not listed.

Is this the same on other machines?

Can I do something about it?

Only for my understanding:
Why is the concatenation operator not working in this assignment on the righthand side

for i to 5 do
  x_ || i := x_ ||(i-1); 
end do;
                           x_1 := x_0

                           x_2 := x_0

                           x_3 := x_0

                           x_4 := x_0

                           x_5 := x_0

Somehow i in (i-1) equals always 1
Why do I have to use

for i to 5 do      
  x_ || i := cat(x_,i-1);  
end do;  
                           x_1 := x_0

                           x_2 := x_1

                           x_3 := x_2

                           x_4 := x_3

                           x_5 := x_4

In 1D-Math an inert division can be entered as an infix operator using "%/"

The same sequence of chracters does not work the same way in 2D-Math

In 2D-Math I have to use

Is there an infix division operator in 2D-Math?

Is there a helppage describing %arithop and the like?