GSoC project "Visualization of STLContainers as SVG" - setting options using << or .axis_color(red).title_font(14)...
1 It seems nice to be able to create a one-stop visualisation of a container, for example: std::vector<double> my_data_structure; // fill with my data... my-graph << my_data_structure; // But should the myriad of graph plotting *options* be set using operator << allowing them to be chained together thus my_graph << line_color(black) << point_color(blue) << x_range(-10, 10) << y_range(0, 5)...; as suggested by John Maddock (who has a most irritating habit of being right ;-) or more conventional setter member functions my_graph.line_color(black); my_graph.point_color(blue); my_graph.x_range(-10, 10); my_graph.y_range(0, 5); and could getter versions return their current values if (my_graph.line_color() == black) .... possibly chained (return this) to reduce typing? http://www.parashift.com/c++-faq-lite/references.html#faq-8.4 my_graph.line_color(black).point_color(blue).x_range(-10, 10).y_range(0, 5); 2 How can a set of plot settings be 'saved' for repeated use? Once one has chosen a plot style, line_color black, point_color blue ..., one wants to save this for re-use (though things like the range may change). 3 Does anyone have experience with auto-axis scaling algorithms. The best reference I have found is Michael Bramley, C/C++ Users journal, www.cuj.com July 2000, pp 20 - 26 But this does not always give the nicest scales - it would work nicely using decimal, but the damned binary FP *wrong* bits at the end screw up the comparisons. (Excel plots show this behaviour). Suggestions? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
On May 23, 2007, at 10:03 AM, Paul A Bristow wrote:
1 It seems nice to be able to create a one-stop visualisation of a container, for example:
std::vector<double> my_data_structure; // fill with my data...
my-graph << my_data_structure; //
But should the myriad of graph plotting *options* be set using operator <<
allowing them to be chained together thus
my_graph << line_color(black) << point_color(blue) << x_range(-10, 10) << y_range(0, 5)...;
as suggested by John Maddock (who has a most irritating habit of being right ;-)
I'd be for this approach. Later you may want to have option containers and the options set explicitely override the corresponding ones in the container. You can further evolve the container into a full-blown cascading stylesheet management. [this maybe what property tree is for, I haven't looked into it yet] By choosing this route you can progress incrementally and add functionality as you go (either as part of the SoC project or later). Regards, Maurizio
On 5/23/07, Maurizio Vitale <maurizio.vitale@polymath-solutions.com> wrote:
I'd be for this approach. Later you may want to have option containers and the options set explicitely override the corresponding ones in the container. You can further evolve the container into a full-blown cascading stylesheet management. [this maybe what property tree is for, I haven't looked into it yet]
By choosing this route you can progress incrementally and add functionality as you go (either as part of the SoC project or later).
The incremental way is what my project is going to thrive on. There are so many small features that can be added.. Paul's given me a few dozen easily, and it's probably the tip of the iceberg! I'm going to be spending a lot of time up front getting the architecture correct for improvement so that I can spend a good chunk of the project adding on features that myself and others would like to see. As for properties, I really haven't given it a whole lot of thought. I already can see that fine-tuning a graph the way you'd like it to look takes a lot of effort, and there's no sense doing it over and over, but I don't have a good way right now. Suggestions?
my_graph.line_color(black).point_color(blue).x_range(-10, 10).y_range(0, 5);
Overall, I'm not against letting users use method calls to set parameters of classes.. sometimes, that's what they're there for. However, I don't feel that this is an alternative that is intuitive to users. When a user normally does chaining, like my_vector[0].to_string().find(...), they aren't expecting my_vector[0] to be affected. However, show a beginner the longest cout statement you can think of with as much chaining as you want and they'll understand that it all affects the printout, even if they don't know what a stream is! I feel that the stream operator chaining can immediately be grasped by beginners, as they know that since it looks like cout and file streams, it must affect a file somehow.
2 How can a set of plot settings be 'saved' for repeated use? Once one has chosen a plot style, line_color black, point_color blue ..., one wants to save this for re-use (though things like the range may change).
To be determined later :P. Maybe an XML file?
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jake Voytko Sent: 24 May 2007 03:37 To: boost@lists.boost.org Subject: Re: [boost] GSoC project "Visualization of STLContainers as SVG" -setting options using << or .axis_color(red).title_font(14)...
my_graph.line_color(black).point_color(blue).x_range(-10, 10).y_range(0, 5);
Overall, I'm not against letting users use method calls to set parameters of classes.. sometimes, that's what they're there for. However, I don't feel that this is an alternative that is intuitive to users. When a user normally does chaining, like my_vector[0].to_string().find(...), they aren't expecting my_vector[0] to be affected. However, show a beginner the longest cout statement you can think of with as much chaining as you want and they'll understand that it all affects the printout, even if they don't know what a stream is! I feel that the stream operator chaining can immediately be grasped by beginners, as they know that since it looks like cout and file streams, it must affect a file somehow.
I'm surprised by this view of beginners expectations. Using a set function is surely very common. Although chaining is less common, you don't have to chain, you can write: my_graph.line_color(black); my_graph.point_color(blue); ... whose meaning is surely quite obvious? but once you see an example of chaining, I feel it is obvious what to do to save a bit of typing - always popular! Other peoples views on this? Paul PS Your prototype code doesn't permit chaining freely - it would intolerable in real-life use. But I'm sure you will be working on it ;-)
On 5/24/07, Paul A Bristow <pbristow@hetp.u-net.com> wrote:
I'm surprised by this view of beginners expectations. Using a set function is surely very common.
Although chaining is less common, you don't have to chain, you can write:
my_graph.line_color(black); my_graph.point_color(blue); ...
whose meaning is surely quite obvious?
but once you see an example of chaining, I feel it is obvious what to do to save a bit of typing - always popular!
I think I miscommunicated at some point.. I didn't mean to say that nobody would understand what to do if they were given a modifier method, and surely method chaining is a way to save typing. I just feel that using the stream operator gives a user a more intuitive feel of how to use it. If I saw a code example that said my_plot<<line_color(red); my_plot<<point_color(black); I feel it would be a reasonable conclusion that one could write, my_plot<<line_color(red)<<point_color(black); without ever having looked at the docs! However, if I saw, my_plot.line_color(red); my_plot.point_color(black); I never would expect to be able to chain the methods together without reading the docs. My personal view of the stream operator is that it says that chaining is implied, and method calls do not give that implication. However, my understanding of the C++ language is relatively nacent compared to many people on this forum, so I could be wrong!
PS Your prototype code doesn't permit chaining freely - it would intolerable in real-life use. But I'm sure you will be working on it ;-)
Indeed I am :) ! Or rather, I will be. The prototype code was written over the course of a weekend (the longest possible break I could take from my studies in one stretch) during the application process, so I was more concerned about showing that I could produce results than getting everything working. On the Wiki, I think I list that as one of the first things that I need to work out. Jake
participants (3)
-
Jake Voytko -
Maurizio Vitale -
Paul A Bristow