visibility issues with lists containing direct "copies" of objects
New
Suppose you define the following
A = (1,1) L_A = {A, (3,2)}
Result: Regardless of whether A is drawn somewhere, drawing L_A results only in the point (3,2) being drawn.
Maybe that's the deliberately designed behaviour for some reason, but it feels like a bug.
Some remarks:
- This only happens for such a "direct copy" of A. Defining L_A as "L_A={A+(0,0), (3,2)}" would circumvent that problem.
- Doesn't matter how many other elements (other than A) the list has or whether A appears more than once.
- It's not specific to lists of points, can be lists of any objects.
Here's another, more problematic behaviour which is likely related.
Define
k = Slider(0, 1, 1) B = (1,-1) L2 = if(k≟0, {B, (2,-1)}, {})
and then move the slider to 1.
Result: B is not drawn anymore. Now you can even change B to any other point and/or move the slider as you want, B will not be redrawn. Seems that the only way to have B drawn again is to go to its object properties and uncheck and re-check the checkbox for the drawing location.
- Before the slider was moved, drawing L_B also omitted drawing B, same as with A and L_A before.
- Seems like when the list changes for k≟1, GeoGebra decides that B (as not part of the list anymore) doesn't need to be drawn anymore.
- Interestingly, this problem doesn't manifest for "C = (-1,-1)" and "L_C = if(k≟0, {C, (-2,-1)}, {(-2,-2)})". Even before the slider is moved, it doesn't behave like L_B, i.e., both points of L_C are drawn).
Files:
VisibilityIssue.ggb
Try and keep lists consistent, either {A,B,C} or {(1,2),(3,4),(5,6)}
Do you have a good reason to mix them up?
Edit: sorry, ignore that
This advice must be written in help of list
De acuerdo
Creo recordar que hubo una época, hace un par de años, en que la visualización de puntos y conjuntos de puntos era doble y para evitar esto se hizo que los puntos y conjuntos de puntos dejaran de ser visibles simultáneamente, de forma que si un punto se ocultaba entonces el conjunto de puntos se ocultaba o algo parecido. Puede que esto sea un efecto secundario de aquellos intentos de hacer compatible la visualización de objetos y listas de esos objetos al mismo tiempo
@Michael I would like a bit of clarification about lists. I considered lists to be powerful tools, but your sentence "Try and keep lists consistent, either {A,B,C} or {(1,2),(3,4),(5,6)}" kinda makes me lose a lot of confidence in them.
Even though Geogebra seemingly allows lists of all kinds of objects, it has become clear that certain list operations are only guaranteed to work properly when the objects in the lists are "of the same type" (even the elements are in principle compatible), although it is becoming increasingly unclear what "of the same type" actually means.
Mostly, list operations seem to work fine when all elements are of the same type (in the sense of what a user might intuitively consider the same type), but I am starting to wonder how much of that is just happenstance (in that the current implemention happens to work the way we expect in most cases) but is far from guaranteed because the result actually depends strongly on some miniscule details that a user has amost no chance of knowing.
So I am gonna try to formulate some questions, hoping that the answers shed some light onto this.
When defining a list via "{<Element>,...,<Element>}", which ways of representing an <Element>, e.g.
are considered to be "of different type" (in terms of what kind of list is created), even if - from a user perspective - they all have the same type, e.g. "point"?
If there are such different "types", does mixing those "types" produce "bad" lists (and operations on such a list might produce wrong results)?
Or is there a standard way to make them (more) compatible? (Always assuming that the elements are compatible in principle, e.g. the lists contain only points.)
To give an example, consider the following
I'd say >99% of users would assume that
But maybe that's not the case. Your earlier remark suggests that L_1 and L_2 are "good" (maybe still inherently different types of list, but operations on them would produce the same outcome), but that the "mixed" L_4 is "bad" (and operations on L_4 might produce wrong results).
And based on the different visibilty behaviour discussed in this thread, it also seems that L_2 and L_3 are inherently different, which suggests that the "mixed" L_6 might also be "bad".
Not 100% sure about L_1 vs. L_3, but they might also be inherently different and L_5 might be "bad".
And what about L_7, is L_7 the same as L_1 or is there another difference?
And are L_1 and L_2 be compatible to be joined for example, i.e., can I safely use "Join(L_1, L_2)" or "Join({L_1, L_2})" or does that produce a "bad" list?
More generally, are there list operations that a guaranteed to be safe, even if the list contains elements of different types? (and here I even consider really different types)
I am assuming that at least "Length(<List>)" is safe, and I am hoping that "Element(<List>, <Position>)" is safe (as long as I don't do inappropriate stuff with the result), so we can use lists as variable length storage even if GeoGebra might consider some elements to be of a different type.
Comments have been locked on this page!