-
Notifications
You must be signed in to change notification settings - Fork 57
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
very minor change for clarity (and possibly minor efficiency)
- Loading branch information
Showing
1 changed file
with
1 addition
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
b1f001d
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.
i left it in there for clarity!
i wasn't sure about the efficiency?
How is the -ve of a fn evaluated under the hood?
b1f001d
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.
i actually don't think it'll make a difference efficiency wise, as i believe the -ve is evaluated implicitly as was originally written here!
if you prefer, feel free to revert.
b1f001d
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.
Maybe this would be better being changed in the definition of this term under the hood.
b1f001d
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.
For reference here is the where the -ve comes from. See the [M] part. It's from Hughes 2nd edition
I like the assembly term interface as it stands because it's reusable - we use it for the MeshVariable_Projection sle.... pretty cool.