spherical plot

[Oscar Lazo]

Well, this is basically a clone of mathematicas "SphericalPlot3d" only
that i thought the 3d was redundant.

I've published the function here: http://www.sagenb.org/pub/1319/ .
And cloned the examles in
http://reference.wolfram.com/mathematica/ref/SphericalPlot3D.html

So there. This would be my first contribution to sage, so thats
great! :D

[mhampton]

Congratulations! Do you have a trac account yet?

One thing you probably want to change is the assumption of variables
phi and theta. I recommend looking at the source of something such as
plot_vector_field3d.py (in plot/plot3d) for an example of setting up
the arguments using setup_for_eval_on_grid which avoids such
assumptions.

Cheers,
Marshall Hampton

On Jan 4, 11:22 pm, Oscar Lazo <algebraicame...@gmail.com> wrote:
> Well, this is basically a clone of mathematicas "SphericalPlot3d" only
> that i thought the 3d was redundant.
>
> I've published the function here:http://www.sagenb.org/pub/1319/.

> And cloned the examles inhttp://reference.wolfram.com/mathematica/ref/SphericalPlot3D.html

[Jason Grout]

This is fantastic! Thank you very much. I could have really used this
this last semester when I taught multivariable calculus, and I'll
definitely use this this next semester when I teach the same class!

If you have the time or inclination, maybe you could also generalize
this to a cylindrical coordinate plotting function. In fact, I wonder
how easy it would be to make a function that took a coordinate
transformation and gave back a plotting function in those coordinates:

Maybe something like:

def generate_plotting_function(transform):
"""
transform is a list of 3 functions
"""

def new_function(f, var_1, var_2, *args, **kwds):
g=[h(f,var_1,var_2) for h in transform]
parametric_plot3d(g, var_1, var_2, *args, **kwds)

spherical_plot=generate_plotting_function((r*cos(t)*sin(p),
r*sin(t)*sin(p), r*cos(p)))

cylindrical_plot=generate_plotting_function((r*cos(t)*z, r*sin(t)*z, z))

(I'm sure there are errors in the above; I wasn't careful about the
variable names above, for example).

Thanks,

Jason

[Oscar Lazo]

On 5 ene, 09:45, Jason Grout <jason-s...@creativetrax.com> wrote:
> This is fantastic!  Thank you very much.

You are very welcome :D

> If you have the time or inclination, maybe you could also generalize
> this to a cylindrical coordinate plotting function.  In fact, I wonder
> how easy it would be to make a function that took a coordinate
> transformation and gave back a plotting function in those coordinates:

I think that would be fairly easy! I will probably do so in short
time.
But i can't figure out a propper name, how about
"transform_plot" - "transform_plot3d"

[Oscar Lazo]

On 5 ene, 08:21, mhampton <hampto...@gmail.com> wrote:
> Congratulations!  Do you have a trac account yet?

I probably have one, but i can't remember my username.

I'll ask wstein for help ;-)

> One thing you probably want to change is the assumption of variables
> phi and theta.  I recommend looking at the source of something such as
> plot_vector_field3d.py (in plot/plot3d) for an example of setting up
> the arguments using setup_for_eval_on_grid which avoids such
> assumptions.

I don't know where to find this code... I'll see if i can find it.

[Jason Grout]

transform_plot3d sounds great. I like the "3d" on the end, as it
indicates to the user that they will be getting back a 3d plot, even if
it is redundant. What do you think? It seems nice and consistent to me.

As far as variable names go, there are several ways we usually support
calling a plotting function:

The following is what I'd like to think of as the "standard" way:

plot(f, (var1, var1_start, var1_end), (var2, var2_start, var2_end))

The following works if f is a function with ordered inputs (e.g., a
python function, or a lambda function, or a function declared with
f(x,y)=x^2*y, for example)

plot(f, (var1_start, var1_end), (var2_start, var2_end))

Note that in this case, you do not have explicit variable names, so
you'll have to make them up.

Also, in your original code, you could simplify it a bit to be:

var('phi,theta')
def spherical_plot(f,phiran=(phi,0,2*pi),thetaran=(theta,0,pi),**kwds):
phi=phiran[0]
theta=thetaran[0]
Rho=(f*cos(phi)*sin(theta),f*sin(phi)*sin(theta),f*cos(theta))
return parametric_plot3d(Rho,phiran,thetaran,**kwds)

Another idealogical difference---I usually think of theta as the azimuth
variable (i.e., as in polar coordinates) and phi as the elevation
variable (measured from the positive z axis). That's how all of the
calculus books I've taught from have it. However, I notice that
Mathematica and Wikipedia agree that the "standard" convention is for
theta to be the elevation (or inclination), and phi to be the azimuth,
and the coordinates to be listed as you have them above (i.e., elevation
before azimuth). As Wikipedia says:

"The standard convention (r, θ, φ) conflicts with the usual notation for
the two-dimensional polar coordinates, where θ is often used for the
azimuth. It may also conflict with the notation used for
three-dimensional cylindrical coordinates. [1]"

I suppose that conflict is why all the calculus books I've seen define
things in a consistent way, instead of apparently the "standard" way.

The reference [1] is to mathworld
(http://mathworld.wolfram.com/SphericalCoordinates.html), where there is
a nice table detailing different uses in different sources. Mathworld
itself uses the "consistent" convention that I and calculus books use.

I don't have a lot of experience with spherical coordinates outside of
the classroom. It would be a little confusing for my class to use your
function above, though, since it uses a different convention than what
we use in class. In that case, it would be great to have a
transform_plot3d function, so we could define a spherical plot function
with the conventions we are using (and so the class could clearly see
that spherical plots are just a special case of a much more general thing).

Anyways, thanks for this work!

Jason

[Jason Grout]

I thought a bit more about this generic function and posted some code to
the trac ticket at http://trac.sagemath.org/sage_trac/ticket/7850.

I called the function make_coordinate_plot3d---I wanted to somehow
convey that you wouldn't get a plot as a return value, but a coordinate
plotting function.

Thanks,

Jason

[Oscar Lazo]

I have published my own transform_plot3d
http://www.sagenb.org/home/pub/1323/
I was unaware of yours.

On 5 ene, 10:48, Jason Grout <jason-s...@creativetrax.com> wrote:
> The following is what I'd like to think of as the "standard" way:
>
> plot(f, (var1, var1_start, var1_end), (var2, var2_start, var2_end))

That's how i made it work

> Also, in your original code, you could simplify it a bit to be:
>
> var('phi,theta')
> def spherical_plot(f,phiran=(phi,0,2*pi),thetaran=(theta,0,pi),**kwds):
>     phi=phiran[0]
>     theta=thetaran[0]
>     Rho=(f*cos(phi)*sin(theta),f*sin(phi)*sin(theta),f*cos(theta))
>     return parametric_plot3d(Rho,phiran,thetaran,**kwds)

I did just that, thank you!

> Another idealogical difference---I usually think of theta as the azimuth
> variable (i.e., as in polar coordinates) and phi as the elevation
> variable (measured from the positive z axis).

I am aware of the naming conflicts, and I also find them troublesome.
However, I've removed the variable specific-ness, meaning you can
now use any variable name as azimuth or elevation!

I am not sure whether to add this the ticket I made before or to open
a new one for transform plot3d and put it all there, or to make one
for
transform plot3d and one for cylindrical plot... Are there any
conventions for this sort of situations?

BTW: I've also spotted the "revolution plot" in mathematica, that one
should also be easy to clone. I'll probably do so tomorrow.

[Jason Grout]

Oscar Lazo wrote:
> I have published my own transform_plot3d
> http://www.sagenb.org/home/pub/1323/
> I was unaware of yours.

Thanks again for working on this!

I've made some comments at http://trac.sagemath.org/sage_trac/ticket/7850

Thanks,

Jason

[Oscar Lazo]

On 6 ene, 01:16, Jason Grout <jason-s...@creativetrax.com> wrote:
> I've made some comments athttp://trac.sagemath.org/sage_trac/ticket/7850

I saw your comments (i'll edit the ticket when i'm sure how many of
those there
should be).

> 1. To be consistent with the plotting functions, it would also need to support something like:
>
> {{{
> spherical_plot3d(lambda x,y: x+y, (0,2*pi), (0,pi))
> }}}

with the changes i've made now, the format has to be
spherical_plot3d(lambda x,y: x+y, (var1,0,2*pi), (var2,0,pi))

but it seems like sage can't make the needed multiplication, i get:
TypeError: unsupported operand parent(s) for '*': '<type 'function'>'
and 'Symbolic Ring'

Instread why not just try:
spherical_plot(x+y, (x,0,2*pi), (y,0,pi))
Produces a seashell-like surface

All of the other comments have been taken care of ;)

> 5. I'm not sure there's any difference between the transform_plot3d and just plainly calling parametric_plot3d. transform_plot3d seems to just basically be a rename of parametric_plot3d.

Ummhh... yes, i guess you are right (flushes). I'll see if i can make
it into something useful...

[Jason Grout]

Oscar Lazo wrote:
> On 6 ene, 01:16, Jason Grout <jason-s...@creativetrax.com> wrote:
>> I've made some comments athttp://trac.sagemath.org/sage_trac/ticket/7850
>
> I saw your comments (i'll edit the ticket when i'm sure how many of
> those there
> should be).
>
>> 1. To be consistent with the plotting functions, it would also need to support something like:
>>
>> {{{
>> spherical_plot3d(lambda x,y: x+y, (0,2*pi), (0,pi))
>> }}}
>
> with the changes i've made now, the format has to be
> spherical_plot3d(lambda x,y: x+y, (var1,0,2*pi), (var2,0,pi))
>
> but it seems like sage can't make the needed multiplication, i get:
> TypeError: unsupported operand parent(s) for '*': '<type 'function'>'
> and 'Symbolic Ring'
>
> Instread why not just try:
> spherical_plot(x+y, (x,0,2*pi), (y,0,pi))
> Produces a seashell-like surface
>

That was an intentionally simple example to illustrate the problem.
Here's something that is more nontrivial:

def f(x,y):
if x>pi:
return y
else:
return -y

spherical_plot3d(f, (x,0,2*pi), (y,0,pi))

Thanks,

Jason

[Oscar Lazo]

On 6 ene, 12:23, Jason Grout <jason-s...@creativetrax.com> wrote:
> That was an intentionally simple example to illustrate the problem.
> Here's something that is more nontrivial:
> def f(x,y):
>     if x>pi:
>        return y
>     else:
>        return -y
>
> spherical_plot3d(f, (x,0,2*pi), (y,0,pi))

I have no idea how to make that work. Functions defined by parts are
surely somthing we'd want. The problem, as i've said is that sage
cannot
multiply functions andsage expressions. That is something better
suited
for more experienced sage programmers than myself...

I do have a workaround however:
spherical_plot(-y,(x,0,pi),(y,0,pi))+spherical_plot(y,(x,pi,2*pi),(y,
0,pi))

will do what you are thinking of

[Jason Grout]

Oscar Lazo wrote:
> On 6 ene, 12:23, Jason Grout <jason-s...@creativetrax.com> wrote:
>> That was an intentionally simple example to illustrate the problem.
>> Here's something that is more nontrivial:
>> def f(x,y):
>> if x>pi:
>> return y
>> else:
>> return -y
>>
>> spherical_plot3d(f, (x,0,2*pi), (y,0,pi))
>
> I have no idea how to make that work. Functions defined by parts are
> surely somthing we'd want. The problem, as i've said is that sage
> cannot
> multiply functions andsage expressions. That is something better
> suited
> for more experienced sage programmers than myself...

The code I posted up (based on your original code) at
http://sagenb.org/home/pub/1322/ handles this correctly (I think) if you
manually define the f_is_expression to be False at the top of the
function. Somewhere, there's a nice way to see if f is a symbolic
expression---that test should be done where we now manually set that
variable. On the other hand, maybe we could just try executing the
first block of code, and make an "except" statement if there is an error
that runs the second block of code.

Thanks,

Jason

[Oscar Lazo]

I've finished adding Jason's code and suggestions. Those can be found
at

http://www.sagenb.org/home/omologos/9/

and the corresponding tickets at
http://trac.sagemath.org/sage_trac/ticket/7850
http://trac.sagemath.org/sage_trac/ticket/7869
http://trac.sagemath.org/sage_trac/ticket/7872

I still have to add support to the format plot3d(f,(x0,xf),(y0,yf)) ,
though...

[kcrisman]

On Jan 8, 12:51 pm, Oscar Lazo <algebraicame...@gmail.com> wrote:
> I've finished adding Jason's code and suggestions. Those can be found
> at
>
> http://www.sagenb.org/home/omologos/9/
>

Just FYI, we don't have access to your home directory on sagenb :) so
you may want to publish that, with the option that it updates when you
make further refinements.

- kcrisman

[Oscar Lazo]

> Just FYI, we don't have access to your home directory on sagenb :) so
> you may want to publish that, with the option that it updates when you
> make further refinements.

Yes, that was not the right link, this one is
http://www.sagenb.org/home/pub/1328/
BTW: it was already published

[kcrisman]

On Jan 8, 2:17 pm, Oscar Lazo <algebraicame...@gmail.com> wrote:
> > Just FYI, we don't have access to your home directory on sagenb :) so
> > you may want to publish that, with the option that it updates when you
> > make further refinements.
>

> Yes, that was not the right link, this one ishttp://www.sagenb.org/home/pub/1328/

> BTW: it was already published

Sorry, I didn't see that. These are very nice - kudos! I noted on
one of the tickets than allowing 'polar' to work in this fashion was a
possibility - that would be good too. Sounds like the CCLI team might
have another example of how development is driven.

- kcrisman

[Oscar Lazo]

> Sounds like the CCLI team might
> have another example of how development is driven.

What is that, CCLI team?