On 7/31/07, Lewis Hyatt <lhyatt@princeton.edu> wrote:
This is what I meant when I said that I was having problems. It currently accepts maps, and I didn't change the language in the documentation clear enough. My view on the 1D containers (vector, etc) is that a user will have a single container, and want to plot it in two dimensions, with the index of the data being the X coordinate, and the value stored being the Y value, and the behavior will be changed to reflect that. I will look into your suggestions and see how that affects my program. I'm a little fuzzy on C++ concepts, and I didn't see a way to say that the containers hold pair<,>s.
OK, well I think what you want to do is set up the interface so that, instead of expecting a container which provides begin() and end(), you expect anything conforming to Boost.Range. (This should not be a major change, just some minor syntax adjustments). The other use cases, such as passing in a separate vector<> for x and y, or passing in only y and having x be auto-generated, are easily adapted to this interface using boost::zip_iterator and boost::counting_iterator. You might choose to support that directly by providing alternate overloads which do the adaptation for the user.
That's a good idea. I'll have to play around with that and see what I can get out of it.
I think what seems most natural to me is that you can provide two overloads of plot(x), where x can be:
-a Boost.Range with a value_type of std::pair<T,U> (what you have now) -a Boost.Range with a value_type of T, in which case you will provide an adaptor which auto-generates the x axis from the data indices
This was my original goal. I ran into some last-minute trouble providing the second interface, but that was certainly the intent. I had not considered using boost::counting_iterator and boost::zip_iterator, but I think they'll certainly help. Thanks, Jake