Opened 11 years ago

Closed 11 years ago

#12017 closed enhancement (invalid)

Adds CoerceKey

Reported by: roed Owned by: robertwb
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: coercion Keywords:
Cc: robertwb Merged in:
Authors: Reviewers: David Roe
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description

Many parents in Sage are supposed to be unique, such as GF(5). But we'd like to be able to make copies of GF(5) sometimes, for example when we want to consider the residue field of a number field at a completely split prime above 5. The main difference between these copies of GF(5) is that they have different coercion data. This patch adds a feature to sage.structure.factory that allows one to do this more simply than creating a whole new class for residue fields.

Attachments (1)

coerce_key.patch (17.4 KB) - added by roed 11 years ago.

Download all attachments as: .zip

Change History (8)

Changed 11 years ago by roed

comment:1 Changed 11 years ago by roed

This patch is still in progress, but I'd like to get feedback on the general approach and the changes to factory and parent. In particular, I'm not very happy with the changes to comparison in parent, but I'm trying to satisfy the following goals

  • Check for type equality and coerce keys in Parent so that implementers of new parents can just write one function that ignores coerce keys and can assume that its inputs are the same type. Maybe one should be allowed to be a subtype of the other instead?
  • Not have to immediately change all of the __cmp__ functions on parents throughout Sage (see #10130 for what happens when you try to do this).
  • Keep comparison equally fast or faster for parents that don't yet facilitate coerce keys. In particular I'd like to avoid adding a bunch of Python function calls.

I'd also like to incorporate some of the improvements from #10130 since I need some of them.

Feedback is welcome.

comment:2 Changed 11 years ago by robertwb

I have to admit that this seems much more complicated than "simply than creating a whole new class for residue fields." In the particular case of residue fields, it seems that creating a new Parent would be desirable (e.g. it could print better and know where it came from); are there other usecases where such re-use would make more sense?

If it is not easy to simply extend the Parent and re-use most of its methods/elements, that should be fixed.

comment:3 Changed 11 years ago by roed

After trying to get this approach to work a bit more, I agree with you. There are some changes that need to be made to Parent to make things like residue fields easier to create, but I'll address them in another ticket.

Thanks for the feedback.

comment:4 Changed 11 years ago by roed

  • Milestone changed from sage-4.8 to sage-duplicate/invalid/wontfix

comment:5 Changed 11 years ago by roed

  • Status changed from new to needs_review

comment:6 Changed 11 years ago by roed

  • Status changed from needs_review to positive_review

Note that this should be closed as invalid, not merged.

comment:7 Changed 11 years ago by jdemeyer

  • Authors David Roe deleted
  • Resolution set to invalid
  • Reviewers set to David Roe
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.