Closed GoogleCodeExporter closed 9 years ago
> The use case here is to represent data that changes through time, so C is
> Date, for example. I'm effectively storing key-value (R-V) pairs where the
> value depends on the time. I can't represent this as RowSortedTable<Date, K,
> V> because the values for all keys don't change at the same time.
I don't quite follow why changing some values separately would be a poor fit
for RowSortedTable<Date, K, V>.
Original comment by cpov...@google.com
on 3 Feb 2012 at 6:06
Because the rowMap for any given date would need to know about values from
other rows. I wasn't clear that I'm talking about a possibly sparse time
series: in the example each row corresponds to a changing series of values,
where the date specifies when the value becomes the 'active' one for that row.
There's not necessarily any expectation of uniformity of this scheduling - the
value for series A might change independently between consecutive changes of
the value of B.
Toy example: suppose I have time series like this in a RowSortedTable, with
times as the row keys, showing the last time we decided on our current
favourite fruits:
Time | A(time) | B(time)
1 | Apple | Banana
2 | Pear |
3 | Raspberry |
4 | Grape | Orange
so B's favourite fruit is the same from time 1 to time 3. Unless I store
mappings for every time value, there's no way to find out B's favourite
(Banana) at time 3, for example.
Whereas, if you represent this the other way around, with row sorted columns:
Time | 1 | 2 | 3 | 4 |
A(time) | Apple | Pear | Raspberry | Grape |
B(time) | Banana | | | Orange |
you can look up by row, then pick the floorKey(3) to get the most recent value.
Original comment by joe.j.kearney
on 3 Feb 2012 at 6:32
I'm going to say that this would be...nontrivial, implementation-wise, I'm
pretty sure. Making an API fit the Navigable spec is a lot of work, just
because it's so many methods.
I'd be willing to do it, but I just want to say that...
Original comment by wasserman.louis
on 3 Feb 2012 at 10:30
Original comment by wasserman.louis
on 5 Feb 2012 at 9:43
Is the plan to update the other bug to refer to TreeBasedTable as well as
TreeMultimap? The challenges for this one seem a bit steeper but I'm sure well
within your capabilities :)
Original comment by cpov...@google.com
on 5 Feb 2012 at 10:33
Oh dear. These are not actually duplicates, are they.
It's so easy to mix up Tables and Multimaps!
Original comment by wasserman.louis
on 5 Feb 2012 at 10:54
Original comment by fry@google.com
on 16 Feb 2012 at 7:18
Issue 905 has been merged into this issue.
Original comment by fry@google.com
on 13 Mar 2012 at 6:41
Original comment by kevinb@google.com
on 30 May 2012 at 7:43
Original comment by kevinb@google.com
on 22 Jun 2012 at 6:16
This issue has been migrated to GitHub.
It can be found at https://github.com/google/guava/issues/<id>
Original comment by cgdecker@google.com
on 1 Nov 2014 at 4:14
Original comment by cgdecker@google.com
on 1 Nov 2014 at 4:18
Original comment by cgdecker@google.com
on 3 Nov 2014 at 9:08
Original issue reported on code.google.com by
joe.j.kearney
on 3 Feb 2012 at 9:30