@UndergradMaths 

diff(f(x),x) is the standard way to enter a differential quotient in Maple (specifically in  Worksheet mode, red prompt and red typewriter-style input). There is an operator D, which may have a notation closer to your liking. You can look that up in the help facility (?D).

In document mode the input looks closer to standard mathematical notation. You can use the Expressions pallette to enter things like differentials (and then fill in the placeholders).

M.D.

@Kitonum ...but note, your examples only work because the value can be expressed in Maple in an exact way. Try cos(1). The point I am trying to make is that this has nothing to do with radians or degrees. sin and cos >always< work in rad. If the result can be expressed in an exact manner in Maple, they will evaluate. If not, they will not evaluate unless given a float as an argument.

M.D.

Carl is correct. However, as far as I can tell these options only exist for 2-d plots. I recently wanted gridlines for 3-d plots and found that the grid-related options don't work for 3-d plots.

M.D.

You did not mention the OS you run. On Mac OS X I can have several Java versions and pick which ones it uses at least by default (using Applications:Utilities:Java:J2SE :Java preferences.app). On Linux I would suspect the same can be done albeit using a different mechanism. On Windows? No clue.

Mac Dude.

@Carl Love Hmm, maybe I should test my package against Maple 18 (which I have access to but not routinely use). In this particular case it seems what works in 15...17, and it seems to me that there may actually be some improvement to report here; certainly to the uninitiated the use of double quotes is not at all intuitive (although, when the manual calls the "rule" for a type a handler one gets the idea that something may actually get evaluated, hence the occasional need to prevent that).  But then; the whole type facility is a bit arcane, what with structured types and so on (which I actually tried in my case as well, but which got get nowhere fast).

Needless to say I would not know about changes in Maple's kernel, but why not (as long as it is backward compatible)? I have run fairly sizeable worksheets developed with Maple 15...17 against Maple 18 and run into very few issues, mostly connected with plotting and/or packages (like Physics, which is just a newer version in 18).

M.D.

@Carl Love This did the trick! I am slightly puzzled as I thought I tried double uneval quotes before; but maybe I enclosed the argument...

Be that as it may, thanks a lot to you & acer for your help.

FWIW, this appears to work in Maple 15 as well (I am moving back & forth between 15 and 17 depending on the machine I happen to use).

Mac Dude

@acer So here is my problem a little more in context:

I am loading a package "Lattice". In this package I have a ModuleLoad proc that amongst others adds a few types specific to the use of this package:

ModuleLoad:=proc();
  #TypeTools:-AddType(Element,'{record(l,R),record(l,k1,n,R)}');
  TypeTools:-AddType(Element,'record(l,R)');
  TypeTools:-AddType(BeamLine,'record(l,R,BL)');
  #TypeTools:-AddType(ExpandedLine,'Vector(Element)');
  TypeTools:-AddType(Machine,'record(l,R,Title,BL)');
  TypeTools:-AddType(Beam,'record(Particle)');
...

Note that the addition of ExpandedLine is commented out since it does not work.

If I now try to add ExpandedLine in a regular worksheet that uses Lattice; I get this:

restart;with(Lattice); # output not reproduced here
TypeTools:-Exists(Element);
                              true
TypeTools:-Exists(ExpandedLine);
                             false
TypeTools:-AddType(ExpandedLine,'Vector(Element)'); # no output generated
TypeTools:-Exists(ExpandedLine);
Error, (in Vector) dimension parameter is required for this form of initializer

So something is interfering here. It seems that Vector is being evaluated despite the quotes. I get the same problem when I activate the AddType stmt. in ModuleLoad. Note that the type Element works as intended; and I also do not see any problem per se with Vector, which is used in the package in different routines.

Maple 17.02 (64 bit) on Mac OS X 10.6.8.

Any insight?

M.D.

@acer Ok, now I am baffled. As you can imagine I am doing this in a larger context so it is always possible that some secodary effects are happeing; except that the package I want to add this to generally works. Regardless, in my context it does not work; either spewing out error messages during AddType or ignoring the new type and barfing at the type() statement.

I did verify that your example works in my Maple 17 as well (stand-alone at least).

Anyway, I'll double check & get back to you.

Thanks,

M.D.

@Athar Kharal Please show what you get. I ran Carl's example and it works, which is to say Maple can find the integral and IntTutor fires up when asked to (I don't know IntTutor so I haven't tried to actully do anything with it).

M.D.

@taro In the standard GUI it is easy: Select two input lines in an execution group and chose Edit>"Split or Join groups">"Split" (the detailed menu labels may be off but the principle is right, citing from memory here).

You join two groups in the same way: select across a boundary between two execution groups and Join. This can be useful: If you use the ditto operator (%), you really want to use it within one execution group so you do not run the risk of it pointing to the wrong thing if you evaluate lines of a sheet individually.

M.D.

The code snippet you provide has too many undefined names to really figure out what is going on.

You certainly have a missing semicolon at the end of the PMMmmf... statement. But you know that as Maple will have flagged it and refused to run the loop.

The dependency on i is a bit convoluted as it goes through rotorshift. Use print(name); to printout intermediate results to check whether that works right.

You are defining functions within the loop. I suggest you pull that out of the loop for efficiency. Also, it sort-of creates a new function every iteration which could cause some interesting effects. Furthermore you are depending on rotorshift acting like a global and being updated for each  call; not particularly good programming practise. I suggest you make that an argument.

As a general help in debugging loops you can insert print statements (like (print(name);) that will print the result. In large loops this helps. You can also make holding arrays for intermediate results and inspect these in the side panel.

M.D.

@nm Yes, the dual interface of Maple is confusing. However, it is not all bad. As a counter example: I used Maple in a teaching context last summer. My Maple files made up my script. This is where the Document mode came in handy, in fact it was close to an enabling factor. The script, which was live Maple code plus lots of text sections, would have been impossible to look at in worksheet mode. As it is I could even print it, for a textbook-like look.

For getting actual work done you really want to stick to worksheet mode and 1-d input. Note that you can change the input mode with the menu on top-left of the input window. C Maple Input is the setting for 1-d input. Also you can hit the [> button to get a 1-d input prompt. Independent of the mode of the sheet.

M.D.

This is an important question, in parts because we now do much more with systems like Maple than just symbolic derivations. I haven't gotten quite to that stage yet, although I likely will within the foreseeable future.

At this point I believe what you can do is saving things like vectors, matrices and arrays (large data sets with only a few names), to be read-in upon resuming a run. This leaves you with having to recreate variables which hopefully is less of a task. Some problems will not yield to such "factorization", however, so checkpointing a long calculation is something Maple should implement.

M.D.

Whar exactly do you mean by "closing a paragraph"?

The important entity in a Maple worksheet is the execution group. In worksheet mode with 1-d input, it is indicated by the line on the left side of the text. It is always "closed" at the end.

M.D.

@nm The observed behavior stems from ?foo or ?pi doing the same thing as when you type foo or pi into the search field within the help window. It is a case-insensitive search. Now clearly, in Help you want the search to be case-insensitive. One may argue that ?something should only trigger on valid Maple names, that seems worth considering.

My pet peeve? Pi in Maple prints as π (lowercase pi). The unrelated name pi prints as π also. Should'nt "the" pi be called pi in Maple input??

At the end, these things are decisions one had to make during building Maple and one learns to live with as user. There are in reality much more significant issues to address than these.

M. D.