A list of multiple intersections, question and bugs(?)

dqnykamp shared this question 7 years ago
Answered

Given a function f(x), if I type


Intersect[f,xAxis]


multiple points are created at each of the zeros of f, i.e., points were f(x)=0. If I then change f to change the number of zeros, then more points are automatically created if needed, or some points go undefined. All well and good, but I do not understand how this works in order to use this to generate lines at the zeros. If there was a way to generate a list of all the intersection points, then I could manipulate the list to create other objects from it.


For the attached construction, the zeros of f represent equilibria of a differential equation. The function f is plotted in the Graphics window and a plot of the solution versus time is in the Graphics 2 window. I want to plot horizontal lines in Graphics 2 at the level of the equilibria. I have developed a way that works that I'm happy enough with, but another (seemingly better) way that I thought should work have failed. I'm not sure why.


My first attempt to get a list of zeros was to create a sequence


Sequence[Intersect[f,xAxis,i],i,1,10]


to find the first 10 intersections. I assumed that might result in undefined points, but I could just use RemoveUndefined to get rid of them. However, entering this command results in it getting changed to


Sequence[Intersect[f, xAxis, 1], i, 1, 10]


i.e., it now is a sequence of just the first intersection repeated over and over. It seems like a bug to me. But, maybe there some reason for this behavior?


The solution that I did get to work was


Sequence[Intersect[f, xAxis, (xx, 0)], xx, xmin, xmax, (xmax - xmin) / 50]


where xmin and xmax are set to be the limits of the x-axis. I don't have a problem with this solution (other than the below bug), as I don't expect students to enter functions where this will miss equilibria. But, since it seems like a bit of a kludge, I was wondering if there was a better way to do it.


I've also run into one other bug that shows up with this method. If I start with the equilibria (i.e., these intersections) hidden, checking the button in an embedded applet to reveal the equilibria does not reveal them. The equilibria don't show up until one makes changes to the function f. I created a workaround by putting


SetValue(f,f)


as the On Update script for the Boolean showing/hiding the equilibria. But that's pretty stilly to have to put that in there.

https://ggbm.at/558899

Comments (2)

photo
1

Hi, first, try :

    {Intersect[f,xAxis]}

or for a polynom :

    {Root[f]}

https://ggbm.at/558907

photo
1

Beautiful. This is much more elegant. I never would have thought of doing {Intersect[f,xAxis]}, but now that you mention this, it makes perfect sense.


Now, there is only one case handled by my ugly method that doesn't work with your nice method. If I let, for example, f(x)=sin(x), then clearly having a list of the infinite number of zeros doesn't make sense. However, I'm puzzled why neither of these modifications work.


I created a segment

    h=Segment[(xmin,0),(xmax,0)]

and tried the intersection

    {Intersect[f,h]}


I also created the function

    g=Function[f,xmin,xmax]

and tried the intersections

    {Intersect[g,xAxis]}


Both of these cases still give undefined lists for f(x)=sin(x).


I can't figure out how to work around this limitation in Geogebra. Geogebra's handling of this situation is a bit odd and leads to strange behavior. It still has the same problem if I change the segment to

    h=Segment[(0,-5),(1,-5)]

Even though these is only one intersection with sin(x), it can't find it. It finds the intersection between h and f(x)=sin(x) only if the segment is perfectly vertical.


All this behavior described is what happens if I first define these intersections and then afterwards change f(x) to sin(x). If after setting f(x)=sin(x), I change the definition of any object (it doesn't have to be related to these intersections), then Geogebra changes the definitions of the intersections to be nearby some point and finds one intersection for each of these cases. Strange behavior, in my thinking. I'd think of it as a bug, but maybe there is some rationale behind it. (I can imagine the intersection code has to handle a myriad of cases, and maybe this makes sense in some case.)


Looks like I should learn this Zip function you used in your example. It looks handy.


Thanks,

Duane

© 2020 International GeoGebra Institute