I agree that a key part would be to be able to adjust options quickly.

Sometimes I would like to be able to toggle interface options without cluttering up the worksheet in which I'm working. Often I don't need or want to have the interface control code appear in my original worksheet, as I'm just investigating and I intend to delete such toggled effects before I save. I usually open a new worksheet with a shared kernel, to get this overall effect. But it could be much easier and faster with a menu.

I also find that the Standard GUI's menus for this are too awkward. I don't like to have to go through Tools -> Options and then select the Interface tab. (And several useful things from the interface() command are missing in that tab, anyway.) I'd prefer to be able to add a quick launch "interface" button to a configurable menubar. That's modern technology, however.

I'd write customized context-menus, to get these effects via right-clicking in the worksheet. But I haven't figured out how to get context-menu actions to insert no output.

Other interface options that I'd like ready access to in Standard are rtablesize, warnlevel, and the ones which affect plot devices and options. Even labelling and labelwidth can sometimes serve a purpose in Standatd if adjusted alongside prettyprint. And then there is printlevel. And some kernelopts.

acer

I recommend using this site's Software Change Request form to submit descriptions and explicit examples of these typesetting performance problems.

acer

It's not altogether clear whether solve is not affected by assumptions.

> assume(x>1):
> solve( (1-x^2)>=0 ); # NULL

> restart:
> solve( (1-x^2)>=0 );
                               RealRange(-1, 1)

acer

It's not altogether clear whether solve is not affected by assumptions.

> assume(x>1):
> solve( (1-x^2)>=0 ); # NULL

> restart:
> solve( (1-x^2)>=0 );
                               RealRange(-1, 1)

acer

This below worked for me on Maple 11.

plot(sin(x), x = 0 .. 2*Pi, tickmarks = [[seq(i*Pi/2=i*Pi/2,i=1..4)],default]);

It also seems to work if more tick-points are specified than will fit in the specified range.

plot(sin(x), x = 0 .. 2*Pi, tickmarks = [[seq(i*Pi/2=i*Pi/2,i=-40..40)],default]);

The spacing() way did not work properly in my Maple 11 too. The fractions print as floats.

acer

This below worked for me on Maple 11.

plot(sin(x), x = 0 .. 2*Pi, tickmarks = [[seq(i*Pi/2=i*Pi/2,i=1..4)],default]);

It also seems to work if more tick-points are specified than will fit in the specified range.

plot(sin(x), x = 0 .. 2*Pi, tickmarks = [[seq(i*Pi/2=i*Pi/2,i=-40..40)],default]);

The spacing() way did not work properly in my Maple 11 too. The fractions print as floats.

acer

I used rationalize because I thought that he might be trying to do it part of it "by hand".

Thanks for noticing, about the two-argument arctan.

acer

I used rationalize because I thought that he might be trying to do it part of it "by hand".

Thanks for noticing, about the two-argument arctan.

acer

Do you mean that you want the solving method to not be implemented as a (new) procedure?

Or do you perhaps mean that you want f to be an expression rather than a procedure or operator? In that case, the function applications could be replaced by 2-argument eval calls, or unapply could be used to produce an operator equivalent at the start of the code. Eg, instead of,

> f := x -> cos(Pi+x) -x: # the input

> f(1.1);
                                 -1.553596121

could be,

> f := cos(Pi+x) -x: # the input

> var := indets(f,And(name,Non(constant)));
                                  var := {x}

> if nops(var) <> 1 then error "expecting univariate expression"; end if;

> eval( f, var[1]=1.1 );
                                 -1.553596121

> F := unapply(f, var[1]);
                             F := x -> -cos(x) - x

> F(1.1);
                                 -1.553596121

acer

Do you mean that you want the solving method to not be implemented as a (new) procedure?

Or do you perhaps mean that you want f to be an expression rather than a procedure or operator? In that case, the function applications could be replaced by 2-argument eval calls, or unapply could be used to produce an operator equivalent at the start of the code. Eg, instead of,

> f := x -> cos(Pi+x) -x: # the input

> f(1.1);
                                 -1.553596121

could be,

> f := cos(Pi+x) -x: # the input

> var := indets(f,And(name,Non(constant)));
                                  var := {x}

> if nops(var) <> 1 then error "expecting univariate expression"; end if;

> eval( f, var[1]=1.1 );
                                 -1.553596121

> F := unapply(f, var[1]);
                             F := x -> -cos(x) - x

> F(1.1);
                                 -1.553596121

acer

It's unfortunate that the help query, issued in the Standard GUI,

  ?:-

takes one to the `use` help-page instead of the more appropriate `colondash` help-page.

And, naturally, both those pages should mention each other.

It's also unfortunate that the query ?uses takes one to the `procedure` help-page instead of to its own dedicated help-page (or to an expanded `use` help-page).

acer

It's unfortunate that the help query, issued in the Standard GUI,

  ?:-

takes one to the `use` help-page instead of the more appropriate `colondash` help-page.

And, naturally, both those pages should mention each other.

It's also unfortunate that the query ?uses takes one to the `procedure` help-page instead of to its own dedicated help-page (or to an expanded `use` help-page).

acer

There is a lot more that one can learn. But you don't need to learn it all before you can get going.

You could try the "Introductory Programming Guide". Look here, for some downloads.

acer

There is a lot more that one can learn. But you don't need to learn it all before you can get going.

You could try the "Introductory Programming Guide". Look here, for some downloads.

acer

You assign various values i[m], in a triple-loop where m has positive integer values. (This is the global name i)

The operator phi is defined to return expressions which contain those i[..] values. (This also is the global name i)

When you construct a top-level for..do loop using loop variable i, then running it wipes out those stored values i[m]. (This also is the global name i)

At that point, inside OVLM, calls to phi() are not returning what you expect. They are returning expressions containing things like 1[1], 1[2], etc.

The problem above isn't because `i` and `j` are also names of parameters of procedure OVLM.

If you replace the int() calls inside OVLM by Int(), then you can see it go wrong as follows. Unassign name i by issuing  i:='i': The call OVLM(1,1). Then assign i:=1: Then call OVLM(1,1) again. After that last call to OVLM, you can see how the output differs. In the last call, there are objects like this,

r[1]^( 2*1[1] + 1 )

So here's the deal. When you use a for..do loop, the loop indexing variable is not somehow "local" to only that loop. When you issue such a loop at the top-level, the loop variable is the global name. That's going to collide with any other previous use of that name (in your case, assigned values of i[m]).

If your loop variable (in your problematic loop) were ii instead of i then it would not be clobbering the "unique radial exponents for the 34 basis functions" stored as i[m]. And then the repeated calls to OVLM would work, since phi() would work as you intended. Eg,

for ii to 1 do
 JS := OVLM(1, 1);
end do

acer