Hi, On Wed, Jun 30, 2010 at 12:25 PM, Prasenjit Kapat <kap...@gmail.com> wrote: > Hi, > > On Wed, Jun 30, 2010 at 6:20 AM, Thomas Friedrichsmeier > <thomas.friedrichsme...@ruhr-uni-bochum.de> wrote: >> Hi, >> >> On Wednesday 30 June 2010, Prasenjit Kapat wrote: >>> 1. Limit on L, no limit on either S or s -- naive >>> 2. Limit on L and s which in turn limits S as well -- better than 1 >>> but the user may not have a clear idea of how large s can be? 1 KB? 5 >>> KB? 30 KB? >>> 3. Limit on L and S -- can be easily superseded by just limiting on S. >>> 4. Limit on S -- seems reasonable >>> 5. Limit on S and s = p * S where p = (say) 0.6 -- more reasonable. >> >> I'm somewhat undecided between 2 and 5. 5 is most elegant, technically, but 2 >> may be slightly easier usability-wise. I think it depends on what we believe >> how what would be sensible values for L, s and S. For L, I believe the ~5-10 >> most recent plots are the most interesting by far, but we could assume 20 to >> be on the safe side. >> Regarding s, the object.size() of plot(rnorm(100000)) is around 1.6MB, here. >> So, if we set s to 2MB, that should support pretty much any plot in practice. >> Multiplying that in solution 2 would yield 40MB. That *is* pretty large. On >> the other hand, S would _typcially_ be much smaller in solution 2, and on >> systems where 40MB are a serious issue, RKWard may not be a good choice in >> the >> first place. >> In solution 5, memory-usage would always approach S after extended usage, so >> it may be reasonable to set S somewhat lower, perhaps at 10MB. >> >> How large is a "typical" plot? My guess is 50KB. That would mean 200 plots >> can >> be stored in 10MB for solution 5. For solution 2 that means the typical >> memory >> use for the plot history is 1MB. >> >> Hm, ok, after writing this down, I think I'm inclined towards solution 2. > > Thanks for the numbers! If no one has any objection, then I shall > implement 2 shortly.
I've implemented the limits as discussed above. Two things came up: 1. s = 50 KB seems small even for a pie (...) plot! Which was a surprise, but it validated the code implementation. Let's stick with 50 KB as the default for now. Once this feature is field-tested by others, if needed, we can change it easily. 2. What to do when the max history length (or size) is reduced from the settings, while there is an existing history? What I mean to say is this: suppose L = 10 is set in the settings. Let H = length of the current recorded history. Suppose H = 8. Now suppose the user decides to reduce L to 5 in the settings. So, there are 3 extra plots in the history. Two ways out: 2a. Do nothing (which is the status quo). In this case, there is a warning displayed in R (not in KDE) and no new plot is added the history. 2b. Pop out the first 3 plots, so that H = 5 and then any new plot can be added the usual way (pop the first and push the last) Do you think 2b is a better solution than 2a? Opinions? I (think, I) have all the necessary code in place to implement 2b, so it should be relatively easy. There is a similar situation if 's' is reduced below max (all individual recorded plot sizes). So, popping plots out of history in this case would almost reduce to the case 5 above; which I'm not too comfortable with it. In any case, it would be nice to show a KMessageBox warning (instead of / along with, the warning in R) from KDE in both these situations. This would require R to send the value to H back to C++ whenever the length of history changes - which is already being by updateDeviceHistory. Can it be accessed from the rksettingsmoduleouput? Since updateDeviceHistory has no information on the 'size,' it may be better to create a separate rk.do.call () with history_length and max_existing_size as the two arguments and connect it to rksettingsmoduleoutput. Or may be there is a simpler/better way... Regards, -- Prasenjit PS: @Stefan, I haven gotten around to your JSS email yet. Will do so soon. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
