-
-
Notifications
You must be signed in to change notification settings - Fork 402
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
Dimension preferences #843
Comments
Sounds good! Deciding what to do with existing preferences like soft_range is also important, as a a balance between compatibility and clean semantics. |
Here is one syntax for this I think might be quite nice:
|
Would the prefs object accept any Parameterized, or only the one sample one that we define (with soft_range, default, etc. already enumerated as Parameters)? |
Of course, we also need to be careful around the issue of compatibility. Here is what we could do:
I suppose we would need a bit of compatibility for pickling once these parameters are moved to live on the preferences object. |
@jbednar Good question! Maybe we could offer a way of using a preferences object we can understand (with things we define such as |
Thanks for the summary. Several things to note, first of I'm wondering about the other parameters, like
This does not match the current semantics of range and soft_range.
Yes, storing other metadata on them makes sense, although perhaps calling it |
Thanks for clarifying! The key thing is that we agree that I suspect |
I'll have to clarify again, when I said This means |
Thanks for the clarification. To update the bullet point lists above:
I agree we are very flexible with how |
As part of 1.7 we will add the preferences to Dimension, and as part of 2.0 we will move existing parameters to the preferences. |
After starting a PR and discussing this issue in detail with Philipp (again!) we came up with a different approach. This is a proposal we are both happy and it requires fewer changes while doing away with an explicit concept of dimension preferences:
Instead of introducing preferences, the idea is that dimension objects are almost entirely preferences which means almost everything in a dimension can be ignored when comparing them. The key new insight is that what defines a dimension can't be some optional argument, or in other words, 'core' metadata must be whatever is passed as the first (mandatory) positional argument. Currently there are two things you can put into this mandatory position, a string (the name) or a tuple (the name and label): a = hv.Dimension('a')
b = hv.Dimension(('b', 'description of the b dimension')) This means the current rules for equality (defining the semantics) should be:
Matching on both name and label should always work between two dimension objects as the label will match the name by default (i.e if it isn't explicitly set via the tuple). UnitsWe have long wondered whether units are part of the semantics of a dimension or not. I believe we have finally figured this out:
For instance, a dimension expressed in Kelvin is equal to a dimension expressed in Celsius (given the name and labels are also equal) as both express temperature. A dimension expressed in meters isn't equal to one expressed in Celsius as these are different types of unit. The conversion methods of the rich unit objects of the dimensions will be used to determine whether the conversions are valid. Rules defining Dimension parametersIn short, the first argument to Unpacking the implications of this rule:
I'll now be working on a PR (or two!) to implement the following:
I realize this comment has grown quite long but it is worth laying things out clearly and explicitly so we can think through the consequences of this plan. This issue has generated a lot of discussion over a number of years and I think we can finally put it to rest! |
Good summary and the to-do list looks correct to me, might just want to add:
|
Looks good; glad to see this heading toward resolution.
By adding units as a third item in a tuple? Seems a bit clunky, but does seem like it forces the user to know that this is part of the definition of that dimension. Seems like it ought to be possible for users to add units later, but I'm not certain what I mean by "later". People definitely add units later in wallclock time (after an initial implementation), but maybe they can be considered to add them at the logical start, not logically after initial creation; not sure.
I'm not sure I agree with that;
I vote for |
After further discussion with @jbednar I think we finally have something all three of us are happy with!
Supporting New rule
hv.Image(..., vdims=[('z', 'Z-score')]) Whatever parameters can be set in this type of tuple format must be core semantic information - by design, these tuples are designed to specify only the most important information to avoid building a dimension object explicitly.
Advantages
Dimension(('z', 'Z-score'), label='Something else') Consequences
I'm hoping that this is the final proposal that is satisfactory to @jlstevens, @philippjfr and @jbednar! Edit: One more TODO item:
|
Sounds perfect; thanks for writing that up. |
I think this issue has finally been addressed in the PR referenced above (merged). Glad to finally close this issue! |
Reopening, I strongly disagree with the decisions we made here. I'd prefer not to open this can of worms again but here we are, should at least discuss it for 2.0. |
Since the very beginning of the project, there has been some tension as to what
Dimension
objects are for. There have been two major pressures:Dimension
is the obvious place to put that. Other things related to usability aresoft_range
and the formatters.This situation has made things difficult as
Dimension
is a core component of HoloViews that we want to keep as simple as possible on one hand while also wanting to support new features on the other. Things are further complicated by questions as to whether two dimension objects are 'equal' and therefore interchangeable.After discussing this problem with @philippjfr and @jbednar, I think we've found a good compromise based on this insight: some of what
Dimension
contains is indeed core metadata about the data and the rest of the options are aimed at usability that are issues of preference (which can be subjective).The core metadata should be a small list of things that define the most important information about the dimension and the preferences can be a much larger, open-ended set of options aimed at usability. For this reason, we should group these two types of metadata separately.
name
,unit
,range
(often constrained by the unit definition, e.g (0, 360) for angle in degrees and (0, None) for a temperature in Kelvin).soft_range
(the typical useful range as determined by the domain or user preference),default_key
and the various formatters.Based on this, the proposal is that
Dimension
has only the core metadata as its own parameters as well as apreference
parameter that holds an object containing all the preferences. This makes it clear as to what the most important information is regarding a dimension while allowing flexibility in terms of the various preferences.We still need to discuss the exact form this preference object takes and we should think of finding a syntactically convenient way of defining them.
The text was updated successfully, but these errors were encountered: