Hello David, Yes, I tend to use mostly "style=surfacecontour" because the contour lines are independent of the number of points -- that is, I can get a nice looking curve with a high number of points while the contour lines remain nicely defined and not too overly crowded. With "style=surfacewireframe" increasing the numpoints parameter also increases the number of 'wires' that define the shape of the curve. I was wondering if there was a setting to control the 'wire density' independent of the numpoints parameter. That is, I would like a nice, highly defined plot (by using a high 'numpoint' value), with a 'wire' definition AS IF I was using 'numpoint=50'. (To make it behave like "style=surfacecontour" does.) Here's an example: If I plot a sphere without defining its resolution: > implicitplot3d(1 = x^2+y^2+z^2, x = -2 .. 2, y = -2 .. 2, z = -2 .. 2, style = surfacewireframe); I get a dull-looking sphere with jagged edges. Thus, if I want a nicely rounded sphere, I might use: >implicitplot3d(1 = x^2+y^2+z^2, x = -2 .. 2, y = -2 .. 2, z = -2 .. 2, style = surfacewireframe, numpoints = 100000) Now my sphere looks much better -- but the 'wire' pattern looks dense. If I switch the style to "surfacecontour" then it looks great. But sometimes I want the lines to go in both directions as "style=surfacewireframe" does, but without the 'dense' or 'heavy wire look'. Anyways, I was merely wondering if there was such a setting. For me "style=surfacecontour" does the trick mostly. Thanks for your reply. :o)

Hello David, Yes, I tend to use mostly "style=surfacecontour" because the contour lines are independent of the number of points -- that is, I can get a nice looking curve with a high number of points while the contour lines remain nicely defined and not too overly crowded. With "style=surfacewireframe" increasing the numpoints parameter also increases the number of 'wires' that define the shape of the curve. I was wondering if there was a setting to control the 'wire density' independent of the numpoints parameter. That is, I would like a nice, highly defined plot (by using a high 'numpoint' value), with a 'wire' definition AS IF I was using 'numpoint=50'. (To make it behave like "style=surfacecontour" does.) Here's an example: If I plot a sphere without defining its resolution: > implicitplot3d(1 = x^2+y^2+z^2, x = -2 .. 2, y = -2 .. 2, z = -2 .. 2, style = surfacewireframe); I get a dull-looking sphere with jagged edges. Thus, if I want a nicely rounded sphere, I might use: >implicitplot3d(1 = x^2+y^2+z^2, x = -2 .. 2, y = -2 .. 2, z = -2 .. 2, style = surfacewireframe, numpoints = 100000) Now my sphere looks much better -- but the 'wire' pattern looks dense. If I switch the style to "surfacecontour" then it looks great. But sometimes I want the lines to go in both directions as "style=surfacewireframe" does, but without the 'dense' or 'heavy wire look'. Anyways, I was merely wondering if there was such a setting. For me "style=surfacecontour" does the trick mostly. Thanks for your reply. :o)

Hello acer, thanks for your input. Yes, even though I've solved my problem I was still wondering if there was a 'workaround' to using subscripted function names without having them to reference a table. Really, when writing in the language of mathematics we tend to subscript our functions (or variable names) -- after all there are only so many letters in the alphabet so subscripts are a very convenient necessity in my humble opinion. I agree that a global setting to enable or disable this 'behavior' would be beneficial. It would also help for me to learn the ins and outs of maple of course since I'm still a rookie and learning my way around it, so I suppose 'noobie mistake' also has to do with it. :o) It's a nice program though. Thanks for sharing your workaround.

Hello acer, thanks for your input. Yes, even though I've solved my problem I was still wondering if there was a 'workaround' to using subscripted function names without having them to reference a table. Really, when writing in the language of mathematics we tend to subscript our functions (or variable names) -- after all there are only so many letters in the alphabet so subscripts are a very convenient necessity in my humble opinion. I agree that a global setting to enable or disable this 'behavior' would be beneficial. It would also help for me to learn the ins and outs of maple of course since I'm still a rookie and learning my way around it, so I suppose 'noobie mistake' also has to do with it. :o) It's a nice program though. Thanks for sharing your workaround.

My friend you were right. I solved my problem, which had to do with the usage of subscripts. Instead of writing r_1:=.... (a.k.a, r sub 1), writing r1:=... (no subscript) solved my problem. I no longer get 'table' errors. Clearly subscripts have a special function that I have yet to learn and understand -- in either case, I fixed my worksheet -- and I no longer have any errors, nor have maple suffer from memory loss... lol. Thanks for your help! - Jose -

My friend you were right. I solved my problem, which had to do with the usage of subscripts. Instead of writing r_1:=.... (a.k.a, r sub 1), writing r1:=... (no subscript) solved my problem. I no longer get 'table' errors. Clearly subscripts have a special function that I have yet to learn and understand -- in either case, I fixed my worksheet -- and I no longer have any errors, nor have maple suffer from memory loss... lol. Thanks for your help! - Jose -

It's not showing up on my previous post for some reason, but in the last line I was expecting the result to be [cos(4), 8, sin(4)]. Finally, r1 and r2, the 1 and 2 are supposed to be subscripts, that is r sub 1 and r sub 2 -- just in case you're wondering about syntax.

It's not showing up on my previous post for some reason, but in the last line I was expecting the result to be [cos(4), 8, sin(4)]. Finally, r1 and r2, the 1 and 2 are supposed to be subscripts, that is r sub 1 and r sub 2 -- just in case you're wondering about syntax.

You might be right -- I haven't verified it yet, but I will try. Here's a simple example I just tried where I got similar errors and it might be related to what you just said: restart; r:=t->[cos(t^2), t^3, sin(t^2)]; t->[cos(t^2), t^3, sin(t^2)] (1) r1:=t+2; t+2 (2) r2:=t+4; t+4 (3) r(2); table([1=t+2, 2=t+4])(2) (4) <---- this the error, I was expecting [cos(4), 8, sin(4)]. In the example above, r1 and r2, the numbers are written as 'subscripts' -- as in r sub 1, and r sub 2, etc.