Moving the data points is easy with plottools:-transform. The hard part is deciding what the tickmarks should be. Once you've decided on the numbers for the ticks, placing them on the axis is easy.

I speak from experience: Back in Maple V or Maple 6, I was so dissastified with the ticks in plots[logplot], plots[loglogplot], plots[semilogplot], and their 3D counterparts that I rewrote the whole lot. And I also invented the equivalent of today's mode= log, which didn't exist at that time. All-in-all, it was about 600 lines of code, with about 2/3 of that for tickmarks. Unfortunately, that code won't run anymore. If it did run, it would be easy to replace the logarithm with any symbolically invertible strictly increasing function, such as your x^3 or x^(1/3).

@tomleslie I was just making a practical suggestion in case you wanted your plots to appear the same (or close) when posted here as they appear in Maple. I know that that's not the way that things should be; that's just the way that they are. Getting MaplePrimes bugs fixed seems much more difficult than Maple bugs.

@tomleslie If you specifically include gridlines= false in the code, then the gridlines won't appear when the worksheet is uploaded here.

@Thomas Richard More to the point is is's existential partner coulditbe:

coulditbe(f=0) assuming x<0, y<0;
      false

@Thomas Dean What Kitonum did wasn't factoring the polynomial in the usual sense, but rather factoring additive subparts. I don't think that there's any reasonable algorithm for it---it involves a lot of educated guesswork. I call it "subfactoring". 

@Thomas Dean For irreducible real polynomials in two variables, this is usually the best way to plot:

algcurves:-plot_real_curve(f, x, y);

One great thing about this is that you don't need to specify ranges for the variables---the command figures out appropriate ranges.

@nm The "main" for Maple is what is executing at the level where you type commands. No proc is equivalent to a "main".

@Joe Riel I didn't mean to imply that it was the same string. I'm just saying that &eacute; is a much-more-convenient way to enter e with an (acute) accent directly from the keyboard, rather than creating the string externally and copy-and-pasting or programming the bit-level manipulations of Unicode.

@lplex Maple understands most (perhaps all?) HTML &-codes directly typed into strings. So:

"d&eacute;cembre";

So copy-and-paste is not needed. This is much more user-friendly than Unicode (for direct keyboard input), even if it takes a few more bytes of memory. All such codes begin with &, are followed by some descriptive letters, and end with ;.

@Samir Khan You can easily directly compute the Katz centrality as below. This can be done in the worksheet anyplace after the graph G has been defined.

GT:= GraphTheory:  LA:= LinearAlgebra:
A:= Matrix(
    GT:-AdjacencyMatrix(G), shape= symmetric, datatype= hfloat
):
ME:= max(abs~(LA:-Eigenvalues(A)));
n:= upperbound(A,1):
CF:= 1.1: #Convergence factor: Can be any number > 1.
I__n:= Matrix(n, shape= identity, datatype= hfloat):
Ones:= Vector(n, 1, datatype= hfloat):
katz_centrality:= LA:-LinearSolve(I__n - A/CF/ME, Ones) -~ 1:

Then proceed with the sorting and plotting exactly as before.

@Adam Ledger CygWin is not a Linux virtual machine, it's just a Linux-like command-window environment. You can still run all your Windows programs from it, including Maple.

@Adam Ledger Yes, I was going to suggest that, although I don't know the precise details.

@Samir Khan  In the workbook attached to the section about centrality measures of graphs, you've misused the attenuation factor (alpha), which is the second parameter of GraphTheory:-KatzCentrality. You've used alpha=0.1, but this factor (for the results to be meaningful) must be smaller than the reciprocal of the eigenvalue of the adjacency matrix (A) of largest magnitude. In this case, that means it should be smaller than about 1/41. The reason for this is that the Katz measure is based on a matrix infinite geometric series with ratio alpha*A. This series diverges if alpha is larger than as stated above. The reason that KatzCentraility doesn't catch this is because it sums the series with the familiar geometric series formula: ((I-alpha*A^+)^(-1) - I), but this summation formula isn't valid for alpha larger than as stated above.

Actually, the bar chart produced for the Katz Centrality has a severe discontinuity for some alpha in 1/589.9390449..1/589.9390448, and the results seem meaningless to me for larger alpha. Since the reciprocal of the maximum eigenvalue of the weight matrix W (not the adjacency matrix A) is in this interval, it must be that KatzCentraility is using W rather than A. (I'd like to see a reference that backs up the validity of this.) If it's correct to use W, then certainly it's utterly meaningless to use alpha > 1/589.... 

@TianyuCheng The arrows, just like the curves, are generated in cartesian coordiantes. The transformation into polar coordinates causes some distortion.

@Adam Ledger Get CygWin on your Windows computers. It's a free, downloadable Linux-like "shell" command-window environment with all the standard Linux commands and text-processing tools.