Order of eNames'

[NoahCardoso]

While working on changing eNames from Lists to Sets I found that the order of eNames' and meNames is important to stable. I don't think that this is necessary. I'm not quit sure how to interpret the log for eNames'. For the meNames log, it just looks like it's sorting them by name instead of order of appearance. I don't see any inherent reason to say that the new sorting style is bad "bad".
eNames'.txt
meNames.txt

[JacquesCarette]

Yes, the order does matter, in that the order must be fixed and can't be random and change from run to run. But the current order does not necessarily matter. This change may legitimately induce a lot of one-time changes to stable.

[balacij]

Exactly as @JacquesCarette explained, stable/ needs to indeed be the 'expectable' artifacts that we generate. However, that doesn't mean that they're permanently set in stone.

With the stable changes, it would be sorting them by UID, which we know is the wrong strategy long-term, but I think it's better to use a Set than a million nubs. Only small heuristics (e.g., group things related to each other next to each other, 'relative'-functions should have the 'relative' object as the first parameter) come to mind when talking about the order in which variables should be introduced, and I don't think they have anything to do with the alphabet nor order of appearance in complex expressions. That being said, if we have any doubts right now about the order, we can retain it using an ordered set, but I also think a normal set is fine. @JacquesCarette do you have any preference?

[JacquesCarette]

We should figure out a decent key (i.e. not UID) to sort these sets by. If we can't find one, we're probably setting ourselves up for later pain.

[NoahCardoso]

In projectile, when eNames' is switched to a set the order of the theta, v_lanch and g variables is changed in the generated code.

In dblpend, when eNames' is switched to a set the order of the theta, v_lanch and g variables is changed in the generated code.
In swhsnopcm, when eNames' is switched to a set the order of m_1, m_2, L_1 and L_2 are changed. The srs is unchanged.

in glassbr, the order of the LR and q variables is changed in the code but the srs is unchanged.

When meNames is a set only the order of things within the srs is affected not the generated code.

It seems that only the order of one set of variables is changed in each of the effected examples when eNames' is changed, but the srs is unaffected. Only the srs is effected when meNames is changed but the generated code is the same as it is not reported in logs.

[JacquesCarette]

We need to know:

1. what the sorting criterion was before,
2. what is the key now.

None of the changes above seem bad. Nevertheless, we should have an explanation for all of them, to make sure that it is a reasonable way to order things.

[NoahCardoso]

Currently eNames' doesn't explicitly sort the UIDs it collects them in the order they are encountered. Is it possible to use symbols as the key rather than UIDs? I am not sure what else we could use as a key other than UIDs and sets.

[balacij]

Ok, I think we have a starting point from the meeting (i.e., proceeding with sorting by symbol). Do you have any leftover questions, @NoahCardoso ? Can we close the issue?

[smiths]

@NoahCardoso as we discussed, please put a comment in the code that sorting by symbol might not be the ideal solution.

[NoahCardoso]

Yes this issue can be closed and I will indicate in the code that this is a temporary fix, not the final solution