-
Notifications
You must be signed in to change notification settings - Fork 191
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
Behavior of data
is inconsistent with behavior of Base.parent
#454
Comments
Hmmm, yeah I agree it would be good to be consistent with I guess these aren't user-facing functions so they don't super memorable names. I like defining I don't know if it makes sense to define |
Note that |
Just to be clear, the point of doing this is because you want to use dispatch to write flexible array operations that are agnostic to whether the array is a 'raw' array (like an |
Julia's
Base.parent(a)
has the behavior that it returns eithera.parent
where applicable, or justa
in the case thata
is an unwrapped array.Our
data(f::Field)
function has a different behavior: whilef
does have a fielddata
, the functiondata(f)
actually returns aview
intodata
at interior grid points, rather thandata
itself.It might be a good idea to make the behavior of
data
consistent with that ofBase.parent
. One way to do this is to change the definition ofdata
toTo capture the existing functionality of
data
, we might define a new function (perhapsinteriordata
? that returns a view over 'interior' points:The terminology is not perfect because of our convention for fields stored on faces (we store these fields asymmetrically: one boundary would be included in 'interior', but the other is not). However, this problem also plagues the current definition of
data
(and our notion ofField
in general).We can then also rename
parentdata(f)
tointeriorparent(f)
, which returns a reference to the interior points off.data.parent
.The text was updated successfully, but these errors were encountered: