Boost logo

Boost :

From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-08-09 19:02:55

On 7/30/07, Jake Voytko <jakevoytko_at_[hidden]> wrote:
> All,
> I have uploaded the newest version of SVG_Plot to the Boost Vault, and
> am looking for feedback. This library allows you to make 1 and 2

Hi Jake,

I finally got around to taking a look at your lib (although I used the
code and docs from the sandbox - hopefully that's OK). First
impressions - this functionality is extremely useful. Being able to
make an .svg straight out of code makes creating plots so much easier,
and the functionality you already have available allows for a lot of
customization. And the potential for future growth of the lib is also

In exploring your lib, I first read the docs front to back. I may
have skimmed through parts of it :-) Here are some comments (a lot of
them are very nit-picky, or they are just regarding things that
weren't perfectly clear).

* From the intro:

"The first task when dealing with numerical data is to plot it."

Ehm... Very motivational, but likely untrue? :-) I agree that plotting
data is extremely useful and important, but I don't think it is
necessarily always "the first task", or even a necessary task at all.

* From the Colors docs:

"The list contains one extra color element, blank, used when you need
to pass a color, but would not like it to show up. This comes in handy
for defining defaults for functions, for example."

I don't understand this. What do you mean by "would not like it to
show up?" The element whose color you are specifying should not show

* From the x and y axis documentation:

"For an alternate way to display a regular axis, you can use an external style:"

What is an external style?

* About customizing the plot

It first struck me as odd that some drawing parameters are specified
through the plot object, and some at plotting time (.plot method).
Then I realized that it is because there are common "plot" elements -
axis, title, background, etc., and then there are elements that are
common to each range "plot" - area fill, bezier, line color...

First thing - how can we disambiguate between "plot" as "the whole
shabang" / with options describing common supporting elements (axis,
title, ...), and "plot" as what is visualizing a single range (drawn
via .plot())?

Second - specifying the line / area fill characteristics (only) at
.plot() invocation seems to have a drawback. Suppose that I want to
create a large number of .SVGs, out of the same data but all in
different styles. So I create the plot in the first style, and output
it to a file. Now I want to change the style for the second file.
For the background elements, i can just change them by invoking the
appropriate methods. But for the .plots? There seems to be no
mechanism for me to go in and change the style of a plot drawn with
.plot(). So, I have to recreate each plot from scratch. Maybe an
avenue for this will be added when you allow for the use of external
stylesheets? Or maybe you will cover it as a part of "avoiding having
to redraw the entire plot each time".

* The defaults tables docs

The two tables have a huge overlap - could they be condensed into one
table? There could be two columns, describing the setting for each
scenario (1d/2d). if something has the same default value for both,
it can span both columns, otherwise you can list different values in
each column or say "N/A" in one of the columns.

Also, it would be nice to cross-reference this with the functions that
change the values.

* In the documentation of svg_2d_plot (and mostly in svg_1d_plot):

The reference for .plot(), _x_functor parameter:

"You will not have to worry about this, unless you are trying to
accomplish stuff like plotting a vector of humans"

This is fun sounding but confusing - "what do you mean, a vector of
humans?" - can you be more specific like "when you need to plot a
vector of values not convertible to double"?

Also, in the example you have humans as the subject, but then title
the plot "Lions" - this is a minor detail, but it made me think that
there is some human-lion conversion going on.

In the example you have:

class my_functor
        typdef pair<double, double> result_type;

        pair<double, double> operator()(const human& _hum) const
                return pair<double, double>(i, _hum.age());

- what is this "i"?


At this point I looked at the code a bit and decided to try solving a
task - creating an .svg in which the text is wrapped in \tex{} so that
I can load it with Inkscape, save it as a .eps, and then use it in a
LaTeX document via psfrag (the purpose of using psfrag is to make the
fonts and their sizes match the text). Looking ahead, since I can
specify all the text verbatim there should be no problem putting
everything in \tex{}. The only exception are tick labels, and that
will be solved when you add custom axis lables support (about that -
you should disambiguate between axis labels and axis tick labels).
Another thought - if you are planning on tackling another format next,
I vote for PS/EPS :-)

I first ran into problems trying out your examples - for one, there is
no Jamfile in the example directory (but this not be a problem with
the version in the vault). I added my own, but then found out that
the rest of your build configuration files seem to be set as if your
lib was located in boost-root. So I ended up replacing all of them by
the time I got to bjam the examples successfully.

And then - a lot of warnings and a few errors (GCC 4.0.1/darwin).
Most of the warnings were regarding the order of initialization of
members in the constructors.

Then, some of the errors were (nothing built successfully for me):

1d_full_layout.cpp:82: instantiated from here
../../../boost/svg_plot/svg_1d_plot.hpp:127: error: 'is_limit' was not
declared in this scope

../../../boost/svg_plot/detail/numeric_limits_handling.hpp: In
function 'bool boost::svg::detail::limit_NaN(double)':
../../../boost/svg_plot/detail/numeric_limits_handling.hpp:35: error:
'_isnan' was not declared in this scope

I didn't look into the reasons for the errors much. Simple fix?

Itsy-bitsy comment correction from glancing at a little bit of the source:


// sorting them into the correcet std::veector

- correcet -> correct?
- veector -> vector

Well, that's it for now :-) I can go further after I get past the errors.



Boost list run by bdawes at, gregod at, cpdaniel at, john at