Opened 5 years ago

Closed 5 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) 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 5 years ago by chapoton

  • Branch set to u/chapoton/17928
  • Cc vbraun novoselt jkeitel added
  • Commit set to e1ec050f70db144c0c988b61a8ebca85e5fe8deb
  • Status changed from new to needs_review

New commits:

​e1ec050trac #17928 opposite (negative) of cones and fans

comment:2 Changed 5 years ago by novoselt

  • Status changed from needs_review to needs_work

That would be nice, but:

  1. The cone negation method is in a wrong class and constructs a wrong object.
  2. 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 and Fan 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 5 years ago by git

  • Commit changed from e1ec050f70db144c0c988b61a8ebca85e5fe8deb to c8ab1f52df108a01440e5340baa83a9c4a818f5b

Branch pushed to git repo; I updated commit sha1. New commits:

​c8ab1f5trac #17928 neg of cone in correct class

comment:4 Changed 5 years ago by chapoton

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 5 years ago by git

  • Commit changed from c8ab1f52df108a01440e5340baa83a9c4a818f5b to bdf048609e0f1ac50905a9f7b512a5b8bab7b753

Branch pushed to git repo; I updated commit sha1. New commits:

​bdf0486trac #17928 setting rays immutable

comment:6 Changed 5 years ago by chapoton

  • Status changed from needs_work to needs_review

ok, this should be correct now, maybe ?

comment:7 Changed 5 years ago by novoselt

  • 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 5 years ago by chapoton

common refinement is now #17938

comment:9 Changed 5 years ago by vbraun

  • Branch changed from u/chapoton/17928 to bdf048609e0f1ac50905a9f7b512a5b8bab7b753
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.