| 23 | | my_plot<< image_size(500, 500) << x_scale(0, 10) << y_scale(0, 10) |
| 24 | | << line_color(BLACK) << draw_axis(); |
| 25 | | |
| 26 | | my_plot<< plot_range(experiment_data.begin(), experiment_data.end()) << write(); |
| | 25 | my_plot << image_size(500, 200) << x_scale(-7, 9) << draw_axis() |
| | 26 | << plot_range(data1.begin(), data1.end(), blue) |
| | 27 | << plot_range(data2.begin(), data2.end(), green) |
| | 28 | << write(); |
| 35 | | == 2.1 `svg_graph` class == |
| 36 | | '''Currently supported operations of the form `my_plot << function()`:''' |
| 37 | | * `x_scale(double, double)` and `y_scale(double, double)` |
| 38 | | * Allows the user to set the bottom, top, left, and right edge of the graph |
| | 35 | = To-Do List = |
| | 36 | == For next week == |
| | 37 | * Create a more consistent internal name scheme (I'm starting to confuse myself) |
| | 38 | * Accept generic STL containers, `Boost.Array` |
| | 39 | * Begin to incorporate a key/legend into the graph |
| | 40 | * Allow streams to be specified as output points |
| | 41 | * Move files not to be consumed by users to "detail" folder |
| 43 | | * `set_start(double)` |
| 44 | | * Allows the user to set the x-axis location of the first data point. This is important currently because the interface does not yet support coordinate `pair<,>`s, and so the user is stuck defining the interval with which the data is input. Obviously not all data has a uniform distribution, and they'll be able to pass an STL container of pair<,>s in the future to alleviate this problem. |
| 45 | | |
| 46 | | * `set_interval(double)` |
| 47 | | * This allows the user to set the interval between data points that are being graphed. Again, this is necessary until we allow the user to put in coordinate `pair<,>`s, and will remain necessary after that for users who do not have data in coordinates |
| 48 | | |
| 49 | | * `plot_range(std::vector<double>::iterator, std::vector<double>::iterator)` |
| 50 | | * Will be the made generic |
| 51 | | * Allows the user to input a begin and an end, and have the user plot the data in between |
| 52 | | |
| 53 | | * `draw_axis()` |
| 54 | | * The user specifies that s/he would like the axis drawn in the image. |
| 55 | | |
| 56 | | '' '''Inherited from `svg`'''. I am only including the ones it makes sense to include. In the current prototype code, it inherits handling for a few functions that are not only illogical, but produce unexpected results! This will be taken care of. |
| 57 | | |
| 58 | | * `write()` |
| 59 | | * Since it would be too much work (and sometimes impossible) to maintain the file without intervention, this function acts as a 'commit'. |
| 60 | | * The user can be sure that whenever they have executed this command, the full output is written to the stream they have specified. |
| 61 | | |
| 62 | | * `line_color(svg_color c)` |
| 63 | | * Allows users to define a color |
| 64 | | * `point_color()` will soon be supported |
| 65 | | * Users will be able to define custom colors soon |
| 66 | | |
| 67 | | == 2.2 `svg` Class == |
| 68 | | The internal architecture of this class (as far as being a data structure for storing a SVG document) is as follows: |
| 69 | | One can consider a `<g>` tag as the branch element of a document. Not currently (but soon!) the `<g>` element will store full information on the styles of all elements that are listed underneath it. Each `<g>` element has a Boost.ptr_vector of tag elements, and soon this will allow (theoretically) infinite branching of the <g> tags, much as the standard would allow. This stores the document XML tree in a literal tree data structure, which I feel makes more sense. A more specific implementation of the internals will most likely come at a date in the near future. |
| 70 | | |
| 71 | | ---- |
| 72 | | = 3. To Do List = |
| 73 | | |
| 74 | | == 3.1 Near Future == |
| 75 | | * Set up codebase in SVN '''''Completed''''' |
| 76 | | * Clean up demo code. Comment better, cement next draft of architecture (focus on single axis first)'''''Completed''''' |
| 77 | | * Fully support chaining of the overloaded input operator '''''Completed''''' |
| 78 | | |
| 79 | | == 3.2 Medium Future == |
| 80 | | * Expand to two-dimensional graphs |
| 81 | | * Explore size-saving of the output file (I currently don't take advantage of things like paths that the `svg` model has to offer) |
| 82 | | * Allow pairs of data to be input |
| 83 | | * Explore hover features in the SVG format as a potential way to label data |
| 84 | | * Allow any STL-compliant container to be input (I have a hunch this will be more complicated than I'd like, so June 8th is tentative.) |
| 85 | | * Consider STL containers that don't directly fit in the straightforward container model (like maps) |
| 86 | | |
| 87 | | == 3.3 Not So Near Future == |
| 88 | | * Support 3-D graphs |
| 89 | | |
| 90 | | == 3.4 Minor Features (No ETA as of May 28) == |
| 91 | | * Full Color Support |
| 92 | | * Add handling for `-NAN` and other double error codes |
| 93 | | |
| 94 | | = 4. Suggestions (No ETA as of May 28) = |
| | 46 | = 3. Suggestions (No ETA as of May 28) = |
