I copy-pasted your statements above into Maple 15 and I am getting the expected plots. The first one is from -10..10 (Maple-picked default); the second one is from -1..1 as expected. Will try Maple 17 later.

Are you sure there isn't something in your code that is not in your post? Or that somehow plot got redefined? You can test for that by copy-pasting the line into a new sheet.

M.D.

Edited: added question about redefined plot function.

Here is what I get on Maple 15 in the Standard interface:

restart;A := <a,b,c>;

a := 1:  b := 2: c := 3:
A;

B:=convert(A, list);

A;

B;

seq(A[i],i=1..3);

The output from the seq command as well as the result for B indicate that in fact A has been set... weird.

Exporting this as Maple Input and reading it into CLI Maple (same installation) I get this:

> A := <a,b,c>;
                                             [a]
                                             [ ]
                                        A := [b]
                                             [ ]
                                             [c]

> a := 1:  b := 2: c := 3:
> A;
                                          [1]
                                          [ ]
                                          [2]
                                          [ ]
                                          [3]

> B:=convert(A, list);
                                     B := [a, b, c]

> A;
                                          [1]
                                          [ ]
                                          [2]
                                          [ ]
                                          [3]

> B;
                                       [1, 2, 3]

> seq(A[i],i=1..3);
                                        1, 2, 3

The output from the convert function is a bit weird, otherwise this is as I would have expected. Note that convert produces unexpected output in both cases (GUI and CLI).

Can't be too cautious, can't we, when using computer-generated results.

Mac Dude.

What about

M:=ArrayTools:-RandomArray(1000,1000,distribution=normal);

?

On my machine (PowerMac G5 running Maple 15; both ancient by modern standards) this is practically instant.

It seems to be preferable to just about any of the other methods mentioned, except that you get to scale the numbers yourself to the range you want; and you get to figure out what range they cover to begin with as the docs don't actually say that.

Mac Dude

(I did this before Carl's and Markiyan's answers, so I might as well post it)

How about this:

restart;
with(geom3d):
with(plots):
TruncatedIcosahedron(football,point(C,(0,0,0)),1):

PlotFootball:=proc(tr::float)
    
    local i::integer;
    display(seq(polygonplot3d(Matrix(faces(football)[i]),axes=none,scaling=constrained,transparency=tr),i=1..32)):
    
end proc:

PlotFootball(0.00);

The whole loop can be combined in the seq. Note that seq in general will be faster than a do loop.

M. D.

I have no clue what an "abecedarian" is, but assuming it is not a fancy word for "analphabet", I suggest some reading material:

A book I found most helpful was "Maple: An Introduction and Reference" by Michael Kofler. It is dated, but what is in there is mostly still valid and it goes beyond just rehashing the company documentation. And you can get it for pennies from Amazon. It will help you starting from zero knowledge.

The second one I like is the "Maple Programming Guide" available in pdf from MapleSoft. This is useful beyond programming as a number of concepts important even for interactive use are discussed. It starts roughly where Kofler's book ends.

There are also introductory guides from Maplesoft which I have mostly skipped in favor of experimenting. That does not mean I don't consider them good, but rather that my style of learning is different.

Edgardo Cheb-Terrab has written a brief introduction I also like (it came too late for me but I gave it to students). Search MaplePrimes for it.

Other than that, experiment and peruse the help facility. All CAS have a learning curve; Maple is no exception. If the help files let you down, read the above and/or ask here. And accept that initially you can solve problems faster by hand. The investment of time using Maple is worth it, though, as that will change as you get proficient.

M.D.

I second Tom and acre's suggestions to peruse the Programming Guide. It was the single most beneficial "book" for me, even for online use of Maple.

As you get into programming Maple, pay close attention to Maple's Modules and friends. While some learning is involved, it will make your life so much easier as your projects and programs grow in scope and size. Wrapping your code in modules (and possibly submodules) has proven for me to be a most powerful way to keep things organized and readable.

Inside your modules, a set of relatively short procedures with defined tasks will provide you with high-level functions that you can then connect together in your main program to do whatever it is you want to achieve. This is a more effective way of using Maple than writing long, monolithic code.

Another one of Maple's important functions is seq(), which in many cases can replace loops while executing faster and leading to more compact code. I remember seq() being slightly confusing initially; again, the effort spent on learning it is well worth it.

Ok, I shut up here. Maple is actually a wonderful programming language even if execution could be faster. It is my tool of choice these days unless I do large-scale simulation work that is cpu-time critical.

M.D.

There is a number of ways you can do this. Myself, I would package the routines in a module and load that using with(modulename), somewhat like this:

MName:=module() option package
  export A,B,C;

  A:=proc(arglist)
    ...
  end proc;

  B:=proc(arglist)
    ...
  end proc;

  C:=proc(arglist)
    ...
  end proc;

end module;

LibraryTools:-Save(MName,cat(libname[1],"/MName.mla")); # libname[1] has the directory where you want Maple to look for your packages.

A can use B and/or C and will know about them. There is also the "thismodule:-" prefix, but I doubt you need this here. The Maple Programming Guide explains all this; it is worth reading it.The "LibraryTools:-Save" function is necessary to create and save the .mla file Maple needs to load using with(MName).

Modules are a very powerful Maple constructs but they do take a little effort to use correctly. The reward is your ability to write your code in a very organized way, keeping things well structured and clear even when you build relatively large programs. They also allow you to write Maple code in a somewhat object-oriented fashion, further enhancing readability and maintainability of your code.

Mac Dude

If you run Maple in a (X)terminal, window is not supported as a plot device. You can try the x11 device if you run Maple in an xterm. The Maplet device seems to work, but you may have to plot "inside" the Maplet: RTFM (I have never done that).

I would wonder why, if plotting is involved, you use Maple in a terminal and not the GUI. Yes, the GUI is a bit clunky, but its plotting abilities are vastly superior to those of CLI-Maple.

M.D.

for i from 1 to 10 do
  for j from 1 to 10 do
  # stuff (i,j)
  end do; # j
end do; # i

You know, there is rather nice online help in Maple? Try it. In your sheet, just say
?for;

M.D.

If all you want is some random numbers for a given pdf, you may use the proc Rarbit I have uploaded below. The comments should make it clear how to use it. While Maple's RandomTools routines maybe more efficient for some pdfs, for others---in particular those with gaps like yours and also those with constantly changing parameters---they do not work all that well, and the simple-minded approach in Rarbit actually works better. I wrote it for a problem I worked on a while back. Note that later I found out that the use of MersenneTwister in this form is not efficient, but I haven't had the need to fix that yet. It only becomes an issue if you need gazillions of random numbers.

Hope this helps,

Mac Dude

Rarbit.mw

You need to load CUDA first, using with(CUDA);

Then CUDA is available as a module and you can do your check above.

On my system I get an Error: CUDA not supported on the current system... :-(.

Mac Dude.

Try 

DocumentTools[SetProperty]("PerformanceTable",update);

Per the online help this "forces an update".

"value" is not a property of the datatable object, so cannot be set. The refresh=true option works with other embedded components (I use it to update things like progress gauges in do loops), but maybe the datatable is different. It does appear the datatable elements can only be set by setting the associated Matrix elements.

Maybe you need to both set the refresh option and update.

Mac Dude

The code your link refers to is not a Packasge in the Maple sense, but rather a collection of procedures. You should be able to read it in like this after you saved the code in a file code.mpl:

read "code.mpl";

You can make a true Maple Package out of this code by wrapping it in a module like this:

Code:=module() option package;
export Help,S,...; # sequence of the names of all the procs in the code
(content of the file)
end module;

To make this accessible to Maple you first execute the above, which defines Code as a package. You then put it somewhere accessible:

LibraryTools:-Save(Code,cat(libname[1],"/Code.mla"));

where libname is a list of directories Maple will search for Code.mla.

You do this once and then you can load your package in any worksheet using with:

with(Code);

and it will all be there. Note that in this worksheet, libname also has to include the directory where Code.mla got saved. I do this in my .mapleinit file like this:

libname:="/Applications/Math_Calc/Maple 15/My_Maple_Libraries",libname:

whice prepends my own directory to whatever Maple needs, thus my stuff goes first.

HTH,

M.D.

Ok, I can actually answer my own question:

As the term "module factory" implies, the generated procs are methods of a module that gets instantiated when the module factory routine is called. The module of course is persistent as it is a structure assigned to a name. The proc then gets called using the name:-proc() call. So the stored value has to be local to the instantiated module, not the proc, in order to be persistent.

Oh well, it's at least a year since I last used the module-factory approach. I guess the gray matter isn't as persistent a store as it used to be... :-).

M.D.

Given Carl's comment it appears you need to get a copy of 64bit Maple. AFAIK that means Maple 17 or later.By your heading you run Maple 13. It's process is probably limited to something like 2 GB (depending on your compute platform). Can you use a sparse matrix? Maple knows how to do that; but I do not. RTFM.

M.D.