The following two postings made in other topics deserve to be seen in this discussion.

• don't limit technology
• SmartPlotBuilder - a wish (now moved to this forum -- see below)

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

This response has been moved to the Maple 15 - Wish List discussion.

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

Alex,

Why stop with 15 years, and Maple 13?

Surely Maple 14 and further releases will be even better.

Your suffers from the same problem you complain about in your post.  At that time, the suggestion was good. Right now, Maple 13 is the best we have.

Moreover, the TI-85 still exists and is useful. It's my opinion that all technologies -- pencil/paper, calculator, CAS, ... -- have their place. Just like TV did not eliminate radio. As more options develop users have more choices about which tool to utilize. The challenge we have to address is deciding which technologies to use for which purposes.

Personally, I do not spend much time trying to predict the future. I expect reality to far exceed anything I could imagine today.

For example, while it's not possible today, it would not surprise me if someday (not too far in the future), "smart phones" (iPhone, droid, ...) or "e-readers" (Kindle, ...) are able to run applets written in Java - or some equivalent.

How is any of this relevant to Maple and MaplePrimes? When this becomes possible, maplets (or worksheets) served via MapleNet (or the "cloud") could be accessible from a handheld device and a mathematical e-book on an e-reader  could be truly interactive.

To me, this is not a question of "if" - it's "when". The exact underlying technology might change, but I believe the functionality will appear - it's just a matter of how long before it becomes reality.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

I, too, concur. These guidelines are clear, well stated, and very appropriate.

In my view, a moderator should be almost invisible (as Jacques has already expressed). We aren't here to correct or polish others posts. We are here to keep order and to try to eliminate anything that will detract from the utility of the MaplePrimes forum.

Posts like Patrick's last post are just thinly veiled attempts to try to bait one or more of us into action. To be honest, when I saw the first misspelling I almost fell for the trap. When I saw all of the "errors" I stopped - and smiled.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

When I read Axel's question, I interpretted "see" as "derive". Robert's response "verifies" the equality of these two expressions. Maybe this does answer Axel's question.

But, I'll ask my question: Is there a way to DERIVE the alternate form?

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

When I read Axel's question, I interpretted "see" as "derive". Robert's response "verifies" the equality of these two expressions. Maybe this does answer Axel's question.

But, I'll ask my question: Is there a way to DERIVE the alternate form?

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

acer,

Now, let me respond to your question about embedded components and maplets.

This was discussed at length. Maplesoft is clearly aware of this situation. I understand that maplets are not high on the list to receive any further development. All future improvements will be directed towards embedded components. It is my understanding that Maplesoft's intentions are to provide users with many of the same controls over embedded components that are already available within maplets. I do not have any clear idea about the order in which additional features will be introduced, or at what pace they will appear.

I hope others who are looking forward to enhanced embedded components will speak up and let Maplesoft know what they want to see. (I know at least one person has included improved embedded components in their Wish List for Maple 15. Any others?)

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

acer,

Thank you for keeping me honest. In an effort to keep threads on a single topic, I'll respond separately to each of your questions.

The issue about .mw files and webmail was not discussed directly. Recall, the same problem exists with .docx, .xlsx, and other files saved as XML. The security concern is that there could be a malicious program hidden within the XML. All of this was discussed in the original MaplePrimes discussion.

While at Maplesoft I did have some discussions about size differences for Maple file formats. In particularly, noting how large .mw files can be - compared, for example, with a .maplet file. (.maplet files are essentially text files). There is recognition of this issue. My suggestion is the use of a compressed worksheet format. There is a .mwz format that appears to fit these requirements. I can't say this with certainty because, as far as I know, .mwz files can only be created by Maplesoft and can only be read by the Maple Player.

I do not understand why there are such tight controls on the creation of .mwz files, and why they can only be accessed with the Player. Maybe this is a temporary situation and I just need to be patient to let the evolution progress through another generation (hopefully not two or more generations).

What do other readers think about this? Other ideas? Support for the status quo? Let's hear what you think.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

The left angle bracket (less than) is the opening delimiter for HTML tags.

I do not see that I am having any trouble entering angle brackets in the MaplePrimes editor, but I do remember having this problem in the past.

When I did have this problem I had to remember that to enter a less than, or left angle bracket, I needed to use &lt to get <.

There is no problem with the greater than (right angle bracket): >

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

Done.

The new blog entry can be found at http://www.mapleprimes.com/blog/dougmeade/maple15wishlist

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

This is why I suggested you might want to look at the Statistics:-Histogram command. I don't see that it makes any sense to combine the plots of the data and the differences in the same plot. Here's how I would begin to look at the histogram of the differences:

genRequestDist2 := proc( N, t )
  local data, dif, pts1, pts2;
  data := sort( RandomTools:-Generate( list( integer(range=1..t), N ) ) );
  dif := [seq( data[i+1]-data[i], i=1..N-1 )];
  Statistics:-Histogram( dif, bincount=nops(ListTools:-MakeUnique(dif)) );
end proc;

For example,

genRequestDist2( 100, 1000 );

You'll probably want to fine tune the bincount setting, or use other options (see ?Statistics,Histogram for a full description of the available options)

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

This is why I suggested you might want to look at the Statistics:-Histogram command. I don't see that it makes any sense to combine the plots of the data and the differences in the same plot. Here's how I would begin to look at the histogram of the differences:

genRequestDist2 := proc( N, t )
  local data, dif, pts1, pts2;
  data := sort( RandomTools:-Generate( list( integer(range=1..t), N ) ) );
  dif := [seq( data[i+1]-data[i], i=1..N-1 )];
  Statistics:-Histogram( dif, bincount=nops(ListTools:-MakeUnique(dif)) );
end proc;

For example,

genRequestDist2( 100, 1000 );

You'll probably want to fine tune the bincount setting, or use other options (see ?Statistics,Histogram for a full description of the available options)

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

To answer your question: Your code does implement the sort, but it's not efficient.

Here's a better implementation of the ideas that I believe you are trying to implement.

cocktailsort2:=proc(L)
 local n,o,r,k,i:
 n:=rtable_dims(L):
 o:=rhs(n):
 r:=lhs(n):
  
 for i from r to o - 1 do
   if L[i] > L[i+1] then
     (L[i], L[i+1] ) := (L[i+1], L[i]);
 #  else
 #    (L[i], L[i+1] ) := (L[i], L[i+1] );
   fi:
 od;
 for k from o to r+1 by -1 do
   if L[k] < L[k-1] then
     (L[k-1],L[k]) := (L[k],L[k-1]);
#   else
#     (L[k-1],L[k]) := (L[k-1], L[k]);
   fi:
 od:
 
 return(L);
end proc:

There is no need for the else clauses - these do nothing.

More importantly, you don't want to nest your loops. They are completely independent. This should eliminate a lot of duplicate work. But, as I reconsider exactly what this does, I doubt it's reallyl what you want either.

It seems to me that you are wanting to work on both ends at the same time, alternating from the left and the right. Maybe something like this?

cocktailsort3:=proc(L)
 local n,o,r,k,i,swapped:
 n:=rtable_dims(L):
 o:=rhs(n):
 r:=lhs(n):
  
 swapped := true:
 while swapped do
  swapped := false;
  for i from 0 to o - r - 1 do
   if L[r+i] > L[r+i+1] then
     (L[r+i],L[r+i+1]) := (L[r+i+1],L[r+i]);
     swapped := true;
   fi:
   if L[o-i] < L[o-i-1] then
     (L[o-i-1],L[o-i]) := (L[o-i],L[o-i-1]);
     swapped := true;
   fi:
  od:
 od:
 
 return(L);
end proc:

Now, neither of my procedures is a complete sort. Both need to be called repeatedly; the exact number of times seems to depend on the number of elements in the list.  A quick Google search led me to the Wikipedia page http://en.wikipedia.org/wiki/Cocktail_sort, from which I easily modified my algorithm to produce:

cocktailsort4:=proc(L)
 local n,o,r,k,i,swapped:
 n:=rtable_dims(L):
 o:=rhs(n):
 r:=lhs(n):
  
 swapped := true:
 while swapped do
  swapped := false;
  for i from 0 to o - r - 1 do
   if L[r+i] > L[r+i+1] then
     (L[r+i],L[r+i+1]) := (L[r+i+1],L[r+i]);
     swapped := true;
   fi:
   if L[o-i] < L[o-i-1] then
     (L[o-i-1],L[o-i]) := (L[o-i],L[o-i-1]);
     swapped := true;
   fi:
  od:
 od:
 
 return(L);
end proc:

The key here is that the main loop continues until no more swaps are made.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

To answer your question: Your code does implement the sort, but it's not efficient.

Here's a better implementation of the ideas that I believe you are trying to implement.

cocktailsort2:=proc(L)
 local n,o,r,k,i:
 n:=rtable_dims(L):
 o:=rhs(n):
 r:=lhs(n):
  
 for i from r to o - 1 do
   if L[i] > L[i+1] then
     (L[i], L[i+1] ) := (L[i+1], L[i]);
 #  else
 #    (L[i], L[i+1] ) := (L[i], L[i+1] );
   fi:
 od;
 for k from o to r+1 by -1 do
   if L[k] < L[k-1] then
     (L[k-1],L[k]) := (L[k],L[k-1]);
#   else
#     (L[k-1],L[k]) := (L[k-1], L[k]);
   fi:
 od:
 
 return(L);
end proc:

There is no need for the else clauses - these do nothing.

More importantly, you don't want to nest your loops. They are completely independent. This should eliminate a lot of duplicate work. But, as I reconsider exactly what this does, I doubt it's reallyl what you want either.

It seems to me that you are wanting to work on both ends at the same time, alternating from the left and the right. Maybe something like this?

cocktailsort3:=proc(L)
 local n,o,r,k,i,swapped:
 n:=rtable_dims(L):
 o:=rhs(n):
 r:=lhs(n):
  
 swapped := true:
 while swapped do
  swapped := false;
  for i from 0 to o - r - 1 do
   if L[r+i] > L[r+i+1] then
     (L[r+i],L[r+i+1]) := (L[r+i+1],L[r+i]);
     swapped := true;
   fi:
   if L[o-i] < L[o-i-1] then
     (L[o-i-1],L[o-i]) := (L[o-i],L[o-i-1]);
     swapped := true;
   fi:
  od:
 od:
 
 return(L);
end proc:

Now, neither of my procedures is a complete sort. Both need to be called repeatedly; the exact number of times seems to depend on the number of elements in the list.  A quick Google search led me to the Wikipedia page http://en.wikipedia.org/wiki/Cocktail_sort, from which I easily modified my algorithm to produce:

cocktailsort4:=proc(L)
 local n,o,r,k,i,swapped:
 n:=rtable_dims(L):
 o:=rhs(n):
 r:=lhs(n):
  
 swapped := true:
 while swapped do
  swapped := false;
  for i from 0 to o - r - 1 do
   if L[r+i] > L[r+i+1] then
     (L[r+i],L[r+i+1]) := (L[r+i+1],L[r+i]);
     swapped := true;
   fi:
   if L[o-i] < L[o-i-1] then
     (L[o-i-1],L[o-i]) := (L[o-i],L[o-i-1]);
     swapped := true;
   fi:
  od:
 od:
 
 return(L);
end proc:

The key here is that the main loop continues until no more swaps are made.

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu

While it's great that you like Peter's work, it would be even better if you would provide a link to them.

A Google search locates them very quickly. The direct URL is http://www.peterstone.name/Maplepgs/maple_index.html

Doug

---------------------------------------------------------------------
Douglas B. Meade  <><
Math, USC, Columbia, SC 29208  E-mail: mailto:meade@math.sc.edu
Phone:  (803) 777-6183         URL:    http://www.math.sc.edu