-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Multi-axis-type sploms #2899
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
Merged
Merged
Multi-axis-type sploms #2899
Changes from 1 commit
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
dd563bb
consider only splom dimensions on axis during axis autotype
etpinard 9e1869d
copy back axes categories on axes that skipped makeCalcdata,
etpinard 9da5a1b
add splom mutli axis type mock
etpinard f3c73db
swap (x|y)a -> (x|y)id for clarity
etpinard b3d27bd
skip dims with conflicting axis types
etpinard 9039a8e
keep track of visible dimensions using visibleDims list
etpinard ab7d9c6
bring handleTypeDefaults api on-par
etpinard 39b71bb
add dimensions[i].axis.type
etpinard 57ddadb
pass gd to basePlotModule.updateFx
etpinard 15efc72
clear additional 'matrixTrace' use by regl-splom for selection
etpinard 1823904
log info when skipping splom dim of conflicting axis types
etpinard 390f292
add mock of splom with conflicting axis types
etpinard adb0004
use 'j' in value loop
etpinard File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
How could you get here? if
xa
exists you'll skip theelse if(ya)
block entirely.But this raises an interesting (if possibly nonsensical) point - what if
xa.type !== ya.type
? I guess this could happen if one is numeric or date and the other is categorical, or if one is linear and the other is log. If the answer is "all hell breaks loose", which wouldn't surprise me, it may be appropriate to just log a warning and hide that dimension entirely. That seems like an abuse of the concept of a splom.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.
Good point. I wrote that up to preserve symmetry, but didn't bother checking. Thanks!
I don't think this can happen on graphs with only 1 splom trace and no
ax.type
set in the layout. That's because (after this PR's 1st commit dd563bb), both x and y axes use the same data array in the axis autotype routine.Scenarios where
xa.type !== ya.type
can happen if,gd.data
autotyped the axesax.type
in the layoutwhich are things that don't happen by accident.
So, I yeah I think skipping that dimension entirely makes the most sense here. Thanks for bringing this up!
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.
Hmm could happen in the editor though. @nicolaskruchten @VeraZab not sure how best to handle this. If we add
dimension.type
we should steer people there somehow when there's a splom on that axis. But if they still set an axis type directly would we want to find the corresponding opposite axis in the splom and set it to match, to avoid this error?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.
hoo boy. Well right now we don't support SPLOMs yet, and I'm thinking that when we do we should lock down axes/subplots quite tightly so that people can't break them too much :)
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.
Skipping dims with axes of conflicting types in b3d27bd