# visibility issues with lists containing direct "copies" of objects

artydent shared this problem 3 months ago
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).

1

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

1

I don't think it's a mixup problem, I only put extra points in to have more visual clues. Works the same with no extra points in the list.

```A = (1,1)
L_A = {A}```

-> The point in L_A isn't drawn.

```k = Slider(0, 1, 1)
B = (1,-1)
L_B = if(k≟0, {B}, {})```

-> After moving the slider, B is not drawn anymore, even when changing its value. Needs manually unchecking/re-checking in the options.

Interestingly - even though L_A and L_B contain a point - the options don't have a setting for the point size in this case. So type-wise they might internally not even be considered a "list of points".

1

strange workaround join(l_A,{})

1

OK, maybe that's a small bug. Is it actually stopping you doing something specific though?

1

Stopping, no. I can easily work around that. It's just a weird behaviour and not obvious at all. I had encountered such "vanishing display" issues in a rather complex setting, and it took me quite some time to figure out what the cause of the problem was.

1

Oh, I never noticed that sentence. Thanks for pointing that out.

It's very unfortunate though. It makes lists practically unusable for objects whose types are re-interpreted by GeoGebra based on their value. In particular, it breaks my standard approach for handling certain user input. It always worked so far, but I have to change it if that behaviour is not guaranteed. I am just not yet sure how to change that without significantly giving up on flexibility and/or code readability/maintainablity, except maybe with extensive use of scripting.

Hm...or is there a way to force Geogebra to interpret something as a specific type (and just treat it as Undefined if such an interpretation fails)?

I actually even encountered something weird, where in one version of my file an object's type would keep flipping between "Line" and "Implicit Function" (depending on the value of another object it depended on), but in another version of the same file the same object would always keep the type "Line" with just an "Undefined" value when it couldn't be a line, and I have no idea how I may have tricked GeoGebra into doing that. Maybe I can do that deliberately?

PS: I just noticed your edit of the "{A,B,C} or {(1,2),(3,4),(5,6)}" post. So I assume that this kind of "mixing" is actually not a problem. That's really a relief, I was almost ready to give up on lists completely.

1

`is there a way to force Geogebra to interpret something as a specific type`
Yes, link the object to a symbolic Input Box then it will preserve its type (or become undefined)

1

Good to know. Thanks.

I'll test this out.

PS: I have no idea why my last post appeared up here, I am sure I had it as a reply to your comment at the bottom.

1

This advice must be written in help of list

1

I think the advice is wrong

2

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

1

I remember the discussion in the forum at that time because I found it somewhat irritating even then.

On this subject, I found something in my fundus in april 2012.

1

¡Ocho años!!!!!

¡Cómo pasa el tiempo!!

https://help.geogebra.org/t...

1

thanks, LOL

1

@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.

1. When defining a list via "{<Element>,...,<Element>}", which ways of representing an <Element>, e.g.

• literals (e.g. "(1,1)" as a point literal)
• names of already defined objects (e.g. "A")
• expressions containing object names, but not just an object name itself (e.g. "A*1")

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)?

2. If yes, is "mixing" only a problem upon list creation or are the resulting lists from different non-mixing definitions still of inherently "different type" and incompatible for certain list operations?
3. If still yes, how can I find what kind of hidden subtype a list has or whether two lists are compatible?

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

```A = (1,1)
B = (2,2)
L_1 = {(1,1), (2,2)}
L_2 = {A, B}
L_3 = {A*1, B*1}
L_4 = {(1,1), B}
L_5 = {(1,1), B*1}
L_6 = {A, B*1}
L_7 = Sequence((k, k), k, 1, 2)
```

I'd say >99% of users would assume that

• at the moment after the definition, the all six lists L_1, ..., L6 are of the same type ("list of points") and have the same content
• as long as the values of A, B, C don't change - operating with any of the lists would produce the same outcome

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.

1
• This command only works, if the list or matrix contains elements of one object type (e. g. only numbers or only points).