Opened 13 years ago
Closed 13 years ago
#1064 closed defect (fixed)
[with patch] applying permutation is coded in a way that behaves badly when input isn't an "expected type"
Reported by: | was | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | sage-2.9.1 |
Component: | basic arithmetic | Keywords: | |
Cc: | Merged in: | ||
Authors: | Reviewers: | ||
Report Upstream: | Work issues: | ||
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
19:00 < wstein> that permuation application code in #750 is (and has always been) lame. 19:00 < wstein> watch: 19:00 < wstein> g = PermutationGroup(['(1,2,3)(4,5)']).gen(0) 19:00 < wstein> g(x) 19:00 < wstein> Get a big traceback from Gap. 19:00 < wstein> It would be trivial to code things to give a much more sensible error. 19:01 < wstein> This isn't a criticism of #750; just that looking at #750 immediately 19:01 < wstein> makes me see that there are bad features to the code. 19:02 < wstein> Even worse: 19:02 < wstein> sage: g(3/2) 19:02 < wstein> 1 19:02 < wstein> That makes no sense! }}] The problem is this line of code in sage/groups/perm_gps/permgroup_element.py: {{{ return int(gap.eval('%s^%s'%(i, self._gap_().name()))) }}} Instead that should be {{{ return int(gap.eval('%s^%s'%(Integer(i), self._gap_().name()))) }}} since then we'll get a sensible error message if i doesn't have a natural interpretation as an integer. Of course, one must import Integer. I'm not attaching a patch, since ticket #750 and a text patch would be too confusing to apply.
Attachments (1)
Change History (6)
comment:1 Changed 13 years ago by
- Summary changed from applying permutation is coded in a way that behaves badly when input isn't an "expected type" to [with proposed patch] applying permutation is coded in a way that behaves badly when input isn't an "expected type"
comment:2 Changed 13 years ago by
- Milestone changed from sage-2.10.1 to sage-2.9
comment:3 Changed 13 years ago by
Changed 13 years ago by
comment:4 Changed 13 years ago by
- Summary changed from [with proposed patch] applying permutation is coded in a way that behaves badly when input isn't an "expected type" to [with patch] applying permutation is coded in a way that behaves badly when input isn't an "expected type"
comment:5 Changed 13 years ago by
- Resolution set to fixed
- Status changed from new to closed
Merged in 2.9.1 alpha2
Note: See
TracTickets for help on using
tickets.
Now the stupid traceback is different, but equally stupid. Amusingly:
Now we're starting to make some sense!?