-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Order of options not respected #3
Comments
So the only way I can think of to resolve this is to specify options as a list, not a record. Something like this:
or perhaps this:
The name "options" is of course just an example, something else could be used. And of course we must keep accepting the current options! So what we'd do is, we'd first look at the
Perhaps |
Dear Max
So ... in 2016, I noticed the problem after it became a problem in 2012,
when GAP changed the behaviour of options
... and I left it broken for another 4 years. Wow.
I take it we will be fixing this after you do the ACE-5.3 release.
I think a lot of users must not care, or have worked around it.
It's possible some will have a legacy program using ACE that works;
so we need to make a change that will allow it to still work
... it seems you might already be suggesting this:
... leave 'options' as a record, and
explain that since 2008 the order of options is not respected
... have a new variable 'optionlist',
which is indeed a list, and encourage users to use that instead,
since it will respect the order of options,
if indeed they need that feature.
Again, I'd need to get my head back in the game.
Curtin has made me quite dull.
I haven't touched this stuff for at least 4 years.
Regards,
Greg
…________________________________
From: Max Horn <[email protected]>
Sent: 11 February 2020 22:02
To: gap-packages/ace <[email protected]>
Cc: Gregory Gamble <[email protected]>; Author <[email protected]>
Subject: Re: [gap-packages/ace] Order of options not respected (#3)
So the only way I can think of to resolve this is to specify options as a list, not a record. Something like this:
ACECosetTableFromGensAndRels(fgens, [], [] : options := [["max", 12], ["start"], ["print", -12], ["incomplete"]]);
or perhaps this:
ACECosetTableFromGensAndRels(fgens, [], [] : options := [["max", 12], "start", ["print", -12], "incomplete"]);
The name "options" is of course just an example, something else could be used.
And of course we must keep accepting the current options! So what we'd do is, we'd first look at the options option; if given, we use it first to set options. Then we iterate over all the other options given in "old-style" and append them. Then we could also do the following, which would be guaranteed to pass max before start.
ACECosetTableFromGensAndRels(fgens, [], [] : options := [["max", 12]], start, print := -12, incomplete);
Perhaps early_options or initial_options would be good alternative names for options?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#3?email_source=notifications&email_token=ABKQEEHOVRSVQDMSSE346GTRCKVWPA5CNFSM4B5TYEGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELMQMJA#issuecomment-584648228>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABKQEEFDSZF4JP5KG7VDYQ3RCKVWPANCNFSM4B5TYEGA>.
|
In Section 4.4, of the ACE manual, we state that due to the non-orthogonality of options it is important to preserve the order in which options are put to ACE. This was a working feature in 2008 with GAP 4.4.12,
but in 2012, with GAP 4.5.4 it was not. Generally, the order options are put to ACE makes little difference, but the example in Appendix C.1, extending to:
fails to work as shown in the manual without 'start' being put to the ACE binary after the 'max' option.
Omitting 'start' in the list of options restores the behaviour in the manual, since a feature of the GAP interface is that if 'start' is omitted it is inserted, and fortunately this happens after the 'max' option has been put to ACE.
The text was updated successfully, but these errors were encountered: