jakubi

1369 Reputation

12 Badges

19 years, 338 days

MaplePrimes Activity


These are replies submitted by jakubi

Can labels be generated programatically?

It sounds not hard as they correspond to a simple Text-input field like:

<ec-label id="Label1" caption="etiqueta" enabled="true" visible="true" visiblecharacterwidth="5" pixel-width="300" pixel-height="200" user-size="false" user-width="false"></ec-label> 

in the mw worksheet.

Can labels be generated programatically?

It sounds not hard as they correspond to a simple Text-input field like:

<ec-label id="Label1" caption="etiqueta" enabled="true" visible="true" visiblecharacterwidth="5" pixel-width="300" pixel-height="200" user-size="false" user-width="false"></ec-label> 

in the mw worksheet.

In Maple 11.02 I get thick tickmarks:

plot(cos(x), x=-2*Pi..2*Pi, axis=[tickmarks=[10, color=blue, thickness=3]]);

In Maple 11.02 I get thick tickmarks:

plot(cos(x), x=-2*Pi..2*Pi, axis=[tickmarks=[10, color=blue, thickness=3]]);

No, the problem is the startup code:

with(Units);
with(Units[Standard]);

as `^` is bound to 'Units[Standard][`^`]' and so on. These 'Units' package operators do not seem to work with such matrix name. Remove that startup code, and it will work.

PS: More correctly. A coloring appears in the inverse Matrix subindexed operation.

Namely, converted to 1D math input, it becomes:

Units[Standard][`^`](`#msub(mi("R",mathcolor = "teal"),
mi("x",mathcolor = "teal"))`, Units[Standard][`-`](1));

But the subindexed Matrix definition was without color:

`#msub(mi("R"),mi("x"))` := Matrix(3, 3,...

And this "teal" colored object is different than the the uncolored one (they have different memory addresses). So, the Units[Standard][`^`]/2D parsing may have problems with this issue.

Indeed, removing the color part, the inverse operation works fine, even with 'Units' operators:

simplify(Units[Standard][`^`](`#msub(mi("R"),mi("x"))`, 
Units[Standard][`-`](1)));

 Matrix(3, 3, {(1, 1) = 1, (1, 2) = 0, (1, 3) = 0, (2, 1) = 0,
 (2, 2) = cos(theta), (2, 3) = sin(theta), (3, 1) = 0, (3, 2) = 
 -sin(theta), (3, 3) = cos(theta)}) 

remember when things get weird, go to 1D math input worksheet mode...

Could it be because the code of (toplevel) 'D' is older than 'rtable' objects?

In regards to VC free Vectors, they are confusing for me and do not correspond to what I understand by free vectors.

Could it be because the code of (toplevel) 'D' is older than 'rtable' objects?

In regards to VC free Vectors, they are confusing for me and do not correspond to what I understand by free vectors.

A quick way to do it is selecting from the plot menu: Color > Z (Hue).

A quick way to do it is selecting from the plot menu: Color > Z (Hue).

VectorCalculus:-D does what you mean, I think.

VectorCalculus:-D does what you mean, I think.

Those tickmarks suboptions seem to be ignored. But they do not produce an error message either. Sounds to me as if their implementation was withdrawn or changed, but not their documentation.

Those tickmarks suboptions seem to be ignored. But they do not produce an error message either. Sounds to me as if their implementation was withdrawn or changed, but not their documentation.

May be that the developer could provide some additional information. Or someone with knowledge, patience and time could uncover what is the matter with this 'pdsolve' code.

The error message arises probably here:

showstat(`pdsolve/numeric/par_hyp`,88..91);
`pdsolve/numeric/par_hyp` := proc(PDE_in, INFO::table)
local a1, a2, xtra, t, x, t0, xb, tv, parms, timespec, mintimespec, i, j, k;
       ...
  88   j := add(INFO["depords"][i][3-tv],i = 1 .. nops(INFO["depords"]));
  89   k := add(INFO["eqnords"][i][3-tv],i = 1 .. nops(INFO["eqnords"]));
  90   if j <> k then
  91     error "input system is too far from a 'standard' form (see ?pdsolve,numeric for more detail)"
       elif nops(INFO["IBC",x]) <> j then
         ...
       end if;
       ...
end proc

May be that the developer could provide some additional information. Or someone with knowledge, patience and time could uncover what is the matter with this 'pdsolve' code.

The error message arises probably here:

showstat(`pdsolve/numeric/par_hyp`,88..91);
`pdsolve/numeric/par_hyp` := proc(PDE_in, INFO::table)
local a1, a2, xtra, t, x, t0, xb, tv, parms, timespec, mintimespec, i, j, k;
       ...
  88   j := add(INFO["depords"][i][3-tv],i = 1 .. nops(INFO["depords"]));
  89   k := add(INFO["eqnords"][i][3-tv],i = 1 .. nops(INFO["eqnords"]));
  90   if j <> k then
  91     error "input system is too far from a 'standard' form (see ?pdsolve,numeric for more detail)"
       elif nops(INFO["IBC",x]) <> j then
         ...
       end if;
       ...
end proc
First 42 43 44 45 46 47 48 Last Page 44 of 123