@Carl Love 

I can't use an estimate.

I tried to find a text file to read and I couldn't. There are fast algorithms for doing this sort of thing.  No where on that page do they talk about using a database for pi(x). I do see for primes. Maple gives no indication how it is computing pi(x).

I could try too use the page to generate the values but I'd like to avoid this.

@acer 

Thanks, pretty close and probably good enough. The grid is still rectlinear unlike drawing the curves myself which are the true surface structure. It's just a minor difference.

I'm not familiar with maples coordinate representations so I didn't bother.

P3 := seq(spacecurve([seq([Cl((j+O)/R*cos(2*Pi*t)), Cl((j+O)/R*sin(2*Pi*t)), sign(k)*(abs(k) - 1.5)/140 + sign(k)*f(Cl((j+O)/R*cos(2*Pi*t)),Cl((j+O)/R*sin(2*Pi*t))),color=[RGB(j/(R+1),j/R*sin(2*Pi*t)^2,t)]], k=[-2,-1,1,2])], t=0..1, thickness=4, transparency=0.7, numpoints=1500),j=0..R+3):

The issue is that the color is set with

color=[RGB(j/(R+1),j/R*sin(2*Pi*t)^2,t)]],

and t is a parameter. It is not updated during the rendering. It just set's it to the first value of t which is 0.

The color is set inside the spacecurve function so it has access to t, or it should.

Essentially I would like to have it render the same color as what happens in your lots(more or less, be based off the surface function).

@Kitonum 

Isn't that pretty much exactly what discont is suppose to do? discont=[usefdiscont=[bins=35]] does it too if bins is high enough(but potential overkill)?

@Carl Love 

Cl := x->max(-1,min(1, x)):

M := 15:
R := 5:
O := 0.1:
#-sqrt(1-x^2)..sqrt(1-x^2)
f := (x,y)->Re(sqrt(x+_i*y)):
P1 := plot3d([seq([x, y, k*f(x,y)], k=[-1,1])
], x=-1..1, y=-1..1, labels=[x,y,Rew],style=surface, grid=[400,400], thickness=2, colorscheme=["xyzcoloring", [(x,y,z)->y^2,(x,y,z)->x*y,(x,y,z)->x^2]]):

# The radial lines
P2 := seq(spacecurve([seq([Cl(t*cos(2*Pi/M*j)), Cl(t*sin(2*Pi/M*j)), sign(k)*(abs(k) - 1.5)/140 + sign(k)*f(Cl(t*cos(2*Pi/M*j)),Cl(t*sin(2*Pi/M*j))),color=[RGB(1,j/M/3,j/M/3)]], k=[-2,-1,1,2])], t=0..R, thickness=4, transparency=0.7, numpoints=1500),j=1..M):

# The polar lines
P3 := seq(spacecurve([seq([Cl((j+O)/R*cos(2*Pi*t)), Cl((j+O)/R*sin(2*Pi*t)), sign(k)*(abs(k) - 1.5)/140 + sign(k)*f(Cl((j+O)/R*cos(2*Pi*t)),Cl((j+O)/R*sin(2*Pi*t))),color=[RGB(j/(R+1),j/R*sin(2*Pi*t)^2,t)]], k=[-2,-1,1,2])], t=0..1, thickness=4, transparency=0.7, numpoints=1500),j=0..R+3):

display(P1, P2, P3);
display(P2, P3);
display(P3);

The issue is that the surface lines color cannot change with the angle or radius(t), so I can't have them correctly map surface properties. You can see this because I use t above for the color, t goes from 0 to 1

The RGB color is not able to use t, the parameter for the spacecurve. You can see the polar lines(the circules) changes color per radius increment, but not angle wise(t). The other lines, the radial lines have the opposite issue. They both stem from the t parameter in spacecurve not "updating" the RGB color(It's evaluating it before or after the spacecurve values are computed and not during)

@Carl Love

Those "grid lines" are just generated haphazardly by plotting the sqrt function for polar rays, becaues they extended past the standard plot it looked funky so I used min/max to limit them and the effect is those corner pieces. They are effectively just "glitches" but they ended up looking nice(I wouldn't mind if they wrapped all the way around).

As I said, the standard rectangular grid lines do not give a meaningful representation of the surface. The surface is generated from a revolution of the sqrt function. The grid lines I ploted are just "sections" of to give a refernce to the way the surface evolves. Rectangular grid lines do nothing to expose how the surface is formed or it's innate curvature.

sqrt(z) = sqrt(r)*e^(i*t/2)

I'm just ploting those rays for various angles t. using min/max on it to limit it to the range of the plot(an artifact of how plotting the spacecurves as r goes from 0 to x(I didn't want to figure out x, which depends on the angle so I just used min/max).

In fact, it would be nice to plot for fix r too, to get a proper "grid". I guess I can do that.

The issue is coloring those space curves properly(rather than all just being purple or solid). I want to color them based on the property of the surface.

Not sure if this is all the code or not but it will give you an idea:

Cl := x->max(-1,min(1, x)):

M := 25:
#-sqrt(1-x^2)..sqrt(1-x^2)
f := (x,y)->Re(sqrt(x+_i*y)):
P1 := plot3d([seq([x, y, k*f(x,y)], k=[-1,1])
], x=-1..1, y=-1..1, labels=[x,y,Rew],style=surface, grid=[200,200], thickness=2, colorscheme=["xyzcoloring", [(x,y,z)->y^2,(x,y,z)->x*y,(x,y,z)->x^2]]):
P2 := seq(spacecurve([seq([Cl(t*cos(2*Pi/M*j)), Cl(t*sin(2*Pi/M*j)), sign(k)*(abs(k) - 1.5)/140 + sign(k)*f(Cl(t*cos(2*Pi/M*j)),Cl(t*sin(2*Pi/M*j))),color=[RGB(1,t^2*sin(2*Pi/M*j)^2,1)]], k=[-2,-1,1,2])], t=0..13, thickness=4, transparency=0.7, numpoints=1500),j=1..M):

display(P1, P2);
display(P2);

Oh, damn, I already posted that code ;/ lol

The issue is not the grid lines, I already generated them, it is the coloring and transparency. I can create the lines how I want but I can't color them how I want. some of the issues I mentioned were because when I have to manually create these gridlines(maybe better to call them surface lines) the rendering would be funky. I have to double them up and put them slightly above and below the surface so they are not partially obsucured by the "infinitely thin" surface(since it's not infinitely thin it inserects the gridlines and cover them up).

@Joe Riel 

Thanks, so

P := Iterator:-Permute([a,b,c,d,e]):
for p in P do printf("%{}a\n",p); end do:

is the answer?

for p in Iterator:-Permute(5) do 
    printf("%a\n", [10,J,Q,K,A][[seq(p)]]) 
od:

I couldn't/didn't follow the discussion about efficiency. Is there any difference between the two or not? They essentially seem like the exact same.

@tomleslie 

see my other post.

@Carl Love see my other post.

@Kitonum 

all these plots of you guys completely obscure what the surface really is.

The grid lines are projections of a rectangular grid on to the surface and have nothing to do with the intrinsic topology of the surface.

The surfaces are not in opposition as your colors suggest, you colored it to suggest they are. You can color the surface how you please but most will be meaningless mathematically.

None of these posts address my original question about color the grid lines properly and dealing with transparency. They are all just different ways to plot the complex function sqrt(z).

The Riemann surface sqrt(z) is a surface generated by sqrt(z), or sqrt(abs(z))*exp(i*ang(z)/2)

That is, it is a surface that involves a "rotation" of the sqrt(x) in complex space. Hence the reason I drew the gridlines the way they were.

All those grid lines are sqrt(z) functions You can see the obvious parabola, the inverse of sqrt, but every other one also is a "parabola", but they are also related to other functions such as cubics, quartics, etc. (the surface can also be seen to be generated by a parabola)

In the image the "grid lines" are all the same color(the purple/magenta) and I do not want that. I want to color them based on their position and values.

The coloring is somewhat arbitrary here but ultimately I was tryign to color it based on a feature of the curve, rather than "opposition" of the two surfaces. That is, we have color to show another dimension, no need to waste it. Since this is the real part it is nice to use the color to show the imaginary value or the magnitude, or whatever. It's not just about displaying a surface but packing in as much relevant information as possible in a nice way.

1. I do not want the same color for all the lines. I want the colors to depend on the surface in some way(but contrasting to the surface color enough, such as having them darker).

2.  It would be nice if there was some type of visual depth cue...  that is, more distant point are darker and thinnner.

Mable really fails at doing this stuff ;/ I feel like I'm going to have to switch to a program that really excells at graphing both visually and speed wise. (I do use some programming libraries in programming languages but they tend to be more work to do simple plots. I like maple for it's general feature set but plotting quality and interaction and performance are a major drawback for me ;/)

I use matlab sometimes but I just like maples symbolic side...  but any time I get beyond simple plotting I really get discouraged from using it ;/ Is there any way to speed it up and to make the plots better? I could potentially write an external library if I have to if it would not be a huge amount of work and could be done.

matplotlib

mayavi

mayavi seems to be the absolute best I've seen as far as speed and quality(well, not best but good)

What would be cool is if I could use maple and somehow interface with some library like this(well, what would be better is if maple itself was faster and prettier).

@acer 

While this works one thing I'm finding is I'm constantly having to add extra parentheses. is there any way to change the precedence?

@Carl Love 

As I said.

1. With an "empty" maple.ini file(Something has to be in it or maple gives an error. I put in with(plots):) maple gives a blank like in a new worksheet without retart: ever being used. I.e., there are no print statements, no other statements. Even if just the statement x := 3: in maple.ini the same thing happens.

2. It doesn't matter about restart: I always put it at the top so I can easily clear stuff if need be but it is ultimately irrelevant to the problem. The problem is that maple is adding an additional line for some reason and I have no clue why. It may not have anything to do with maple.ini but I'd have to delete the file to check, well, I guess I'll try:

>
restart:
Error, unable to read `C:\Docs\Math\maple.ini`
>

The extra lines produced are the >

That was from deleting maple ini and that is in a new worksheet.

I'd then have to go add the ini file for the settings and see if that would stop it or is producing it somehow.

@Carl Love 

Thanks, maybe I'll start using it. Those caches are what are also called circular buffers. I was using this

global _Hist
_Hist := [N, op(_Hist[1..-2])];

In a similar way. I'll try to start getting in the habit using maple caching.

What you say about option remember, system; Generally how often? Every time memory or numbers change? They change all the time when I do any computation, this may be a bit excessive if it is constantly collecting.

Generally what I'd like is to be able to use a computation and have it optimized for the length of the computation(such as in a plot) and not be garbage collected while the overall computation is going on... unless there are memory issues.

@Mac Dude 

It may very well be due to algebric representation. I never declare float. I also have that issue where it sometimes tries to compute certian things symbolically and craps out(e.g., if I change a variable name and forget to change it in the code then maple will try to compute the universe).

There is the other thread where I talk about plotting using matrixplot and it becomes impossibe after a small number. Also when I use grid.

QQ := Matrix(150,150,(i,j)->evalf(cos(i*j^cos(i)))):
matrixplot(QQ, heights=histogram);

that too 3GB. I had to use evalf for some reason(never had to before but I guess it has to do with the functon).

If I do a few of these types of plots I run out of memory. Mind you though I usually have firefox runing and that takes a few GB because it is a monster hog too. If I end up doing another thing that uses a few gigs I hit the upper limit quite quick. Maple doesn't seem to manage memory all that well. Once I do a lot the memory seems to be in use... even though surely most of the memory is not needed to be consumed.

@Carl Love 

yes, but it happens before any line because it's comming from the maple.ini. So even with a new worksheet in and nothing in it. If I put anything in the maple.ini file it happens. To be clear, I do use restart:

Now, before I started to use maple.ini I don't remember seeing this and so I think it has to do with the maple.ini file. Probably not fixable.

@Carl Love 

Thanks, that worked. I still get a single output line though, and it seems to do it no matter what is in the ini file ;/ That is, if I just put with(plots) in the ini file then I get a blank output line.