Changes between Version 3 and Version 4 of Ticket #29581, comment 53


Ignore:
Timestamp:
08/25/21 07:41:00 (3 months ago)
Author:
gh-mjungmath
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #29581, comment 53

    v3 v4  
    11Thank you Travis for your comments. My original idea was to inherit from `DeRhamCohomologyClass`. Because both classes have the `representative` method in common, which is crucial to perform operations such as additions and cup-products. My "dream" would be that an element of `CharacteristicCohomologyClassRing` can be seen as member of `DeRhamCohomologyRing`, and whenever `representative` is invoked (even after coercions), you can still choose a connection.
    22
    3 One way to achieve this could be to allow `_representative` to refer to a method. But I suppose this is rather spurious for the user?
     3One way to achieve this could be to allow the attribute `_representative` in `DeRhamCohomologyClass` to refer to a method. But I suppose this is rather spurious for the user?
    44
    55Alternatively, if we drop my "dream" and still allow coercion: we can modify `DeRhamCohomologyClass` in such a way that we can give it a name and allow to leave the `_representative` attribute empty. Similar to scalar fields whose expressions are not set yet. Afterwards, the representative can be set dynamically, and we can make the instance immutable if desired.