275 Reputation

5 Badges

1 years, 62 days

Social Networks and Content at Maplesoft.com

Editor-in-Chief of Maple Transactions (www.mapletransactions.org), longtime Maple user (1st use 1981, before Maple was even released). Most obscure piece of the library that I wrote? Probably `convert/MatrixPolynomialObject` which is called by LinearAlgebra[CompanionMatrix] to compute linearizations of matrix polynomials in several different bases. Do not look at the code. Seriously. Do not look. You have been warned.

MaplePrimes Activity

These are replies submitted by rcorless

@Carl Love I once proposed that subject line as the title of our article on Gamma; both Jon and Judi recoiled in horror, even though it's a palindrome.

I had not known that this integral was expressible in terms of Psi.  Thank you---that derivation is cool, too; I like FormalPowerSeries.

@Kitonum I hadn't known about the "continuous" option; I am going to go look at it now.  This is something I really really should have known.

Okay, then---TIL about Algebra Tiles!  Totally going to show this to my daughter (who is a teacher).

Blink, blink!

@jeffreyrdavis75 I like the pictures too.  And, yes, one can do 3d versions (we haven't, so far, but there is a good reason to if we want to colour by condition number and by density both at once).  Have at it!


I do not know why my animation tool bar does not appear.  However, I can run the animation by using right-click and the context menu.  Fine.  Principle of conservation of recusancy, I guess.


Now I have a different problem; plots[animate] has replaced the old "insequence=true" option, and I find my handling of it to be hit-and-miss.  The following produces a static plot only, not an animation, the way I expected it to.  Any thoughts?


plots[animate](plots[pointplot], [[seq([n, sin(combinat[fibonacci](k + 1)*n/combinat[fibonacci](k))], n = 1000 .. 2000)], symbol = point, axes = boxed, labels = [n, typeset(sin(combinat[fibonacci](k + 1)*n/combinat[fibonacci](k)))], labeldirections = [horizontal, vertical]], k = [seq(j, j = 1 .. 12)]);


I'll try "with(plots)" now just in case that works, but I would expect this to work with the long forms.

@acer This earns you an acknowledgement in the paper :)  I am happy to use your real name there if you like, but if you want to keep the pseudonym I'm happy to do that, too!

@mmcdara I hope to get to a planned improvement in that package (our original version was a little better for derivatives).  Let's see what happens, now that I am retired :)

Here's one paper using it---there are others listed on David Jeffrey's home page.


Thank you very much!  That explains everything.  Yes, circuits is what I meant (and not knowing any graph theory, I was unaware of the different definitions of "cycle" and "circuit").  When I converted to an undirected graph (to make CycleBasis work) via the UnderlyingGraph command, the pair of directed edges [12,4] and [4,12] collapsed to a single undirected edge; at that point no cycle remained.  But if three or more vertices are involved in a circuit (in my application), they have to collapse to a cycle.  Ok, that explains that puzzle very well.

In my application the directed graph comes from a deterministic dynamical system; there is only one edge leading from any given vertex, and so detection of a cycle in the underlying graph is automatically detection of a circuit in the original; but thank you for teaching me how to check it in a more general situation.  Your showing how to use ListTools there was also helpful---didn't know about Rotate!

@Preben Alsholm well done!

@Axel Vogt you are exactly right :)


@Axel Vogt Thanks for "analytic involution".  I had only ever seen the word "involution" used in a geometric construct, and that long ago.  Had no idea that the idea was in such wide use!  The Wikipedia entry on involution is quite informative.

You are also exactly right about the need to be careful with branches.  This particular computation would be easier if we had stuck with Dave Hare's original choice for the branch numbering; but the choices we made make things nicer both at zero and at infinity; and we saw no way to make them all work well.


Implicitly allowing a multiplication without a multiplication symbol has been a user desire for Maple for a very long time.  Donald Knuth wanted it in Maple, for instance.  That it's convenient I cannot deny: 2x versus 2*x.

But Maple's use of operators is simply too useful to throw away: f(x) means the application of the operator f to the argument x.  It is obvious that Maple must continue to allow that.  

But since the beginning, constants in Maple are constant *operators*.  Thus when we say 600(x) that means "six hundred applied to the argument x" we are asking to evaluate the constant operator at argument x.  The answer is 600.  This is an incredibly useful feature of the Maple language, and it is still present in Maple.  I remember writing a section of a chapter on this in my book (back before some of you were born, I think).  (Where's my cane?  You young whippersnappers.)

At some point, though, Maple bowed to the inevitable (they resisted Donald Knuth! But I suspect that lots of people wanted what he wanted) and so --- in 2D Math Input --- one can get 600*300 when one does 600(300) : Screenshot

Or, copying and pasting directly from the worksheet (which hides the 2D math formatting and really obscures the point)



You will see when writing (x-600)(a + b) in 2D math input that when you open the "(" you get a pop-up window asking you if you really want to multiply instead of use the operator.  

I understand the need for the compromise and why implicit multiplication is needed, but I use operators nearly every week and when I say (x-600)(a+b) I always (what, always? Yes, always.  Always?  Well, almost always) want the operator form. So that message kind of annoys me.  But I see why it has to be there.

But having both really means that people who don't know about operators are going to stub their toes when what they type means something different to what they had intended.

Page 1 of 1