Opened 7 years ago
Closed 7 years ago
#17928 closed enhancement (fixed)
opposite of cones and fans
Reported by: | chapoton | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | sage-6.6 |
Component: | geometry | Keywords: | cone, fan, negative |
Cc: | vbraun, novoselt, jkeitel | Merged in: | |
Authors: | Frédéric Chapoton | Reviewers: | Andrey Novoseltsev |
Report Upstream: | N/A | Work issues: | |
Branch: | bdf0486 (Commits, GitHub, GitLab) | Commit: | bdf048609e0f1ac50905a9f7b512a5b8bab7b753 |
Dependencies: | Stopgaps: |
Description
it would be useful to be able to write -C and -F for the cone obtained by negating the rays of a cone, and same for a fan.
Change History (9)
comment:1 Changed 7 years ago by
- Branch set to u/chapoton/17928
- Cc vbraun novoselt jkeitel added
- Commit set to e1ec050f70db144c0c988b61a8ebca85e5fe8deb
- Status changed from new to needs_review
comment:2 Changed 7 years ago by
- Status changed from needs_review to needs_work
That would be nice, but:
- The cone negation method is in a wrong class and constructs a wrong object.
- The cone and fan actual classes are very picky about the input - rays have to be immutable, as described in the documentation. Either run a loop to make them immutable or use
Cone
andFan
constructors that take care of it,check=False
would make sense, of course. (It may also make sense to always set immutability in point collections instead of trying to be super efficient, but that's for another ticket and would require some manual work to eliminate current cycles.)
comment:3 Changed 7 years ago by
- Commit changed from e1ec050f70db144c0c988b61a8ebca85e5fe8deb to c8ab1f52df108a01440e5340baa83a9c4a818f5b
Branch pushed to git repo; I updated commit sha1. New commits:
c8ab1f5 | trac #17928 neg of cone in correct class
|
comment:4 Changed 7 years ago by
Thanks for your quick reaction.
I think I have taken care of point 1.
Concerning point 2, I am not sure to see the point. It seems that the current code does work. Could you give me a case where the opposite fan or cone (as build now) misbehaves ?
By the way, I would love to have a method to obtain the common refinment of two fans. Do you see an easy way to do that using existing code ?
comment:5 Changed 7 years ago by
- Commit changed from c8ab1f52df108a01440e5340baa83a9c4a818f5b to bdf048609e0f1ac50905a9f7b512a5b8bab7b753
Branch pushed to git repo; I updated commit sha1. New commits:
bdf0486 | trac #17928 setting rays immutable
|
comment:6 Changed 7 years ago by
- Status changed from needs_work to needs_review
ok, this should be correct now, maybe ?
comment:7 Changed 7 years ago by
- Reviewers set to Andrey Novoseltsev
- Status changed from needs_review to positive_review
Looks good now.
For fan refinement: assuming they have the same support, you can map fan1
to fan2
by the identity map and allow domain subdivision. Then the domain fan3
of the resulting FanMorphism
will be the minimal subdivision. It may be nice to implement a method fan1.common_refinement(fan2)
returning such a fan after constructing an opposite morphism as well (this will ensure common support, I am not sure how to check it otherwise except for the case of complete fans which should be handled separately for efficiency).
comment:8 Changed 7 years ago by
common refinement is now #17938
comment:9 Changed 7 years ago by
- Branch changed from u/chapoton/17928 to bdf048609e0f1ac50905a9f7b512a5b8bab7b753
- Resolution set to fixed
- Status changed from positive_review to closed
New commits:
trac #17928 opposite (negative) of cones and fans