feature: multiple x axis to combine different time precisions
See original GitHub issueassume we have multiple time series with different time precisions / resolutions / divisions: some series are value per year, others are value per month, others are value per week
currently we must preprocess our data to match the highest value frequency (here: value per week) and repeat values with lower frequencies (annual data: same value for all 52 weeks) (please tell me im wrong …)
here is a plot of annual and monthly values:
![](https://user-images.githubusercontent.com/12958815/102510944-7e157f00-4088-11eb-9c4e-4f981862ae7b.png)
what is ugly here are the circles in the white annual line - they are too many
disabling the circles completely is a bad solution
possible workarounds: use nulls/gaps to encode missing values show only every N-th circle (others?) … but these still require to merge x values into one axis
possible solution:
currently, data[0]
holds the x values, and all other data[i]
hold y values
we could introduce a mapping between arrays, mapping x values to y values
or more general, map input values to output values
the default mapping would be
datamap: [
[0, 1], // f(d0) -> d1
[0, 2], // f(d0) -> d2
[0, 3], // f(d0) -> d3
[0, 4], // f(d0) -> d4
// ....
]
to combine annual and weekly x values, we could then use
datamap: [
[0, 1], // f(d0) -> d1
[2, 3], // f(d2) -> d3
]
or plot functions with multiple inputs
datamap: [
[0, 1, 2], // f(d0, d1) -> d2
[3, 4], // f(d3) -> d4
]
or we extend opt.series[i]
like
series: [
{
label: "T year",
axis: 0, // x axis
},
{
label: "T month",
axis: 0, // x axis
},
{
label: "N year",
axis: 1, // y axis
input: 0,
// this is an output/value series
// with series 0 (T year) as single input/key
},
{
label: "N month",
axis: 1, // y axis
input: 1,
// this is an output/value series
// with series 1 (T month) as single input/key
},
]
in the future we might need 3D plotting and MISO functions (multi input, single output) (not sure if MIMO makes much sense)
@leeoniya please share your thoughts so i can make a better PR : )
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (4 by maintainers)
you’re welcome to help. but, yes, i think it will be very substantial as the underlying data format assumptions permeate many parts of the internals. it’s not gonna be as simple as tweaking just the pathbuilder, for example. the probability of not breaking many things to get this done is basically zero, imo.
the ultimate question is, what gains do you expect in non-artificial cases, and can you prove that this will work robustly and generally. if someone tells me that they need better perf on a 10M pts scatter dataset, the simple answer is that this is not the right library to use - at some point, this just becomes true. so, it’s important to evaluate real use-cases, costs and possible gains from this effort.
this is an arbitrary number. is that 500 datapoints? 500 * 52 datapoints? 500 * 365 * 24 * 3600 datapoints? as i said, i would be interested to see how
uPlot.join()
performs on your dataset, and its details.scatter/bubble is much easier (not easy) to solve with a different underlying data structure (as described there), which is the plan. if you’d like to help with that, i think it will be a much better use of time 😃 i don’t plan to work on that for a few more months due to other work, so cannot promise a timely PR review either, unfortunately.
gonna close this since i don’t think there is anything actionable here. feel free to follow up in this thread if you have perf issues with a specific use-case/dataset.