How to specify +/- in a function definition.

[webmasterpdx]

E.g. To plot a circle, you'd want to specify y=+/- sqrt(r^2 - x^2).
Normally a circle equation is specified as x^2+y^2=r^2, but the various apps insist we specify the functions as a function of x or y=f(x).

The same is in graph3d, where a sphere is x^2+y^2+z^2=r^2.
Again, specifying z=f(x,y) = +/- sqrt(r^2-(x^2+y^2))

In CAS, is there a way to specify a function as being plus or minus something as above?
Here I'm thinking from an analytical point of view, how does one specify +/- some function.

From an app plotting perspective, one thing I tried in function is to plot 2 functions, this time in graph3d, to plot a sphere:

F1 = sqrt(16-(x^2+y^2)) ............r = 4, r^2 = 16

F2 = -sqrt(16-(x^2+y^2))

Thus by plotting both functions, you should get the full function drawn.
From an analytical perspective, you could do the same thing perhaps, by specifying a vector of 2 elements representing both + and - the function respectively....as in [+f,-f].

Now, the problem I have with plotting both with graph3d is due to rounding errors you'll get jagged spaces around the midpoint of the sphere (the plane that splits it from +Z to -Z).

Is there a way to specify the sphere to do this right.
Note that at the moment I'm using the beta graph3d system software....but I'm sure the same problem exists in the public app.

I can't show this problem in the 2D case as the circle only has 2 points at the split point....since it's only a circle.

Here is a screenshot to show what I mean...

   

[AlexFekken]

In 2D you can define curves implictly (i.e. as f(X,Y) = 0) with the "Advanced Graphing" app (and parametrised ones, i.e. X=f(T) and Y=g(T), with "Parametric").

And yes, it would be nice if the (or an) upcoming firmware update would support these options in 3D for surfaces as well. But I can see why that would be more complicated to implement.

Your proposed +/- functionality would only deal with much more limited scenarios.

[Wes Loewer]

(11-10-2017 06:57 AM)webmasterpdx Wrote:  F1 = sqrt(16-(x^2+y^2)) ............r = 4, r^2 = 16
F2 = -sqrt(16-(x^2+y^2))

This isn't exactly what you wanted with +/-, but using

FZ2=-FZ1(X,Y)

helps a little.

[webmasterpdx]

Look at the example plot I showed. Specifying FZ2=-FZ1(X,Y) makes no difference in that.

i.e. How do I plot x^2+y^2+z^2=r^2 ???........a sphere????
....without all the jaggies....

[AlexFekken]

Since the problem is apparently caused by the domain of the functions ending abruptly, you can (arguably) get a "better" graph by extending the domain, e.g. making the functions zero where they are now not defined:

FZn= sqrt(max(0,16-X^2-Y^2)) // (sorry about the edits)

Increasing the grid size will also give a somewhat better picture (with or without domain extension) but unfortunately it is limited to 100x100. Now *that* limitation should be easy to change by the developers.

[webmasterpdx]

That does make it look better, but it's not really plotting a sphere there. I think the problem is actually a bug. The plot should be flush with the plane z=0. It's not just rounding error, as if I plot sqrt(100-(x^2+y^2)), the blank areas are higher than 1 off the plane. That looks like a bug.

[AlexFekken]

Since we are hacking, here is more "refined" domain extension:

FZn = IFTE(16-X^2-Y^2 >= -3, SQRT(MAX(0,16-X^2-Y^2)), SQRT(-1))

[AlexFekken]

(11-11-2017 12:15 PM)webmasterpdx Wrote:  I think the problem is actually a bug.

I don't think so: I think it just means that the chosen algorithm is based on a fixed X-Y grid (as seems to be clear from the settings and the graphs themselves). So it does not work well where functions aren't smooth.

A "solution" would probably be to make the grid "adaptive" (to the singular behaviour), as we are used to in the function plots, but that would probably have a siginificant impact on the complexity, execution time and memory usage for the hidden line removal...

[webmasterpdx]

When i use the max function it really slows it down. However, I still think it's a bug. If you plot it with 100 instead of 16 (radius of 10) you'll see gaps up around z=4 or 5....
I'm SURE it's the algorithm, but my point is it's not a good algorithm. Interestingly when I plot it in wolfram-alpha, they do get it right, but you can see the jaggie areas in a slightly different shade, as if it originally plotted it the way mine is, and they filled in the gaps....maybe using max automatically or something.

[AlexFekken]

(11-11-2017 01:22 PM)webmasterpdx Wrote:  I'm SURE it's the algorithm

I agree that it seems to be a limitation of the algorithm. That doesn't mean it's a bug.

[Wes Loewer]

(11-11-2017 11:25 AM)webmasterpdx Wrote:  Look at the example plot I showed. Specifying FZ2=-FZ1(X,Y) makes no difference in that.

Sorry, I just meant that this notation makes it easier to simulate +/-, not that the graph would be any different.

The graph issue is simply a result of using a fixed increment. The jagged edges are expected for such a method. This is essentially the 3d equivalent of using the Function App to plot F1(X)=sqrt(20-X^2) and F2(X)=-F1(X) with Method=Fixed-Step Segments". Unless the window settings are set just right, the two halves don't meet.

I suspect the algorithm was selected as a balance of speed and accuracy (and simplicity).

Just think, some day we'll have real-time hi-res ray tracing (on a "display" implanted in our brains, no doubt). :-)