-
Notifications
You must be signed in to change notification settings - Fork 81
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
Reimplement *_satisfying in a more generic fashion #51
Comments
Oh, another idea: if a point in the line, plane, or space were represented by a single grouped entity rather than the separated Cartesian coordinates. |
I'm sorry I missed your idea. The reason why columns of p correspond to points is mostly historical but also in assembly we require efficient slicing of all x-coordinates, all y-coordinates, etc. Default memory ordering of NumPy makes the current approach more efficient in terms of processor-level caching. NumPy supports changing this but I haven't seen a reason to rewrite everything. |
Oh, no, I didn't mean columns as opposed to rows. (I agree with that choice, by the way.) I just meant that a point might be passed as a single argument rather than `dim` arguments, one per coordinate. As far as that goes it could be a tuple, list, ndarray, dict, object, whatever, but `ndarray` is probably best.
A point (say the i-th) is naturally obtained from a `skfem.Mesh`, however, as `mesh.p[:, i]`, the i-th column of `mesh.p`, which is an `ndarray` of shape `(dim,)`. Isn't that the form that the points will be in already when they're passed to the lambda function? (I didn't check, I just assumed that they'd be sliced out of `mesh.p`.)
Envoyé depuis ProtonMail mobile
…-------- Message d'origine --------
On 20 sept. 2018 à 19:31, Tom Gustafsson a écrit :
I'm sorry I missed your idea. The reason why columns of p correspond to points is mostly historical but also in assembly we require efficient slicing of all x-coordinates. Default memory ordering of NumPy makes this more efficient in terms of caching.
—
You are receiving this because you commented.
Reply to this email directly, [view it on GitHub](#51 (comment)), or [mute the thread](https://github.com/notifications/unsubscribe-auth/ABg-0yov5vT-BBnJ3IbKfYEPIdctvITQks5uc2BxgaJpZM4Wwmet).
|
This would also be consistent with how it's done in the bilinear and linear forms. It's a good idea but requires some rewriting of examples and tests and other code. Mesh.submesh must be modified accordingly. |
The methods named:
could be implemented in a generic fashion for both 2D and 3D meshes and moved to Mesh superclass. They already look very similar: the tuple unpack notation via * could be used to make the implementation equivalent.
The text was updated successfully, but these errors were encountered: