From: Alan W. I. <ir...@be...> - 2010-11-09 22:15:46
|
On 2010-11-05 17:33-0700 Alan W. Irwin wrote: > My remaining pllegend ToDo: > > 1. Implement plstring and also use it internally in pllegend rather > than the legacy plsym. DONE as of revision 11310. There is still plstring and pllegend documentation work, vertical offset debugging for plptex, and plcolorbar and qt device driver plstrl work to do, but this commit constitutes the last API change I have planned for pllegend so this should be the final API. This should also be the final form of API for plstring. In other words, I think plstring and pllegend are ready for propagation to bindings and examples 4 and 26 for all languages. I plan to do the python propagation shortly, and I hope others will help with the propagation effort for other languages. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-11-10 04:37:18
|
On 2010-11-09 14:15-0800 Alan W. Irwin wrote: > In other words, I think plstring and pllegend are ready for > propagation to bindings and examples 4 and 26 for all languages. I > plan to do the python propagation shortly [....] Python propagation of plstring and pllegend to bindings and examples DONE as of revision 11312. Java and Lua propagation of plstring (but not pllegend) to bindings and examples DONE as of revision 11313. Andrew, would you be willing to finish propagation of pllegend for Python? Werner, would you be willing to do the same for Lua? I cannot finish those because I don't know how to handle swig conversion of const char** arguments in either language. My next step is to make a standard example 33 (first in the Python language but then to be propagated to all other languages) that will exercise many different pllegend capabilities. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-11-10 21:46:15
|
On 2010-11-09 14:15-0800 Alan W. Irwin wrote: > In other words, I think plstring and pllegend are ready for > propagation to bindings and examples 4 and 26 for all languages. Wrong again.... :-) Revision 11318 changed the pllegend API again (and also changed the Python bindings and C and Python examples accordingly). The motivation for that change is I would like to demonstrate multiple legends aligned with each other for example 33, and for such alignment you need to make the legend_width and legend_height calculated by pllegend accessible to the calling routine. I urge developers and users here to test pllegend capabilities immediately by modifying the Python (especially example 33) or C examples. That "immediately" is because we want to finalize the pllegend API as early as possible in this release cycle. I am actually pretty sure that API is finalized now, but we might be blindsided by additional needs late in this release cycle or even in the next release cycle unless you all immediately do some inventive testing and/or thinking about how pllegend will be used in the future. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-11-14 08:27:02
|
On 2010-11-10 13:46-0800 Alan W. Irwin wrote: > On 2010-11-09 14:15-0800 Alan W. Irwin wrote: > >> In other words, I think plstring and pllegend are ready for >> propagation to bindings and examples 4 and 26 for all languages. > > Wrong again.... :-) And yet again.... :-) revision 11328 changes the API by adding a box_line_widths array to the argument list. See commit message for justification. I use this argument in one of the calls to pllegend in the new 4th page of example 33 which put the different legend types that are possible with pllegend through their various paces. (This page caught a few bugs in pllegend which I also fixed in revision 11328.) In an earlier commit I also revised the 3rd page of example 33 to look a bit nicer. I believe I am now done with example 33 which implies I wont be messing with the pllegend argument list any more (he says for the third time!). Here is what is remaining on my pllegend (and related) ToDo list for this release cycle (in descending order of priority): * Propagate example 33 from Python to C. * Doxygen and DocBook documentation of the API. * Each set of pllegend argument arrays describing text, boxes, lines, or symbols has different numbers and/or different types of arrays. Thus, it should be possible to implement 2^4 = 16 overloaded variations (for languages that support overloading) of pllegend that use the 2^4 combinations of each set of pllegend argument arrays dropped or not. * Default values of most of the pllegend arguments if they are not supplied by the user or invalid values are supplied by the user. (This has already been done with nrow and ncolumn, but the idea should be greatly expanded.) * Debug the &%%*&%*&(&* vertical alignment issues that are demonstrated (with different offsets for the many different kinds of text handling that are used by our device drivers) by examples 4, 26, and 33 and also by the later pages of examples/python/test_circle.py. It's quite likely some of the issues near the end of the above ToDo list will have to be put off until the next release cycle since I have promised some research colleagues that I will put some quality time into FreeEOS in the near future. Other's legend-related work for this release cycle: * plcolorbox (Hez). * string-length calculations implemented for our qt device driver similar to what has already been done for our cairo device driver (Hazen). * Propagation of pllegend bindings and changed examples (4 and 26) and new example (33) to all our languages other than C and Python. (Presumably most active developers will help with this propagation for their favorite language once I have completed the C version of example 33.) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-12-27 08:36:38
|
On Sun, Nov 14, 2010 at 3:26 AM, Alan W. Irwin <ir...@be...> wrote: > On 2010-11-10 13:46-0800 Alan W. Irwin wrote: > > Other's legend-related work for this release cycle: > > * plcolorbox (Hez). > It's taken much longer than expected, but a first (incomplete) version of plcolorbar is now available (revision 11394). The commit message has more details, but here is a summary. The eventual plan is to support color bars for plimage, possibly plimagefr, plshades and probably plgradient with this function. This revision only includes support for plimage. Color bars can be placed relative to any of the four plot sub-page sides, with user-defined lengths and widths. End-caps can be added as well. Two pages have been added to the end of example 33 to illustrate the progress so far. There is still a lot of testing to do, particularly testing all of the possible combinations of position side, label side and end-cap drawing. Please take a look at the API and new pages from example 33 and let me know if anything seems to be missing or implemented in an unintuitive way. Enjoy! Hez |
From: Hezekiah M. C. <hez...@us...> - 2010-12-30 04:58:08
|
On Mon, Dec 27, 2010 at 2:32 AM, Hezekiah M. Carty <hez...@us...> wrote: > On Sun, Nov 14, 2010 at 3:26 AM, Alan W. Irwin > <ir...@be...> wrote: >> On 2010-11-10 13:46-0800 Alan W. Irwin wrote: >> >> Other's legend-related work for this release cycle: >> >> * plcolorbox (Hez). >> > > It's taken much longer than expected, but a first (incomplete) version > of plcolorbar is now available (revision 11394). The commit message > has more details, but here is a summary. > > The eventual plan is to support color bars for plimage, possibly > plimagefr, plshades and probably plgradient with this function. This > revision only includes support for plimage. Color bars can be placed > relative to any of the four plot sub-page sides, with user-defined > lengths and widths. End-caps can be added as well. > > Two pages have been added to the end of example 33 to illustrate the > progress so far. There is still a lot of testing to do, particularly > testing all of the possible combinations of position side, label side > and end-cap drawing. > > Please take a look at the API and new pages from example 33 and let me > know if anything seems to be missing or implemented in an unintuitive > way. > The plcolorbar implementation should now be functionally complete (rev. 11402). It still requires testing, but all of the features should be in place. Added: - plshades support, including uneven spacing between shade segments (see example 33, page 7) - plgradient support - Extra pages in example 33 to illustrate this functionality Hez |
From: Hezekiah M. C. <hez...@us...> - 2010-09-28 20:24:41
|
On Tue, Sep 28, 2010 at 2:03 PM, Alan W. Irwin <ir...@be...> wrote: > On 2010-09-28 08:43-0400 Hezekiah M. Carty wrote: >> 2. With support for cmap1 elsewhere in pllegend, would it be >> reasonable to add support for cmap1 line and symbol colors? > > Yes. > >> Do people >> generally use cmap1 for line or symbol plots? > > I think we only have one instance of that in our examples so users may > not have picked up on this possibility, but it has long been the case > that plcol0 and plcol1 could be used interchangably so perhaps we > should arrange that for pllegend as well. > > To implement this, I think we need an overall PL_LEGEND_CMAP1 opt flag > and we should replace PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 in opt_array > with PL_LEGEND_DISCRETE_COLOR. If the overall PL_LEGEND_CMAP1 opt > flag is set, _all_ color indices are interpreted as PLFLT cmap1 values > in the range from 0. to 1., but otherwise they are interpreted as > PLINT cmap0 index values. > This sounds reasonable to me. It would be nice to be able to mix and match cmap0 and cmap1 in the same legend - could this be done with a per-entry flag? In this case, each entry's color would be interpreted according to the matching flag. A possible exception would be the text color for legend entries - it would probably be a good idea to leave them as cmap0 (PLINT) only. > One potential downside to having cmap0 and cmap1 alternatives for all > colors is a proliferation of alternative PLINT cmap0 or PLFLT cmap1 > arguments such as the current PLINT *cmap0_colors, PLFLT * > cmap1_colors arguments. Could we just use generic pointer (void *) > arguments to stand in for either kind of cmap index/value to halve the > number of color arguments? I have very little experience with using > void *, so if you think this idea would work, could you illustrate what to > do with a commit that replaces the current PLINT > *cmap0_colors, PLFLT * cmap1_colors arguments with one generic pointer > argument? Then I could propagate that idea to all our other color > arguments, e.g., bg_color, text_colors, line_colors, symbol_colors > (which are currently restricted to just cmap0). > The simplest option I see is to make all of the color arguments PLFLT. This would require a user of the C API to copy their cmap0 PLINT array to a PLFLT array, but it limits the number of arguments. Making the arguments void * could be used here, but it makes the API more fragile. There is nothing to stop a user from passing in the wrong kind of array and getting a segfault at runtime, or worse, no segfault and silently produced bad output. > Are there any downsides to using generic pointers for something like > this? For example, will such pointers make it difficult to propagate > pllegend to some of our languages? > This would likely make language bindings more difficult, but not terribly so in the case of OCaml - the pllegend function already needs to be wrapped by hand. I can't speak for other languages. > Whatever we decide to do here, I think we should be consistent. So if > you don't think it is a good idea to provide both cmap0 and cmap1 > alternatives for all colour arguments (through generic pointers), then > I think we should probably consistently use cmap0 arguments for all > colors, i.e., drop the PLFLT * cmap1_colors argument and replace the > current PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 flags in opt_array with > PL_LEGEND_DISCRETE_COLOR. > Sticking with cmap0 as the only option is certainly the simplest approach. I do think cmap1 is worth supporting, but it's probably worth polling the rest of the PLplot developers to see what others would prefer. I can likely provide more feedback and assistance later this evening, but I hope these initial thoughts are helpful. Hez |
From: Alan W. I. <ir...@be...> - 2010-09-28 21:30:34
|
On 2010-09-28 16:24-0400 Hezekiah M. Carty wrote: > On Tue, Sep 28, 2010 at 2:03 PM, Alan W. Irwin > <ir...@be...> wrote: >> To implement this, I think we need an overall PL_LEGEND_CMAP1 opt flag >> and we should replace PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 in opt_array >> with PL_LEGEND_DISCRETE_COLOR. If the overall PL_LEGEND_CMAP1 opt >> flag is set, _all_ color indices are interpreted as PLFLT cmap1 values >> in the range from 0. to 1., but otherwise they are interpreted as >> PLINT cmap0 index values. >> > > This sounds reasonable to me. It would be nice to be able to mix and > match cmap0 and cmap1 in the same legend - could this be done with a > per-entry flag? > In this case, each entry's color would be interpreted > according to the matching flag. A possible exception would be the > text color for legend entries - it would probably be a good idea to > leave them as cmap0 (PLINT) only. After thinking about this some more I have changed my mind, and I now feel strongly that simplest is best so we should just use cmap0 colors for all the various kinds of colors. After all, this is just a discrete legend API so it would be natural to use discrete colors with it. As soon as you add the choice of cmap1 colors for the extreme minority of our users that use them in discrete situations, then the API possibilities start to proliferate like mad with extra arguments required to determine separate cmap0 or cmap1 choices for bg_color, text_colors, line_colors, symbol_colors, and block_colors. To make things worse, the latter four of those are per entry. In sum, I just don't think all those API complications are worth it in order to support what I feel is always going to be an extreme minority use case. > >> One potential downside to having cmap0 and cmap1 alternatives for all >> colors is a proliferation of alternative PLINT cmap0 or PLFLT cmap1 >> arguments such as the current PLINT *cmap0_colors, PLFLT * >> cmap1_colors arguments. Could we just use generic pointer (void *) >> arguments to stand in for either kind of cmap index/value to halve the >> number of color arguments? I have very little experience with using >> void *, so if you think this idea would work, could you illustrate what to >> do with a commit that replaces the current PLINT >> *cmap0_colors, PLFLT * cmap1_colors arguments with one generic pointer >> argument? Then I could propagate that idea to all our other color >> arguments, e.g., bg_color, text_colors, line_colors, symbol_colors >> (which are currently restricted to just cmap0). >> > > The simplest option I see is to make all of the color arguments PLFLT. > This would require a user of the C API to copy their cmap0 PLINT > array to a PLFLT array, but it limits the number of arguments. I guess that is the best option if we are going to deal with cmap1 at all, but the downside is it will confuse users to have two interpretations of their floating point numbers depending on a proliferation of cmap0/cmap1 choice options in the API. Thus, as I said above, I now want to keep this simple and stick with cmap0 alone. >> Whatever we decide to do here, I think we should be consistent. So if >> you don't think it is a good idea to provide both cmap0 and cmap1 >> alternatives for all colour arguments (through generic pointers), then >> I think we should probably consistently use cmap0 arguments for all >> colors, i.e., drop the PLFLT * cmap1_colors argument and replace the >> current PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 flags in opt_array with >> PL_LEGEND_DISCRETE_COLOR. >> > > Sticking with cmap0 as the only option is certainly the simplest > approach. For the "simplest is best" reasons above, I am going to drop cmap1 from pllegend. I will try to finish that by late this afternoon. > > I can likely provide more feedback and assistance later this evening, > but I hope these initial thoughts are helpful. Very much so. They brought to my attention some of the complications inherent to catering to cmap1 usage in discrete color situations so I think we are going to have a simpler and therefore better pllegend API as a result. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-09-28 22:06:10
|
On Tue, Sep 28, 2010 at 5:30 PM, Alan W. Irwin <ir...@be...> wrote: > On 2010-09-28 16:24-0400 Hezekiah M. Carty wrote: >> Sticking with cmap0 as the only option is certainly the simplest >> approach. > > For the "simplest is best" reasons above, I am going to drop cmap1 > from pllegend. I will try to finish that by late this afternoon. > That sounds perfectly reasonable to me. The plcolorbar API will need cmap1 support, but that is/will be useful with a different kind of plot. Hez |
From: Alan W. I. <ir...@be...> - 2010-09-28 22:46:44
|
On 2010-09-28 14:30-0700 Alan W. Irwin wrote: > For the "simplest is best" reasons [...], I am going to drop cmap1 > from pllegend. I will try to finish that by late this afternoon. Done as of revision 11231. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-09-30 01:41:16
|
On Tue, Sep 28, 2010 at 6:46 PM, Alan W. Irwin <ir...@be...> wrote: > On 2010-09-28 14:30-0700 Alan W. Irwin wrote: > >> For the "simplest is best" reasons [...], I am going to drop cmap1 >> from pllegend. I will try to finish that by late this afternoon. > > Done as of revision 11231. > While working on the OCaml interface to pllegend, I came up with a potential improvement to the C interface: What do you think of changing the pllegend API somewhat to allow only specifying the entries which are actually used? For example, if there are no symbols, the symbol arrays would be empty. If there are two lines and one box, there would be two elements in the line arrays and one in the box array. nlegend would still be the total number of entries in the legend, and opt_array would be used to specify where the legend entries are placed. Here is a example subset of parameters: nlegend: 4 opt_array: PL_LEGEND_LINE, PL_LEGEND_LINE, PL_LEGEND_SYMBOL | PL_LEGEND_LINE, PL_LEGEND_LINE line_colors: red, blue, purple, green symbol_colors: blue, yellow >From these (plus styles, widths, symbols, etc), the legend would show up as: 1. blue symbols, red line 2. blue line 3. yellow symbols, purple line 4. green line Does this make sense? I think it would make passing arguments to pllegend a bit more predictable as no dummy entries are required, but I don't know if others would feel the same way. I'm willing to make an attempt at implementation if you think it is worth considering. Hez |
From: Alan W. I. <ir...@be...> - 2010-09-30 05:48:18
|
Hi Hez: On 2010-09-29 21:40-0400 Hezekiah M. Carty wrote: > On Tue, Sep 28, 2010 at 6:46 PM, Alan W. Irwin > <ir...@be...> wrote: >> On 2010-09-28 14:30-0700 Alan W. Irwin wrote: >> >>> For the "simplest is best" reasons [...], I am going to drop cmap1 >>> from pllegend. I will try to finish that by late this afternoon. >> >> Done as of revision 11231. >> > > While working on the OCaml interface to pllegend, I came up with a > potential improvement to the C interface: > > What do you think of changing the pllegend API somewhat to allow only > specifying the entries which are actually used? For example, if there > are no symbols, the symbol arrays would be empty. If there are two > lines and one box, there would be two elements in the line arrays and > one in the box array. nlegend would still be the total number of > entries in the legend, and opt_array would be used to specify where > the legend entries are placed. > > Here is a example subset of parameters: > > nlegend: 4 > opt_array: PL_LEGEND_LINE, PL_LEGEND_LINE, PL_LEGEND_SYMBOL | > PL_LEGEND_LINE, PL_LEGEND_LINE > line_colors: red, blue, purple, green > symbol_colors: blue, yellow > >> From these (plus styles, widths, symbols, etc), the legend would show up as: > > 1. blue symbols, red line > 2. blue line > 3. yellow symbols, purple line > 4. green line > > Does this make sense? I think it would make passing arguments to > pllegend a bit more predictable as no dummy entries are required, but > I don't know if others would feel the same way. > > I'm willing to make an attempt at implementation if you think it is > worth considering. Thanks for thinking some more about what is possible with pllegend, but in this case I do not like this idea. Instead, I prefer the present identical dimensions for all quantities so that the same position of each array always refers to the same legend entry. I think that is much less confusing to users (see below for an example). Furthermore, note I have been careful with the present implementation to insure no unused quantities (as determined by the bits set in each entry for opt_array) are ever referred to. So you only have to specify quantities that opt_array indicates will actually be used. I did specify all pllegend arrays completely for example 4 because I wanted to facilitate my experimentation testing (and hopefully yours as well) of that example legend with all combinations of possible opt_array values, but full specification is not necessary, and once we get to propagating example 4 post-release I will leave opt_array in its present form, set the unused box arrays for that example to NULL, and also simply ignore any unused quantities for each legend entry rather than setting them. So the preparation and call will look like this: // Draw a legend // First legend entry. opt_array[0] = PL_LEGEND_LINE; text_colors[0] = 2; text[0] = "Amplitude"; line_colors[0] = 2; line_styles[0] = 1; line_widths[0] = 1; // note from the above opt_array the first symbol (and box) indices // do not have to be specified // Second legend entry. opt_array[1] = PL_LEGEND_LINE | PL_LEGEND_SYMBOL; text_colors[1] = 3; text[1] = "Phase shift"; line_colors[1] = 3; line_styles[1] = 1; line_widths[1] = 1; symbol_colors[1] = 3; symbol_scales[1] = 1.; symbol_numbers[1] = 4; symbols[1] = 3; // from the above opt_arrays we can completely ignore everything // to do with boxes. plscol0a( 15, 32, 32, 32, 0.90 ); pllegend( PL_LEGEND_BACKGROUND, 0.57, 0.85, 0.06, 15, nlegend, opt_array, 1.0, 1.0, 2.0, 1., text_colors, text, NULL, NULL, NULL, line_colors, line_styles, line_widths, symbol_colors, symbol_scales, symbol_numbers, symbols ); Note the second entry above is especially complicated because two plotted possibilities are specified for that entry, but a more normal case would be only one plotted possibility (a box, line, or line of symbols) alone for each entry which reduces what has to be specified. I am also thinking about the possibility of specifying defaults for many/most arrays that are set to NULL within pllegend for the core C library. For example, if line_styles (or box_patterns) is NULL use a continuous line (or solid fill for the box) for each entry, But this change concerning the meaning of a NULL array in the core C version doesn't change the core C version API so I intend to think some more about this after the release before doing anything about it. Also, for the many of our language bindings that allow function overloading, I think as a convenience to users it would be fine to have 7 overloaded pllegend possibilities corresponding to the 7 possibilities (assuming you are going to exclude the not, not, not combination) of boxes or not; lines or not; and symbols or not. Also, there may well be additional overloading possibilities when say box_patterns or line_styles (or quite a few other possibilities with C defaults) are missing from the argument list. But all of such overloading considerations should be dealt with after the release. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-09-30 04:00:31
Attachments:
pllegend-alternate-api-test.patch
|
On Wed, Sep 29, 2010 at 9:40 PM, Hezekiah M. Carty <hez...@us...> wrote: > On Tue, Sep 28, 2010 at 6:46 PM, Alan W. Irwin > <ir...@be...> wrote: >> On 2010-09-28 14:30-0700 Alan W. Irwin wrote: >> >>> For the "simplest is best" reasons [...], I am going to drop cmap1 >>> from pllegend. I will try to finish that by late this afternoon. >> >> Done as of revision 11231. >> > > While working on the OCaml interface to pllegend, I came up with a > potential improvement to the C interface: > <snip> > > I'm willing to make an attempt at implementation if you think it is > worth considering. > I gave the change a shot. I don't want to commit without getting some feedback, so I have attached a test patch for pllegend.c and x04c.c for your consideration. I think the result is positive overall. Thoughts? Hez |
From: Alan W. I. <ir...@be...> - 2010-09-30 05:56:21
|
> I gave the change a shot. I don't want to commit without getting some > feedback, so I have attached a test patch for pllegend.c and x04c.c > for your consideration. I think the result is positive overall. > > Thoughts? I looked at the patch to make sure I had understood you before. (I had.) Note in the example I just posted, the exact same number of quantities are specified as in your patch to x04c.c, but with a uniform index of 0 for the data for the first legend entry and a uniform index of 1 for the data for the second legend entry. Sorry, but I just feel that uniform indices are much easier for humans to understand so I would like to stick with the status quo. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2010-10-05 01:36:11
|
As of revision 11247 I have propagated the pllegend API to python just to prove that I could do so. Because my python swig skills are rusty it was a bit of a struggle dealing with the char ** text array because we had not dealt with that type before with swig. Those who eventually propagate pllegend to Java and Lua (and probably other languages) should be aware that this type is going to cause you some extra work. As a result of my propagation work, I now get consistent results for python and C for both examples 4 and 26. Others may also want to propagate pllegend to their favorite languages at this time. However, you should be aware that once Hez and Andrew have propagated pllegend to OCaml and Octave and compared its capabilities with the older legend capabilities for those languages, we might get some suggested changes in the pllegend API out of those comparisons. If those changes actually occur I am willing to modify my python propagation accordingly, but others may want to wait to propagate pllegend until we get feedback from Hez and Andrew on their experiences with pllegend for OCaml and Octave. We also need a volunteer to create an initial version of plcolorbar functionality in our core C library to complement the current discrete pllegend functionality. Hez, would you also be willing/able to take a shot at this? Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-10-17 19:13:06
|
On Mon, Oct 4, 2010 at 9:36 PM, Alan W. Irwin <ir...@be...> wrote: > As of revision 11247 I have propagated the pllegend API to python just > to prove that I could do so. Because my python swig skills are rusty > it was a bit of a struggle dealing with the char ** text array because > we had not dealt with that type before with swig. Those who > eventually propagate pllegend to Java and Lua (and probably other > languages) should be aware that this type is going to cause you some > extra work. > > As a result of my propagation work, I now get consistent results for > python and C for both examples 4 and 26. Others may also want to > propagate pllegend to their favorite languages at this time. However, > you should be aware that once Hez and Andrew have propagated pllegend > to OCaml and Octave and compared its capabilities with the older > legend capabilities for those languages, we might get some suggested > changes in the pllegend API out of those comparisons. If those > changes actually occur I am willing to modify my python propagation > accordingly, but others may want to wait to propagate pllegend until > we get feedback from Hez and Andrew on their experiences with pllegend > for OCaml and Octave. > I have propagated the pllegend API and example changes (examples 4 and 26) to OCaml as of revision 11262. This revision gives clean "make test_diff_psc" results between C and OCaml on my system. One suggestion I have for the API is to add a box/outline option for the pllegend window (PL_LEGEND_BOX as another option for the opt parameter?). I'm not sure how the color of the box should be added to the API - we already get a background color argument, and I'm concerned about pllegend's already long argument list becoming longer with every new option added. The previous OCaml legend support does not have this feature, but it would be a nice addition. > We also need a volunteer to create an initial version of plcolorbar > functionality in our core C library to complement the current discrete > pllegend functionality. Hez, would you also be willing/able to take a > shot at this? > I'll see what I can do with this. Hez |
From: Hezekiah M. C. <hez...@us...> - 2010-10-18 01:28:42
|
On Sun, Oct 17, 2010 at 3:12 PM, Hezekiah M. Carty <hez...@us...> wrote: > On Mon, Oct 4, 2010 at 9:36 PM, Alan W. Irwin <ir...@be...> wrote: >> >> As a result of my propagation work, I now get consistent results for >> python and C for both examples 4 and 26. Others may also want to >> propagate pllegend to their favorite languages at this time. However, >> you should be aware that once Hez and Andrew have propagated pllegend >> to OCaml and Octave and compared its capabilities with the older >> legend capabilities for those languages, we might get some suggested >> changes in the pllegend API out of those comparisons. If those >> changes actually occur I am willing to modify my python propagation >> accordingly, but others may want to wait to propagate pllegend until >> we get feedback from Hez and Andrew on their experiences with pllegend >> for OCaml and Octave. >> > > One suggestion I have for the API is to add a box/outline option for > the pllegend window (PL_LEGEND_BOX as another option for the opt > parameter?). I'm not sure how the color of the box should be added to > the API - we already get a background color argument, and I'm > concerned about pllegend's already long argument list becoming longer > with every new option added. > I have started work on the plcolorbar API. I don't expect to have it done today, but it did bring up some API/functionality changes I would like to propose for pllegend (and use in plcolorbar). 1. I think it is worth considering different ways of expressing the position of a legend or color bar. For example, in the OCaml color bar API, the position of the color bar is specified relative to a user-specified plot subpage boundary. This could be done in the C API with another set of options for the "opt" parameter: PL_LEGEND_TOP, PL_LEGEND_BOTTOM, PL_LEGEND_LEFT, PL_LEGEND_RIGHT and possibly PL_LEGEND_CENTER. The position arguments would then be interpreted as offsets from the given side. For example: PL_LEGEND_BOTTOM | PL_LEGEND_RIGHT : Position the box relative to the bottom-right of the plot subpage PL_LEGEND_RIGHT | PL_LEGEND_CENTER : Position the box relative to the right side of the plot subpage, centered vertically (the y-position would be ignored in this case) The default would continue to be PL_LEGEND_TOP | PL_LEGEND_LEFT. I expect PL_LEGEND_CENTER to be more commonly used with plcolorbar. 2. Allow a user to specify if they want the legend positioned relative to the plot window or the plot subpage (PL_LEGEND_PAGE or PL_LEGEND_WINDOW?). The position would be (possibly normalized) plot window coordinates for PL_LEGEND_WINDOW and normalized subpage coordinates for PL_LEGEND_PAGE. Sizes/lengths would probably still be specified as normalized subpage coordinates. I expect most of the "opt"-appropriate options to be shared between pllegend and plcolorbar. If the rest of you feel that these changes are reasonable, I am willing to make or help make the required changes to the C implementation of pllegend. Hez |
From: Alan W. I. <ir...@be...> - 2010-10-18 06:03:54
|
On 2010-10-17 21:28-0400 Hezekiah M. Carty wrote: > On Sun, Oct 17, 2010 at 3:12 PM, Hezekiah M. Carty >> One suggestion I have for the API is to add a box/outline option for >> the pllegend window (PL_LEGEND_BOX as another option for the opt >> parameter?). I think this is a good idea. The independent QSAS plot legend also has the option of painting a bounding box for the legend. >> I'm not sure how the color of the box should be added to >> the API - we already get a background color argument, and I'm >> concerned about pllegend's already long argument list becoming longer >> with every new option added. I would go ahead and add another argument to specify the color of the box. I think we just have to live with the fact that making a legend that satisfies most people's style requirements requires a lot of arguments (see also nrow and ncolumn discussed below). However, large numbers of arguments shouldn't be much of a problem for C users if we are really smart about adopting good default values for most parameters. Furthermore, we will eventually want to provide some standard smaller argument lists for pllegend for those language bindings that have function overloading. So let's keep these general possibilities in mind, but wait to do any detailed implemention of default values and/or function overloading until the fundamental API is completely settled. >> > > I have started work on the plcolorbar API. I don't expect to have it > done today, but it did bring up some API/functionality changes I would > like to propose for pllegend (and use in plcolorbar). > > 1. I think it is worth considering different ways of expressing the > position of a legend or color bar. For example, in the OCaml color > bar API, the position of the color bar is specified relative to a > user-specified plot subpage boundary. This could be done in the C API > with another set of options for the "opt" parameter: PL_LEGEND_TOP, > PL_LEGEND_BOTTOM, PL_LEGEND_LEFT, PL_LEGEND_RIGHT and possibly > PL_LEGEND_CENTER. The position arguments would then be interpreted as > offsets from the given side. For example: > > PL_LEGEND_BOTTOM | PL_LEGEND_RIGHT : Position the box relative to the > bottom-right of the plot subpage > > PL_LEGEND_RIGHT | PL_LEGEND_CENTER : Position the box relative to the > right side of the plot subpage, centered vertically (the y-position > would be ignored in this case) > > The default would continue to be PL_LEGEND_TOP | PL_LEGEND_LEFT. I > expect PL_LEGEND_CENTER to be more commonly used with plcolorbar. Sounds good. > 2. Allow a user to specify if they want the legend positioned relative > to the plot window or the plot subpage (PL_LEGEND_PAGE or > PL_LEGEND_WINDOW?). The position would be (possibly normalized) plot > window coordinates for PL_LEGEND_WINDOW and normalized subpage > coordinates for PL_LEGEND_PAGE. Sizes/lengths would probably still be > specified as normalized subpage coordinates. The QSAS team brought up this issue as well. I think you guys are right so let's just drop the PL_LEGEND_PAGE and PL_LEGEND_WINDOW control bits and instead always specify the x, y position, and length of plotted area in normalized window coordinates. Then to go outside the window you simply set an x position or y position of less than 0 or greater than 1. > > I expect most of the "opt"-appropriate options to be shared between > pllegend and plcolorbar. > > If the rest of you feel that these changes are reasonable, I am > willing to make or help make the required changes to the C > implementation of pllegend. Please go ahead. After you have completed those C API changes, there is one additional change (rows and columns in the legend, again suggested by what the QSAS legend does) that I want to implement as well. I am thinking of an API where you specify nrow and ncolumn. Normally, the nrow by ncolumn cells would be filled in column-major order with nlegend <= nrow*ncolumn entries, but if the PL_LEGEND_ROW_MAJOR bit were set, the cell filling would be done in row-major order rather than the default column-major order. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-09-10 22:02:25
|
On Thu, Sep 9, 2010 at 3:00 PM, Alan W. Irwin <ir...@be...> wrote: > I am transferring this discussion from plplot-general to plplot-devel > with a different subject. > > On 2010-09-09 10:36-0400 Hezekiah M. Carty wrote: > >> The OCaml bindings include a character_height function which (should?) >> return the character height in world coordinates: >> >> >> http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/bindings/ocaml/plplot.ml?revision=11020&view=markup >> >> The function begins on line 611 and should be fairly self-explanatory. >> There is likely a simpler way to do this using internal PLplot >> functions, but this method allows you to stick to the public, >> documented API. >> > > I am not that good at reading OCaml code, but it looks like the method > combines results from plgch, plgvpd, plgspa, and plgvpw. From the > documentation of those, you should be able to use the combination of > plgspa and plgvpd to obtain the viewport limits in mm. Then combine > those results with plgvpw results (which obtains the viewport limits > in world coordinates) to determine the ratio of world coordinates to > mm in the y direction. Then use that factor to transform plgchr > height results in mm to world coordinates. So I think this idea > should work fine, but it would not be necessary if we had a central > libplplot pllegend capability which simply accessed the required > internal variables directly. > I think I'll stick with a direct port using the public API for the first pass. This can be relaxed once the port to C is working acceptably. > Hez, from your OCaml experience with legends would you be willing to > implement a legend-drawing capability in libplplot and also modify one > of our C examples to use that new API? (I assume from here on that > that new function would be called pllegend.) If you were willing to do > that implementation, I (and presumably others from past history) would > be willing to help out afterward with the usual API addition tasks of > pllegend documentation and propagating the pllegend API and its use in > a standard example to all our languages. I believe the ultimate > result of a well-documented and uniform pllegend capability for all > our languages would be a welcome improvement to PLplot. > I'll give it a shot. The current OCaml version is purely for line-plot legends. It should be fairly straightforward to generalize the function to allow either line or point/symbol legends from the same function. I've started a src/pllegend.c. I'll reply to this thread once I have an initial test version checked in to trunk. Hez |
From: Hezekiah M. C. <hez...@us...> - 2010-09-10 23:48:22
|
On Fri, Sep 10, 2010 at 6:01 PM, Hezekiah M. Carty <hez...@us...> wrote: > On Thu, Sep 9, 2010 at 3:00 PM, Alan W. Irwin <ir...@be...> wrote: >> Hez, from your OCaml experience with legends would you be willing to >> implement a legend-drawing capability in libplplot and also modify one >> of our C examples to use that new API? (I assume from here on that >> that new function would be called pllegend.) If you were willing to do >> that implementation, I (and presumably others from past history) would >> be willing to help out afterward with the usual API addition tasks of >> pllegend documentation and propagating the pllegend API and its use in >> a standard example to all our languages. I believe the ultimate >> result of a well-documented and uniform pllegend capability for all >> our languages would be a welcome improvement to PLplot. >> > > I'll give it a shot. The current OCaml version is purely for > line-plot legends. It should be fairly straightforward to generalize > the function to allow either line or point/symbol legends from the > same function. > > I've started a src/pllegend.c. I'll reply to this thread once I have > an initial test version checked in to trunk. > The initial version of pllegend is now in PLplot trunk, revision 11165. This adds: - pllegend.c: The implementation, including a C-port of get_character_height which is not exposed in the public API - x04c.c: The first page has been updated to include a legend, and symbols have been added to one of the lines to help illustrate the pllegend API I need to run for now, but hopefully this is a good start. pllegend.c has a comment explaining each of the function arguments. pllegend allows basic line or symbol legends in its current state. Comments on the API are more than welcome! Hez |
From: Alan W. I. <ir...@be...> - 2010-09-11 01:09:27
|
On 2010-09-10 18:46-0400 Hezekiah M. Carty wrote: > The initial version of pllegend is now in PLplot trunk, revision > 11165. Thanks very much for this effort. However, it appears you forgot to svn add and commit your new pllegend.c. Once that rather urgent (since it makes builds impossible) issue is straightened out, I look forward to seeing what the new legend is going to look like for example 4. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hezekiah M. C. <hez...@us...> - 2010-09-11 04:55:22
|
On Fri, Sep 10, 2010 at 9:09 PM, Alan W. Irwin <ir...@be...> wrote: > On 2010-09-10 18:46-0400 Hezekiah M. Carty wrote: > >> The initial version of pllegend is now in PLplot trunk, revision >> 11165. > > Thanks very much for this effort. However, it appears you forgot to > svn add and commit your new pllegend.c. Once that rather urgent > (since it makes builds impossible) issue is straightened out, I look > forward to seeing what the new legend is going to look like for > example 4. > Ouch - that's quite embarrassing! Thank you for pointing out the oversight, and my apologies for missing that. Revision 11166 adds pllegend.c, and will hopefully build successfully. Hez |