[rkward-devel] plot history featrues
Thomas Friedrichsmeier
thomas.friedrichsmeier at ruhr-uni-bochum.de
Tue Sep 7 09:54:04 UTC 2010
On Tuesday 07 September 2010, Thomas Friedrichsmeier wrote:
> The idea to use a hash is certainly appealing, but I'm also reluctant to
> add new hard dependencies. Using an optional dependency, sounds like
> adding a lot of complexity, though. Qt also supports MD5 and SHA1, so
> perhaps it's not too much trouble to cook a basic digest ourselves,
> instead. I'm not sure, how much impact this would have on the
> implementation. If it's just a detail, I'd say it's for a later release.
> If it's a core aspect, I'd say use digest() for now, and I'll look into
> creating hash function based on Qt.
On second thought:
> plot (rnorm (10000))
> a <- recordPlot()
> b <- recordPlot ()
> system.time (for (i in 1:1000) digest (a))
user system elapsed
6.244 0.100 6.367
> system.time (for (i in 1:1000) identical (a, b))
user system elapsed
1.068 0.004 1.051
So, for the most common case, which is simply comparing the current plot
against the one that was previously saved at this position in history,
identical is six times faster than creating a hash.
For the use case of checking the entire history for duplicates, using a hash
would seem to be faster once more than six plots are involved, but:
- If two plots really *are* different, identical() is much faster, and in fact
it's typically close to instantaneous in this case. Thus, as long as there are
no, or only few duplicates, using identical() is still the faster option. And
we can safely assume few duplicates to be the more common case.
- Checking the entire history for duplicates may (or may not?) have additional
potential for confusion in some corner cases. It may well be a good idea, but
I'd advise against it for the moment. Let's try to keep things simple for now.
Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20100907/ac817ca0/attachment.sig>
More information about the Rkward-devel
mailing list