A minus sign is missing. Inserted, the plot is a smooth horizontal line at 1 as it should. The other plot for 'ln' is indeed stepwise both in Classic and Standard at  the default value of Digits.

A minus sign is missing. Inserted, the plot is a smooth horizontal line at 1 as it should. The other plot for 'ln' is indeed stepwise both in Classic and Standard at  the default value of Digits.

With that single equation you cannot say much about A and B. E.g. solve for A

                                  -Y + B x
                            A = - --------
                                      3
                                     x

Then, for B finite, and Y<>0 you have A ~ Y/x^3 when x close to 0. So that A is unbounded from below and above, etc.

With that single equation you cannot say much about A and B. E.g. solve for A

                                  -Y + B x
                            A = - --------
                                      3
                                     x

Then, for B finite, and Y<>0 you have A ~ Y/x^3 when x close to 0. So that A is unbounded from below and above, etc.

Both forms are equivalent. You could do:

Logic:-BooleanSimplify(`&or`(a,`&and`(a, b)));
                                  a

It might depend on the exact details of what you do like Classic or Standard GUI, 1D or 2D input, Word version, etc, as recent versions of Standard GUI may copy to the clipboard several fields, including text and image ones, and it may depend on what the other application takes on pasting.

I have never had paste problems with text editors.

Just wonder whether the choice of the term "literal" and expressions like "literal name" and "literal subscript" in this context, 2D math input, is good or confusing. A help text search for "literal" finds tens of help pages where "literal" and "literal name" are used in a quite different sense.

Just wonder whether the choice of the term "literal" and expressions like "literal name" and "literal subscript" in this context, 2D math input, is good or confusing. A help text search for "literal" finds tens of help pages where "literal" and "literal name" are used in a quite different sense.

Inserting this same input into Maple 11.02, 12.02 and 13.01 Classic, under Win XP, I get 13.01 output in about 10s while no output is produced from 11.02 and 12.02 after some minutes.

Inserting this same input into Maple 11.02, 12.02 and 13.01 Classic, under Win XP, I get 13.01 output in about 10s while no output is produced from 11.02 and 12.02 after some minutes.

You will get those error messages because you have assigned a set to 'sys':

sys := {diff(f1(x), x, x)-f1(x)+f2(x) = 0, diff(f2(x), x, x)-
f2(x)+f3(x)+b1*(f1(x)-f2(x)) = 0, diff(f4(x), x, x)+
b3*(f3(x)-f4(x)) = 0, diff(f3(x), x, x)-f3(x)+f4(x)+b2*(f2(x)-
f3(x)) = 0};

and then called 'dsolve' this way, enclosing 'sys' in a list:

dsolve([sys]);
Error, (in ODEtools/odsolve) invalid input: 
PDEtools/sdsolve expects its 1st argument, SYS, to be of type 
{set({<>, =, algebraic}), list({<>, =, algebraic})}, but received
...

Either use a set or a list, not both.

You will get those error messages because you have assigned a set to 'sys':

sys := {diff(f1(x), x, x)-f1(x)+f2(x) = 0, diff(f2(x), x, x)-
f2(x)+f3(x)+b1*(f1(x)-f2(x)) = 0, diff(f4(x), x, x)+
b3*(f3(x)-f4(x)) = 0, diff(f3(x), x, x)-f3(x)+f4(x)+b2*(f2(x)-
f3(x)) = 0};

and then called 'dsolve' this way, enclosing 'sys' in a list:

dsolve([sys]);
Error, (in ODEtools/odsolve) invalid input: 
PDEtools/sdsolve expects its 1st argument, SYS, to be of type 
{set({<>, =, algebraic}), list({<>, =, algebraic})}, but received
...

Either use a set or a list, not both.

Some commands do look at  the prefix/postfix of the name. E.g.:

type(A_,PhysicsVectors);
                                  true

I agree that the output NULL is not a user friendly default. You can do:

infolevel[all]:=1:
use RealDomain in solve(sin(x)=cos(x),AllSolutions) end use;

solve:   Warning: solve may be ignoring assumptions on the input variables.
solve:   Warning: no solutions found

Tracing it more deeply with e.g.:

infolevel[all]:=5:
trace(`solve`):
printlevel:=20:

it shows that in:

use RealDomain in solve(sin(x)=cos(x),AllSolutions) end use;

'AllSolutions' is interpreted as another variable name to solve for, and assumed also as real:

...
{--> enter assume, args = x, real, AllSolutions, real
...
{--> enter solve, args = sin(x) = cos(x), AllSolutions
                   Args := [sin(x~) = cos(x~), AllSolutions~]
...

The package 'RealDomain' has its own 'solve' command. I get this error message:

use RealDomain in solve(sin(x)=cos(x),x,AllSolutions) end use;

Error, (in assuming) when calling 'solve'. 
Received: 'invalid input: 
too many and/or wrong type of arguments passed to solve; 
first unused argument is AllSolutions'

tracelast; 

RealDomain:-solve called with arguments: sin(x) = cos(x), x, AllSolutions
 #(RealDomain:-solve,7): sol := :-simplify([`assuming`([solve(args)],['real'])])
 assuming called with arguments: [solve(sin(x) = cos(x),x,AllSolutions)], [real]
 #(`assuming`,147): error `assuming/error_message`(X,cin,eval([lastexception],1))

It sounds like a bug as if 'assuming' is not handling properly the new option 'AllSolutions' in 'solve'.

However, I find confusing the documentation of ?RealDomain in regards to whether this option should be supported. Indeed, the help link in the table of the subsection "List of RealDomain Package Commands" goes to ?solve, instead of ?RealDomain,solve, say.