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.

@Alejandro Jakubi I have, more-or-less, described the situation as I see it. I can do my share of submitting bug reports, suggesting improvements etc., but ultimately I cannot change a company's behaviour (and/or their revenue model) other than by stopping to use their product.

But none of these rants liberate me, or anyone else, from due diligence and accepting my responsibility in verifying results I get.

M.D.

@dharr Well, N is infinity for each term and can in fact be factored out trivially.

The problem is more likely that Maple does not know what limit(sigma(n),n=infinity) is, and it returns it unevaluated.

You can get around the eval problem by replacing sum with add. But add cannot be taken to the limit N=infinity.

M.D.

@Alejandro Jakubi Well, even on re-reading it I do not see my reply as making any suggestion as to whether the op's request made sense or not. With the info provided, how could I?

In my work environment (and many others' also), "support" usually boils down to money, unless stated otherwise. Since the op appears to work in an academic environment and is looking for support for a student, the question what level of support was asked for (implying monetary) seems still a reasonable one to ask. Certainly other forms are conceivable, but would need to be outlined with a few more specifics.

Thinking more about it, I'd probably start by writing down a rough outline of what the student's project is supposed to achieve and what kind of upport is really needed. Also, and importantly, one would want to make the case where Maplesoft would gain from such support whatever kind it is. Would a case study be of interest to Maplesoft? Would this project potentially lead to new packages not extant right now (which, if general enough, I would consider a stronger case). or?? And we should not fool ourselves, even if this would be more like a kind-of cooperative programming project or whatever, the company will evaluate the associated costs and will need to ask itself what the return, real and potential, will be.

I still suggest that the op needs to talk to someone within Maplesoft itself. This forum can be a conduit (it was for me when I was planning my accelerator physics course), but how is he going to find out what would make this interesting to Maplesoft and what their conditions would be? I do think the fact that no one from Maplesoft replied indicates that the original question was asked maybe somewhat too broadly and with too little detail. We know a good number of Maplesoft people read this forum, and I am slightly disappointed that no one at least was willing to make some helpful remarks to the op.

Mac Dude.