"Create (new) Groups"

[AcroDirki]

Hi guys!

During a training week we propsed 21 figures for 3 Unknowns, containing 3 different stall turns, 3 dfferent tailsides and 4 rolling circles. They were proposed in their families one after the other. When the "create groups" button was clicked, it was noted that the overall order of the 21 figures was shifted, but the sequential / suborder of figures was maintained, concluding such that all 4 rolling circles had to be flown in a single unknown, resp. all stallturns / tailslides in a unknown. This didn't change with multiple executions of "create new groups". Hence, the algorithm is not truly random. It needs to be improved, either by a constraint, spreading the figures of family 2, 5 & 6 as well as spins and flicks over all unknowns or by true random function and multiple execution (which is may be the easier but not the better solution).

The algorithm, however, should be explained in more detail in the manual to make it transparent.

It would be appreciated very much, if this could be implemented before July (german glider nationals) as a final test before the world championship.

Kind regards, D.

[OpenAero]

As the manual indicates the algorithm creates groups that have the best possible match in speed/attitude. It certainly is not random! Creating random groups would give a higher chance of impossible combinations, exactly what this algorithm wants to prevent. Forcing the spread of families 2, 5 & 6 could be fairly easily implemented. Do you consider this to be the best solution?

[AcroDirki]

Well, this solution is a first attempt, which sounds convenient. 2, 5, 6 the spins and the flicks should be distributed to ensure a certain versatility in every unknown. As I described above, a single unknown that contains 4 different rolling circles would not be appreciated by the competitors / judges etc, while in all other unknowns a rolling circle is missing. However, there should be a certain random component in the creation of groups, which is finally constrained by the sequence feasibility (not more than 2 additionals needed; Total K in the limits), in order not to establish any kind of selection preference in terms of speed (i.e. when the first unknown contains low speed entries/exits only, resp. as a majority due to any algorithm, as some competing aircrafts are more or less convenient for them). It's about the neutrality of figure selection for the unknowns, keeping in mind that not in every championship all unknowns are flown pending on weather conditions...

[OpenAero]

After a complete rewrite of the routine, there is now a new algorithm available on https://openaero.net/devel . Please test thoroughly with as many combinations as possible!

It works as follows: 1) Label every figure with a Superfamily number (as in old Free sequences) which marks it as spin, flick, turn, hammerhead, tailslide or other 2) Randomize figure order, but subsequently sort by Superfamily 3) Figure by figure, assign to one of the proposals. Take into account distribution of Superfamilies and best fit with existing proposal figure speeds

However, because of the nature of this method of figure selection, it can not be guaranteed that there exists a solution that also accounts for a maximum of 2 additionals in each group and total K in limits. In these cases it is up to the jury to find the best solution.

[AcroDirki]

Hi guys,

a check using https://openaero.net/devel was attempted using the following string on a Win10 PC and google chrome Version 66.0.3359.181:

1j1 1jo1 1jo5- -1j5 1j5- h4 -h h- -h- q2- ta4 -ta ,4ta- -ta- -ita id2f- 2ft 2fa1 bf of -d2if -2if 1m2if pb2if o2if- ivs sirp2 sirp- -is -isirp2 1c2 -pb -k 2t- -1a2-

The following points were observed:

1. The grid info box still behaves "wild". I can´t click the "create group"-button as the box is still moving more or less with the mouse movement. As soon the mouse hovers onto the box, the box moves accordingly.
2. The rule implementation on the maximum number of certain figures (fam 2, 5, 6, 9.9, 9.10, 9.11&12) works correctly in my eyes.
3. Wrong alerts were indicated on "of" and "o2if" that the selected base figures would not be allowed.
4. As the grid info box was effectively still inaccessible, the number of figures per grid-line could not be chosen to 7, which seems most convenient for the figure proposal.
5. Probably due to 4 a saved png-file or pdf does not contain all figures. Obviously there is no auto-fit-function (working).
6. Due to only 4 allowed base figures for a stall-turn not more than 4 could be choosen without another, correct error message on repitition of a base-figure.

As I hence couldn´t verify the above implementation, I can give so far just another suggestion to the quote:

However, because of the nature of this method of figure selection, it can not be guaranteed that there exists a solution that also accounts for a maximum of 2 additionals in each group and total K in limits.

The "best fit with existing proposal figure speeds" is rather a soft than a hard requirement, as long as the attitudes are matching. Is it possible to maintain a solution complying with 2 additionals in each group and total K in limit by releasing the soft requirement of "best speed fit"?

A further proposal to the algorithm:

I´m well aware to avoid more constraints than really necessary on the randomized selection. However, in order to aid to the feasibility, I think it could make sense to spread the mentioned figures of fam 2, 5 and 6 such that per programme their combination does not require already a linking figure, i.e. 1j1 ta- -h in programme 1, 1j5- -ta h- in programme 2 and so on. I assume that such an implementation requires to define reasonable "logical preferences" and is anyway a logical challenge as it must also be considered, that the entire figure pool may contain less than the maximum numbers of these figures.

However, I want to thank very much the devel-team, esp. Ringo, for every single effort, taken here.

Kind regards, D.

Ammendment:

Using the Touchscreen-Function of my PC, I was finally able to adjust the number of figures per line in the grid view and to create the groups with the following result:

The first impression is that it worked well. The mentioned families are spread as intended. Unknown1 figures' choice seems feasible. However, from a more detailed view on the second line (Free Unknown) it turns out the figure choice is not feasible to fly, as there are 4 negative high speed exits, but just 1 negative lowspeed entry. => at least 3 linking figures required, as sequence may not finish in inverted attitude. Figure choice for line 3 (Unknown 2) seems likewise unfeasible: 2 Negative High speed entries, 1 negative low speed entry, but no negative exits at all. Here it is obvious that, if 1 or 2 figures between line 2 and 3 are exchanged, then both programms are feasible in terms of entry/exits. Lines 4 and 5 look less critical than 2 & 3 in terms of entry/exit attitudes, but are probably still hard to compose - need most probably minimum 2 if not 3 linking figures, as this can be judged by a quick review.

It would be a "nice to have", if the total K of every line would be summed in order to assist a manual feasibility check. Line 1, Free Unknown: 172 K => OK, acc. to SC6pII 2.3.3 b) Line 2, Unknown1: 151 K +2 add. to 175-190 K => OK Line 3: Unknown2: 156 K Line 4: Unknown3: 157 K Line 5: Unknown4: 156 K

[OpenAero]

Thanks for the testing.

Regarding point 1), I tried this on a Windows 10 laptop with chrome 66 and 67. Both worked correctly. So I cannot reproduce. I will try to find out what may cause this for you but maybe there is some unusual setting on your PC?

Regarding the combinations of the amendment. Does a new run provide better combinations? By definition, as these rules are so convoluted and plainly awkward I think creating a "perfect" algorithm would be very time consuming. It seems always a new issue pops up regarding the feasibility of groups. Therefore I regard this algorithm to be sufficient, with the responsibility for final group creation resting with the jury.

I will look at items 3) and 5) and the possibility of adding "Total K per group" to the group creation dialog.

[OpenAero]

Thinking about 1) some more: so your desktop has both a mouse and a touch screen? That may be where the problem originates.

[OpenAero]

Please check if the latest version on openaero.net/devel solves the "wild" grid info issue. I have made an update that works well on touch and regular devices but do not have the combination.

[AcroDirki]

Hi Ringo,

The "wild" grid box seems to be successfully catched :) in the actual devel-version. I can´t move it at all now, but this doesn´t really disturb me as I still can hide it, if necessary.

Yes, I´ve got an Lenove AIO MZ910 which I can operate by Mouse and Keyboard as well as through the touchscreen. Honestly I´m quite new to Win10, so I have no conclusion, whether I have set a "strange" option somewhere. It´s most probably the default option, then.

The implementation in the grid box to sort the figures looks very convenient and works well.

Kind regards, D.

[OpenAero]

Hi Dirk,

I had to make some more changes to the Grid Info box because of other issues. Can you confirm that the "wild" box issue has not returned when using openaero.net/devel on your Lenovo?

Regards, Ringo

Op vr 22 jun. 2018 om 12:35 schreef AcroDirki notifications@github.com:

Hi Ringo,

The "wild" grid box seems to be successfully catched :) in the actual devel-version. I can´t move it at all now, but this doesn´t really disturb me as I still can hide it, if necessary.

Yes, I´ve got an Lenove AIO MZ910 which I can operate by Mouse and Keyboard as well as through the touchscreen. Honestly I´m quite new to Win10, so I have no conclusion, whether I have set a "strange" option somewhere. It´s most probably the default option, then.

The implementation in the grid box to sort the figures looks very convenient and works well.

Kind regards, D.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OpenAero/main/issues/220#issuecomment-399400027, or mute the thread https://github.com/notifications/unsubscribe-auth/AK7VoSnaw7No-ovsYpT8hrQ2LEp18q1zks5t_Mh7gaJpZM4UBL2s .

[OpenAero]

Completed. No recent developments.