Frequency can mean cycles/unit-of-time, or revolutions/unit-of-time, or 1/unit-of-tme. The second is a common unit of time.

So, using 2*Pi radians as one cycle or revolution

f1,f2 := 1, 1/3: # frequencies, as cycles/second

plot([sin(f1*t*2*Pi),sin(f2*t*2*Pi)],t=0..3);

The above shows two sin plots. One does 1 cycle (2*Pi radians) for every whole unit of t, and the other does 1/3 cycles. You can interpret a unit of t as being a second, for example. The plots are thus done over 3 seconds. One curve does three full cycles and the other shows just one cycle.

You can use the legend or labels options of plot to illustrate it. For example,

f1,f2 := 1, 1/3: # frequencies, as cycles/second

plot([sin(f1*t*2*Pi),sin(f2*t*2*Pi)],t=0..3,
     labels=[typeset(Unit(s)),cycle],
     legend=[typeset(f1*Unit(Hz)),typeset(f2*Unit(Hz))]);

acer

Remain calm. Please put your seat-back into its upright position. Please extinguish all cigarettes.

Seriously, we may be able to give some help. But you are right, posting your code would help. You can use the green up-arrow in the toolbar at the top of this forum's editor (to upload files and worksheets). Or you can put the code inlined right into a post/response here (toggle to Source, and use the <pre> and </pre> tags say).

For the most part in straight Matlab computations will be done in hardware double- precision. There are ways to get around that in (most of) Maple, but it is not the default. There are also ways to use even higher precision in Maple (by setting its Digits environment variable for example), which is generally not possible in Matlab (without having to recourse to its symbolic toolbox).

Let us know what commands you are using, or post or upload the code itself, and it may be possible to offer more precise suggestions.

You may wish to read the ?Digits, ?evalhf, and ?Matrix help-pages.

acer

I can't tell exactly what you want.

> eqn := a*b*c = sqrt(a+2)*d*e:

> sol := isolate(eqn,a);
                                      2  2      2  2 1/2
                             (d e + (d  e  + 8 b  c )   ) d e
                  sol := a = --------------------------------
                                            2  2
                                         2 b  c

> printf("%a == %a\n",lhs(sol),rhs(sol));
a == 1/2/b^2/c^2*(d*e+(d^2*e^2+8*b^2*c^2)^(1/2))*d*e

> solve(eqn,{a});
              2  2      2  2 1/2
     (d e + (d  e  + 8 b  c )   ) d e
{a = --------------------------------},
                    2  2
                 2 b  c

                     2  2      2  2 1/2
           (-d e + (d  e  + 8 b  c )   ) d e
    {a = - ---------------------------------}
                           2  2
                        2 b  c

acer

In Maple, the quotation mark " is used to delimit strings. The single-left-quote is used to delimit names. (One can convert from one to the other, as shown below.) It's not entirely clear to me which you want.

> N := `i love going to the movies`;
                        N := i love going to the movies

> S1 := convert(N,string);
                      S1 := "i love going to the movies"

> S2 := "i love going to the movies"; # same as S1
                      S2 := "i love going to the movies"

> StringTools:-LengthSplit(S2,2);
 "i ", "lo", "ve", " g", "oi", "ng", " t", "o ", "th", "e ", "mo", "vi", "es"

> map(`[]`@parse,[%]);
   [[i], [lo], [ve], [g], [oi], [ng], [t], [o], [th], [e], [mo], [vi], [es]]

note. LengthSplit also works directly on the name N,

> StringTools:-LengthSplit(N,2);
 "i ", "lo", "ve", " g", "oi", "ng", " t", "o ", "th", "e ", "mo", "vi", "es"

map(`[]`,[StringTools:-LengthSplit(N, 2)]);
[["i "], ["lo"], ["ve"], [" g"], ["oi"], ["ng"], [" t"], ["o "], ["th"],

    ["e "], ["mo"], ["vi"], ["es"]]

Notice this difference in converting from strings to names.

> parse(" g");
                                       g

> lprint(%);
g
> convert(" g",name);
                                       g

> lprint(%);
` g`

> map(t->[convert(t,name)],[StringTools:-LengthSplit(N, 2)]);
[[i ], [lo], [ve], [ g], [oi], [ng], [ t], [o ], [th], [e ], [mo], [vi], [es]]

> lprint(%[4]);
[` g`]

acer

The Optimization routines do floating-point calculation, ie. they are not exact. So the issue is whether the result is "close enough" to zero at the current working precision (or with the tolerance used by the routine in question).

The assume=nonnegative option is a convenient way to supply additional constraints on all the variables. It's equivalent to passing such additional constraints as x[1]>=0, x[2]>=0, etc. So, what you are seeing is a constraint violation.

By default,  Optimization routines work at floating-point double precision. Notice that value for y[2] is close to zero (effectively zero) in the double-precision sense.

> evalhf(DBL_EPSILON);
                                                 -15
                          0.222044604925031308 10

Here are two ways to deal with this issue. The first is to apply `fnormal` to the result. See the ?fnormal help-page for an explanation.

> sol := Optimization[NLPSolve](F1, {constraint1, constraint2 },
>   x[2]=x[1]+0.0001..xmax, y[2]=ymin..y[1]-0.0001,
>   assume=nonnegative, maximize);
sol := [0.938888888888889328,
                                                                -15
    [x[2] = 6.33333333333333393, y[2] = -0.165123990869542325 10   ]]

> fnormal(sol);
               [0.9388888889, [x[2] = 6.333333333, y[2] = -0.]]

> fnormal(sol,14);
           [0.93888888888889, [x[2] = 6.3333333333333, y[2] = -0.]]

> fnormal(sol,15,1e-15);
          [0.938888888888889, [x[2] = 6.33333333333333, y[2] = -0.]]

Alternatively, you can obtain results with an even tighter bound on any violation of the constraints.

> Digits:=17:

> sol := Optimization[NLPSolve](F1, {constraint1, constraint2 },
>   x[2]=x[1]+0.0001..xmax, y[2]=ymin..y[1]-0.0001,
>   assume=nonnegative, maximize, feasibilitytolerance=1e-16);
     sol := [0.93888888888888898, [x[2] = 6.3333333333333334, y[2] = 0.]]

See the ?Optimization,options help-page for more explanation of the feasibilitytolerance option.

The waters are a little muddy here, because the Optimization routines respect both the Digits and UseHardwareFloats environment flags. But hopefully the above is enough.

acer

I'm not sure that I understand what you mean by simultaneously, here.

Can you phrase the multi-objective optimization goal in more explicit terms? Is it the case that you have no satisfactory (single) objective function that unifies both U and u (with  some penalty function applied to each)?

For example, can you state the goal in terms of Pareto optimality? If not, then how should the u and U be compared? (Ie. how does a penalty for one relate to a penatly to the other, quantitatively?)

acer

What's the objection to using piecewise?

> f := proc(x) piecewise(x>=0 and x<1,1,0); end proc:
> int(f(x),x=0..2);
                                       1
 
> int(f,0..2);
                                       1
 
> f := piecewise(x>=0 and x<1,1,0):
> int(f,x=0..2);
                                       1

Consider your original,

> f:=proc(x) if x>=0 and x<1 then 1 else 0 fi; end proc:
> f(x);
Error, (in f) cannot determine if this expression is true or false: 0 <= x and
x < 1

Note that int(f(x),...) or plot(f(x),...) will try to evaluate f(x) right away. That's why you got an error. Because at that moment, x is not assigned and so the comparison produces that error. You could also use the operator form of calling int (or plot), even with your original definition of f.

> int(f,0..2);
                                       1

acer

Actually, you set up an equation Determinant(PL) = 0, and started working with that. So, either deal with lhs() of that equation, or don't set it up as an equation.

EqPl:=simplify(Determinant(PL)=0):
coeffs(lhs(EqPl), [x, y, z]);

altern := simplify(Determinant(PL)):
coeffs(altern, [x, y, z]);

BTW, that subs() call didn't assign to anything. Did you intend it to do so?

acer

The sort of membership that you are considering involves checking whether your candidate Matrix is identical to any member of the set A.

But Matrices are mutable data structures (their entries can change). Two mutable structures are not considered identical just because they happen to have the same entries at one given moment. That's because changing the entry of one of them wouldn't affect the other.

The same happens for direct comparison of Matrices. Consider,

> evalb( Matrix(2,2,[[0,0],[0,0]]) = Matrix(2,2,[[0,0],[0,0]]) );
                                     false
 
> X := Matrix(2,2,[[0,0],[0,0]]):
> Y := Matrix(2,2,[[0,0],[0,0]]): # not same object as X
> evalb( X = Y );
                                     false
 
> X[1,1]:=17:
> Y[1,1];
                                       0
 
> Y := X: # same object as X
> evalb( X = Y );
                                      true

> X[1,1]:=13:
> Y[1,1];
                                       13

For your set A, you could instead compare entries something like this,

> ormap(t->EqualEntries(t,Matrix(2,2,[[0,0],[0,0]])),A);
                                      true
 
> ormap(t->EqualEntries(t,Matrix(2,2,[[1,1],[1,1]])),A);
                                      true

You can also use more sophisticated comparisons. Eg, here is a floating point comparison (allowing for  only 1 ulp difference  when compared using 3 digits)

> ormap(t->verify(t,Matrix(2,2,[[1,1],[1,0.999]]),
>                 'Matrix'('float'(1,digits=3))),A);
                                      true
 
> ormap(t->verify(t,Matrix(2,2,[[1,1],[1,0.998]]),
>                 'Matrix'('float'(1,digits=3))),A);
                                     false

Having introduced verify, one could do your example like this,

> verify(Matrix([[1,1],[1,1]]),A,'member'('Matrix'));
                                     true
 
> verify(Matrix([[1,1],[2,2]]),A,'member'('Matrix'));
                                     false

acer

> L := 0.5*m*diff(x(t),t)^2 - m*g*x(t):

> diff(frontend(diff,[L,diff(x(t),t)]),t) = frontend(diff,[L,x(t)]);
                                  / 2      \
                                  |d       |
                            1.0 m |--- x(t)| = -m g
                                  |  2     |
                                  \dt      /

acer

> T:=convert(x^n*exp(x),FormalPowerSeries,x);
                                 infinity
                                  -----    (k + n)
                                   \      x
                            T :=    )     --------
                                   /         k!
                                  -----
                                  k = 0

 > Z:=value(subs(infinity=5,T));
                              (2 + n)    (3 + n)    (4 + n)    (5 + n)
              n    (1 + n)   x          x          x          x
        Z := x  + x        + -------- + -------- + -------- + --------
                                2          6          24        120
 
> S:=series(eval(Z,n=3),x,8);
                     3    4        5        6         7      8
               S := x  + x  + 1/2 x  + 1/6 x  + 1/24 x  + O(x )
 
> value(subs(n=3,T));
                                    3
                                   x  exp(x)
> series(%,x,8);
                   3    4        5        6         7      8
                  x  + x  + 1/2 x  + 1/6 x  + 1/24 x  + O(x )

> Z:=value(subs(infinity=20,T)):
> MultiSeries:-series(Z,x,5);
                          (2 + n)    (3 + n)    (4 + n)
          n    (1 + n)   x          x          x             (5 + n)
         x  + x        + -------- + -------- + -------- + O(x       )
                            2          6          24

acer

I suspect that this may explain how djc obtained this form,

   evalm((`&*`(`&*`(A, B), 2))*B-`&*`(B, Id));

If the ?evalm help-page, being viewed, has its Examples toggled to 2D Math (using the small button symbol at right-end of iconic menubar), then pasting the relevant line to a Worksheet as 1D Maple input produces the following,

   evalm((`&*`(`&*`(A, B), 2))*B-`&*`(B, Id))

But it the Examples are toggled to 1D Maple input, then it gets copied and pasted into a Worksheet as the following 1D Maple input,

   evalm((A &* B) &* (2*B)-B &* Id);

I also tried pasting as 2D Math, with both levels of Typesetting (Extended and Standard). But who can tell, what is really lying "underneath" displayed 2D Math? I don't like the idea that 2D Math might be WYSINWYH (what you see is not what you have).

acer

By default, units are not combined upon addition.

> restart:
> 3*Unit(microliters)+4*Unit(liters);
                                3 [uL] + 4 [L]

They are combined, if the Units:-Standard package is loaded. The default volume unit for results is meter^3.

> restart:
> with(Units:-Standard):
> 3*Unit(microliters)+4*Unit(liters);
                                 4000003   [ 3]
                                ---------- [m ]
                                1000000000

One can change it, so that microliters is the new default for volume in results.

> restart:
> with(Units:-Standard):
> Units:-UseSystem(Units:-AddSystem(SI,uL));
> 3*Unit(microliters)+4*Unit(liters);
                                 4000003 [uL]

acer

> T := table([ (1,1)=a, (2,2)=s ]);
                     T := table([(1, 1) = a, (2, 2) = s])

> Matrix(2,2,{op(op(eval(T)))});
                                   [a    0]
                                   [      ]
                                   [0    s]

> B[1,2]:=y:
> B[2,1]:=z:
> Matrix(3,3,{op(op(eval(B)))});
                                 [0    y    0]
                                 [           ]
                                 [z    0    0]
                                 [           ]
                                 [0    0    0]

acer

It is the principal third root. There are three cube roots of -1, lying equally spaced around the unit circle in the complex plane.

> evalc( (-1)^(1/3) );
                                            1/2
                               1/2 + 1/2 I 3
 
> convert(%,polar);
                                          Pi
                                polar(1, ----)
                                          3

For a non-principal root,

> surd(-1,3);
                                      -1

There is a short, related, comment in the sqrt help-page (4th bullet item in Description). Compare with exp(1/3 * ln(-1)).

acer