order remains the same in rearranged list

nidzela shared this problem 9 years ago
Answered

i think this is a bug: trying to prepare an ordered table of values of a function and its derivatives, i found that the original order within the list of points i created remained unaltered although rearranging it afterwards by hand.


operating system: MS Windows XP

Java version: jre1.6.0_22 (i guess... it is the newest reference in the Java folder)

steps of how to reproduce the bug:

  • 1. create several points.

    2. use ALT+left click to select them and create a list in the input bar.

    (press enter to confirm the list)

    3. try to redefine the list, including new points or exchanging the order of the ones originally in it.

    (the values in the list seem to be the ones in the first definition, not the latest!!)


observe that the formula in the spreadsheet x(Element[llista1, 3]) returns x-coordinate of the old 3rd point in the list, B, instead of the actual and expected value x(D).

maybe it is relevant that my points were created by sets: firstly, solutions of f(x)=0 (=> A, B, C); then Extremes[f] (=> D, E, F); finally Extremes[f'(x)].

weird: can't these points be used separatedly??


see image and attached ggb file.

https://ggbm.at/5523230e7412a7bd9e05cc3b8f7b95744e46a6

Comments (5)

photo
1

Java version: jre1.6.0_22 (i guess... it is the newest reference in the Java folder)
Latest is jre1.6.0_29

photo
1

Hi Nidzela,


in many cases it is not possible to decide what is the order of elements A,B, if e.g. A,B are intersections of two circles (sorting them by x will make them "jump" when one circle is moved). Therefore we always add al siblings of an element to a list, so these are equivalent: {A}, {B}, {B,A}, {A,B}. For roots / extremums the order could be defined, but we probably won't make an exception.

photo
1

Java version: jre1.6.0_22 (i guess... it is the newest reference in the Java folder)
Latest is jre1.6.0_29


...i meant: "in my Java folder" :-)

i'll check for the new release, anyway.

photo
1

Hi Nidzela,


in many cases it is not possible to decide what is the order of elements A,B, if e.g. A,B are intersections of two circles (sorting them by x will make them "jump" when one circle is moved). Therefore we always add al siblings of an element to a list, so these are equivalent: {A}, {B}, {B,A}, {A,B}. For roots / extremums the order could be defined, but we probably won't make an exception.


hi, kondr!

i'm not sure i've understood your explanation completely... i don't catch the word "siblings".


but i think i understand the idea: my points should have been defined one by one, in order that inner relationship doesn't affect list sorting... here's my new job on it, and it works: i created A'=A and so on, just for those points automatically generated by conditions/intersections (roots and extremums).


applying the method described in the first message i could manage to get the desired (and sorted) list of points. thanks!

https://ggbm.at/552329

photo
1

Hi,


ad siblings: the construction can be viewed as a directed graph (not exactly a tree) with algorithms and elements as nodes and edges from parent to child (if you type C=Midpoint[A,B] the graph will be a tree, algorithm Midpoint being parent of C, points A,B being parents of algorithm Midpoint). Algorithms with multiple outputs (Root, Intersect, Vertex, ...) have multiple children and the relation between children of the same parent can be described as "siblings".


And your workaround is nice.

© 2021 International GeoGebra Institute