-
Notifications
You must be signed in to change notification settings - Fork 7
finat_element.is_lagrange #200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: release
Are you sure you want to change the base?
Conversation
| '''Appropriate mapping from the reference cell to a physical cell for | ||
| all basis functions of the finite element.''' | ||
|
|
||
| def is_lagrange(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Is
is_lagrangea good name? Maybehas_only_point_evaluation_dofs? (or something in between) - Should this be a
cached_property?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rckirby what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
KMV and Crouzeix-Raviart have only point wise evaluation dofs but aren't "Lagrange". If we want this function to return True on those, we should change the name. Connor's proposed name is verbose, but I can't think of a shorter one.
a cached_property seems reasonable, but would we break consistency with other such queries internally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is more pythonic to use properties for this sort of thing. For example UFL is trying to move away from argument-less methods (like the recent .topological_dimension() to .topological_dimension.
c44a163 to
4072e63
Compare
No description provided.