Stretto

145 Reputation

5 Badges

1 years, 69 days

MaplePrimes Activity


These are replies submitted by Stretto

@acer 

Yeah, that is what I wanted. Thanks. I ended up just using plot since it seems to be easier. I didn't need to have  Float(undefined).

@ThU 

No. This is not a solution.

@dharr 

Not always can can still be hard to see. It seems maple craps out for some equations.

@acer 

What a strange issue. I don't need a movie. I just want to see an animation lik eone can do with plots.

 

Also, for the function below, there is a strange issue.

f := [sign(r)*ln(abs(r))*cot(x)*(1 - x*sin(x))]:
F := BP(f, [0.1], 33000, 1 - 0.0000001, 1 + 0.0000001, -0.0001, 0.0001):

 

BP seems to spread out the interations over some larger zone than above. Zooming in on the point around one requires a huge number of iterations to get decent a decent image.  This could be due to something funky about f but it seems like it might be a problem with Bifurcation itself. I've tried with 10M points and it works but takes a long time... I don't see why 10M points would be needed unless a lot of points are overlapping OR Bifurcation is doing something odd that it shouldn't do. (like having a minimum window that it will compute over and then just crops, meaning a lot of resolution is lost and one has to waste a lot of computational time)

 

 

 

@Carl Love 

 

Given that these are strings, I need to collect on them. Is there any way to collect on a string?(remember, the color is only visual).

@Carl Love 

 

It doesn't work insidee a sequen when 5 is variable.

seq(Color(ithprime(k)),k=1..n)

 

which is used inside another procedure. It's hard to describe but maple ends up complaining at some point. simple cases work, compelx do not. I have to resort to using ``.

EV was a hypothetical Evaluate function that forced the arguments to be evaluated inside out.

@acer 

@Carl Love 16357

Thanks, I made a handy function:

Color := proc(x, H := .42)
    uses Typesetting, ColorTools;
        mn(convert(x, string),
            ':-mathcolor'= RGB24ToHex(Convert([H,1$2], "HSV", "RGB24")),  
            ':-size'= "16",
            ':-fontweight'= "bold");
end proc:

 

but when I call it with something like ithprime(5) it prints out ithprime(5) rather than first evaluating ithprime(5). I run in to this problem a ton. How I can I get maple to always evaluate something at the call site?

Color(EV(ithprime(5)))

EV is called first before Color. It seems maple evaluates from outside to inside rather than the normal way of inside to outside.

(it would actually have to be used inside Color since I don't want to have to add more chars for no reason)

 

 

 

 

@Carl Love 

Intersting, thanks for the help.

@Kitonum 

 

Thanks, one major issue is that when there is only one element in the list I get `%+`(x)

 

While I could bypass this with if's it would be nice if it worked for single elements too. (just return x)

 

also, what if I just want paranthesis(no mutliplication in front?) or I want to do it around a variable that is a sequence. 1%/5*r where r is some sequence alreading using inert stuff. Surely there is some way to insert an inert character?

@Carl Love 

@acer

Thanks. I thought I responded. Plots look nice.

@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).

 

 

 

 

 

 

1 2 3 4 5 6 Page 1 of 6