Combinatorial implementation of the affine symmetric group

[dec4a3e9-7377-4ea4-ae7b-b43807ab08bd]

This is a combinatorial implementation of the affine symmetric group, providing a second implementation of the WeylGroup(['A',k,1]), but quite a bit faster. Also included are combinatorial implmenetations of affine types B,C,D and G. Extension to types E and F should be possible.

Apply:

• attachment: trac_12940_affine_permutations-td.patch

Depends on #14673 Depends on #8392

CC: @nthiery @anneschilling @sagetrac-chrisjamesberg

Component: combinatorics

Keywords: affine, days38, days49

Author: Tom Denton

Reviewer: Chris Berg, Anne Schilling

Merged: sage-5.11.rc0

Issue created by migration from https://trac.sagemath.org/ticket/12940

[jdemeyer]

comment:45

Read this sentence again: I think of assertion failures as serious as a crash due to a Segmentation Fault: it is always a bug in the program if one occurs.

[jdemeyer]

comment:46

Please don't use ClonableArray as an example, it shouldn't be using assertions that way.

[jdemeyer]

comment:47

One more way to think of assertions: they express "I know this condition is true", not "I want to check that this condition is true".

[anneschilling]

comment:48

Hi Jeroen,

Thank you for your comments! The asserts in the check methods of ClonableArrays/Lists seem to be in a grey area, since they are used for both the user input check as well as internal checks. Is assert ok here? If not, I would strongly suggest to change the documentation of ClonableArray to show how things are supposed to be used!

Thank you,

Anne

Replying to @jdemeyer:

One more way to think of assertions: they express "I know this condition is true", not "I want to check that this condition is true".

[dec4a3e9-7377-4ea4-ae7b-b43807ab08bd]

comment:49

If this is the accepted usage of asserts vs ValueErrors in Sage, they should be written up as such in the developer's guide; there wasn't any way for me to know this was the local convention. Additionally, a bug+patch should be made for the Cloneable Array class.

The line between internal assumptions and user input becomes very thin in Sage, and this is an example of a very close case. The idea of the Cloneable Array is that it's a simple data type with some extra assumptions. When making a new one of these objects, you might break those assumptions temporarily, but should end up with something that satisfies the assumptions, and the 'check' methods are intended to check that your methods have actually made this transformation effectively. This is a machine use of the check method, but - as you say - the check method also works well to check user input. After all, user input IS code in Sage! It's not a bug in my code if buggy input fails to run. It's a very, very different situation from taking user input from, say, a web form and getting an Assertion Error. Users can run arbitrary code, so if you want to avoid assertion errors at all cost, it should simply be completely off-limits to use assert statements at all. I have, as a user, definitely used statements like X._test_whatever(), which, as you say, are fine to have assert statements.

In short, if an assertion error happens in my code, yes, it's a bug in the program. If one happens due to code that's been supplied by the user, it's a bug in the user's input.

The only reason I can actually get behind to switch to ValueErrors is that it's possible to turn off assertion errors at the Python level. But this doesn't seem to be why you think they're as bad as segmentation faults....

In any case, I've refactored the code, and am attaching a new version of the patch.

[jdemeyer]

comment:50

Replying to @sdenton4:

If this is the accepted usage of asserts vs ValueErrors in Sage, they should be written up as such in the developer's guide; there wasn't any way for me to know this was the local convention.

It's not a local convention, it is a general convention independent of Sage or Python. I think you will find that http://en.wikipedia.org/wiki/Assertion_(software_development)#Comparison_with_error_handling mostly agrees with me.

After all, user input IS code in Sage!

I don't understand what you mean with this.

It's a very, very different situation from taking user input from, say, a web form and getting an Assertion Error.

Why? What makes calling AffinePermutationGroup() so different from filling in a web form?

I have, as a user, definitely used statements like X._test_whatever(), which, as you say, are fine to have assert statements.

Underscored methods are supposed to be private, so you're expected to know what you're doing. Everything I said applies to using public, documented functions. Of course, everything can happen if you mess with internal data structures.

It's not a bug in my code if buggy input fails to run.

That's perhaps a matter of opinion. Would you find it a bug in the rm command if it crashed with a Segmentation Fault if the file could not be found? Would you find it a bug in your web browser if it crashed every time you fill in a non-existing URL?

[jdemeyer]

comment:51

Perhaps this should be a NotImplementedError:

raise ValueError('Cartan type provided is not implemented as an affine permutation group.')

[dec4a3e9-7377-4ea4-ae7b-b43807ab08bd]

comment:52

Switched to NotImplementedError in the indicated place. Can this finally get out the door now?

[dec4a3e9-7377-4ea4-ae7b-b43807ab08bd]

Patch file.

[anneschilling]

comment:53

Attachment: trac_12940_affine_permutations-td.patch.gz

[jdemeyer]

Merged: sage-5.11.rc0