Activity for Hiroki Motoyoshi
-
Hiroki Motoyoshi modified a comment on ticket #815
Thank you for confirming about the 205 patch. mark's border drawing rule Deciding whether or not to draw a border is a bit more complicated, but it is possible to establish a consistent rule that 'mode', 'mark border style', and 'parent border style' have priority in that order, as shown in 'DrawModeRules.pdf'. Your commit “5af9157bcc6c85a91564464b08e090f86888c280” gives top priority to the 'noborder' directive in 'parent border style', which conflicts with the rule proposed here. If you agree with...
-
Thank you for confirming about the 205 patch. mark's border drawing rule Deciding whether or not to draw a border is a bit more complicated, but it is possible to establish a consistent rule that 'mode', 'mark border style', and 'parent border style' have priority in that order, as shown in 'DrawModeRules.pdf'. Your commit “5af9157bcc6c85a91564464b08e090f86888c280” gives top priority to the 'noborder' directive in 'parent border style', which conflicts with the rule proposed here. If you agree with...
-
Are you sure? This change would mean that you cannot modify the fillstyle of an object that contains a mark. I think the current initialization to FS_DEFAULT is correct. That tells it to inherit the fillstyle of the object that contains it. Yes, I'm sure. The 205 patch simply modifies the object mark's default fillstyle. My test code is like this, $box <<EOD 0 0 0 1 1 1 1 0 0 0 EOD set mark 1 $box using ($1-0.5):($2-0.5) set mark 1 append $box set xrange [-1:2] set yrange [-1:2] set label at 0,1.2...
-
Thank you for refactoring set_mark(). Here are two small patches, after your commit. 204_disable_append_in_first_set_mark.patch More fixes to set_mark. Includes the following. [Fix] set mark 1 append $data when none of the marks are defined is not acceptable [Refactoring] Eliminate MARK_ACTION_CREATE and MARK_ACTION_APPEND macro variables 205_modify_default_fillstyle_of_object_mark.patch The default fillstyle of "mark" object was "fs solid 1", but it should be changed to "fs empty" as well as "plot...
-
Patch for fixes to 'set_mark()' This patch contains the following Fixes and Modifications [Fix] Correct rejection of pseudo file "++" [Modification] 'set mark N empty' should accept 'title', 'fc', 'fs' options [Modification] 'set mark N append' should not accept 'title', 'fc', 'fs' options (raises error) [Modification] 'append' for undefined mark tag should be an error to avoid confusing [Modification] macro variable MARK_ACTION_UNDEFINED is removed by refactoring With this patch, the syntax of the...
-
Another concerns about the current implementation of the main branch on SourceForge. ** border color selection for 'fc variable' ** If the 'fc variable' is specified and the border color is not, the border line is drawn as a black line. It should be matched with the variable fillcolor. The patch is attached, and the test script is here. $box << EOD 0 0 0 1 1 1 1 0 0 0 EOD set mark 1 $box $data << EOD 0 0 0 1 1 0 1 1 EOD set xrange [-1:3] set yrange [-1:3] plot $data using 1:2:($0+1) with marks mt...
-
If you replace the code snippet 'using 1:0:2' in the 'with labels' section with 'using 1:(0):2', does the output match your expectations? The 'using 1:0:2' is functionally equivalent to 'using ($1):($0):($2)'. Here, '$0' serves as a pseudocolumn, initiating at 0 and incrementing by 1 for each valid point read. This likely affects the y-axis offset of the labels in your figure, causing it to increase by 1. If, despite the replacement, the y-axis offset of the labels in your figure still increases,...
-
After much consideration, I have given up on introducing color and fillstyle columns, as I do not have enough material to convince you at this time. Even without introducing color and fillstyle columns, the 'marks' style would be a new feature that expands gnuplot's expression. So, please proceed with the current direction of the main branch of SourceForge. I have the following concerns about the current implementation of the main branch on SourceForge, and I hope you will consider them. 'fillcolor'...
-
After much consideration, I have given up on introducing color and fillstyle columns, as I do not have enough material to convince you at this time. Even without introducing color and fillstyle columns, the 'marks' style would be a new feature that expands gnuplot's expression. So, please proceed with the current direction of the main branch of SourceForge. I have the following concerns about the current implementation of the main branch on SourceForge, and I hope you will consider them. 'fillcolor'...
-
After much consideration, I have given up on introducing color and fillstyle columns, as I do not have enough material to convince you at this time. Even without introducing color and fillstyle columns, the 'marks' style would be a new feature that expands gnuplot's expression. So, please proceed with the current direction of the main branch of SourceForge. I have the following concerns about the current implementation of the main branch on SourceForge, and I hope you will consider them. 'fillcolor'...
-
Since there is no 4th vertex property, you can't switch colors in the middle of a mark definition. On the other hand, the fill and stroke colors can be different from the start. It would not be that much work to add back a vertex color if needed. In my opinion, it is more valuable to be able to switch colors in the middle of a mark definition. By doing so, fill and stroke can be superimposed as separate definitions, and as a result, the border color can be specified separately. This is the case for...
-
Since there is no 4th vertex property, you can't switch colors in the middle of a mark definition. On the other hand, the fill and stroke colors can be different from the start. It would not be that much work to add back a vertex color if needed. In my opinion, it is more valuable to be able to switch colors in the middle of a mark definition. By doing so, fill and stroke can be superimposed as separate definitions, and as a result, the border color can be specified separately. This is the case for...
-
Thank you for the patch. This feature gives us a hint as to the shape, which we can't know from the number alone.
-
This may be wandering off topic. I do think it is a good idea to make all gnuplot terminals consistent with regard to the winding attribute, but that may not actually achieve what you want. Do you have a real-world example of a polygon shape with holes in it that you want to draw? Is the trick of connecting interior "hole" shapes to the overall perimeter via a zero-width line (as in your example) sufficient? Marks does not yet have an actual example, but a 'with polygons' style example would be the...
-
Thanks for the information on the Fill-Rule for each terminal. It is very helpful. I understand that it is possible to paint with a single stroke polygon, like the star shape in your example. Apparently, the Fill-Rule setting is not the only essential thing for drawing holes. For example, whether the Fill-Rule is nonzero or even-odd, we should be able to represent a hole by drawing the outer polygon clockwise and the inner polygon counter clockwise. If we call the inner polygon a subpath of the outer...
-
One issue I came across was whether a "marktype 0" should be accepted. I can see that it makes the nice windbarbs example simpler. But all the other gnuplot entities created by set <something> <tag> ... require that tag > 0. (linetypes, objects, labels, pixmaps, arrow,...) and treat tag=0 as an error.</tag></something> My intention is that the marktypes that the user can set with set mark are 0 and positive number. I want to reserve the negative number marktype for internal use, built-in marks, etc....
-
I had assumed that only the final code would be committed to the main branch once the discussion and specification work here had settled down. I apologize for the haste in getting things done. I also apologize for the sending many patch files in incomplete states. Thank you for reviewing codes deeply and committing the modified codes. 014_show_mark was a misunderstanding of what I tried to say earlier. I apologize for the confusion. The point I was trying to make was that gnuplot's show commands...
-
Some updates were made. 021_show_marks_datablock_handling.patch The handling of output to datablock in the 'show_mark()' function was corrected with reference to the 'new_block()' function. 022_save_marks_uses_pseudo_file.patch "save marks" output changed to use pseudo file as follows. set mark 1 '-' x1 y1 ... x2 y2 ... : : : e 023_careful_comparison_of_fillstyle_type.patch Changed to use '(style & 0xf)' for comparison with FS_EMPTY in response to changes made by 'commit 83e4eadb78c8e7a4a41ff9805d9052d42daa0ad3'....
-
Some updates were done. 021_show_marks_datablock_handling.patch The handling of output to datablock in the 'show_mark()' function was corrected with reference to the 'new_block()' function. 022_save_marks_uses_pseudo_file.patch "save marks" output changed to use pseudo file as follows. set mark 1 '-' x1 y1 ... x2 y2 ... : : : e 023_careful_comparison_of_fillstyle_type.patch Changed to use '(style & 0xf)' for comparison with FS_EMPTY in response to changes made by 'commit 83e4eadb78c8e7a4a41ff9805d9052d42daa0ad3'....
-
The show_mark() function introduced in ‘014_show_mark.patch’ had a bug regarding the initialization of the datablock variable. A patch to fix this bug is attached. 019_BUGFIX_initializing_datablock_in_show_mark.patch EDIT Sorry, it is found that this patch can't fix the bug. SEGV was occurring when loading a lot of data into set mark. The cause of the bug was that the fillstyle member of the mark_data struct was not properly handled in the mark's reallocation when loading data in set mark. The attached...
-
The show_mark() function introduced in ‘014_show_mark.patch’ had a bug regarding the initialization of the datablock variable. A patch to fix this bug is attached. 019_BUGFIX_initializing_datablock_in_show_mark.patch EDIT Sorry, it is found that this patch can't fix the bug.
-
The show_mark() function introduced in ‘014_show_mark.patch’ had a bug regarding the initialization of the datablock variable. A patch to fix this bug is attached. 019_BUGFIX_initializing_datablock_in_show_mark.patch
-
Attached are multiple patches including the bug fixes that address your "Comments/problems 29 April". I believe many of the features you have noted so far have been implemented in these patches. Hopefully this will help us finalize the 'marks' style specification. 012_BUGFIX_for_Apr_29_comments.patch This patch addresses the following bugs. missing "break" statement after set.c:371 set_mark(); mark symbols are not drawn in the key if the key is outside the plot comment in plot_marks "stored in yhigh"...
-
Sorry. The bug occurred in the 'set_mark' function when replacing a newly constructed mark with an existing mark with the same tag number. No special processing was done as required if the mark to be replaced was the first element in the mark list. Please look at the attached patch file, 011_BUGFIX_special_treatment_of_replacing_first_mark_in_mark_list.patch
-
Difference between show and save Please follow the current practice used by the rest of the program: save_FOO() can write either to a file or to stderr. show_FOO() always writes to stderr. As an implementation convenience, show_FOO() may be implemented internally as save_FOO(stderr). In the current implementation, the 'save' command does not support marks at all. It would be helpful if you could advise what output would be desirable. Simply put, the output could be something like. set mark 1 ‘-’...
-
Five small patch files include the responses to your point about ‘Code consolidation’ and ‘Limitation of set mark’ are attached. 006_add_empty_option_for_set_mark.patch This introduces a new syntax for explicitly defining an empty mark. set mark <tag> empty In the future, this feature may be removed if it proves unnecessary. 007_consolidate_codes_as_get_mark.patch This is a patch to address your point "Code consolidation", defining the 'get_mark()' function and refactoring 'graphics.c' to use it....
-
Thanks for the patch, I was worried about interference using lp_parse as no other plotting style has both POINT and FILL styles at the same time. As there doesn't seem to be any major problem, I agree to apply your patch. The execution of 'Fig11_formulas.gp' failed, but this is due to a restriction on the word order of the options, caused by introducing of 'lp_parse'. # NG. 'with marks mt k ps 1 fs solid 0.0 border lw 1 ' ^ ## OK 'with marks mt k ps 1 lw 1 fs solid 0.0 border ' ^ Additional modifications...
-
Attached '002_ps_variable.patch' is a patch file againt 'gnuplot_marks.patch' + '001'. This patch add the 'ps variable' handling.
-
variable mark size in a plot My understanding, perhaps wrong, was that set mark does not specify what the coordinate units are, so this must be added later by the units keyword in a plot or set object command. Your description is correct! And "units ps" is the default in the current implementation. In addition, pointsize defaults to 1.0. So if I want the mark to be interpreted in terms of point size units in a plot command I say plot using 1:2 with marks units ps to use a scale factor of one, and...
-
I like that it is terminal-independent. This means it can replace the recent commit series 6bc3c0eb..edcd8dbb that added a small number of terminal-dependent special point types. The functional equivalence is shown by Figure 3. As noted in the patch documentation, there is a notice regarding this. In gnuplot, drawing to terminals is done using scaled integer coordinates per terminal. If the scaling is not sufficient for bitmap terminals or even vector terminals in some cases, the mark shape may be...
-
Attached '001_change_mode_default.patch' is a patch file againt 'gnuplot_marks.patch' This patch changes the drawing style for mode=0 to follow the fillstyle setting. Edited It seems the patch did not successfully attach. Sorry. I attached file.
-
Attached '001_change_mode_default.patch' is a patch file againt 'gnuplot_marks.patch' This patch changes the drawing style for mode=0 to follow the fillstyle setting.
-
The "mode" parameter is not a good idea, given that gnuplot uses fillstyle everywhere else to control the fill and border propertie. "mode" is both confusing and less capable than allowing a fillstyle to be attached to a mark object or to a plot "with marks". I do realize that there are several wrinkles here. A mark that consists of a polyline does not necessarily have either a "fill area" or a "border", so some adjustment to the terminology may be needed. If this ends up requiring an addition or...
-
"set mark 3 $triangle fillcolor 'blue'" This command is accepted but so far as I can see the color has no effect. Is there a way to set a fixed, or at least a default, color for the mark? I would rather not accept such an option, but how can I implement this? To give the mark a fixed color, specify fillcolor as an integer in the fourth column of the input data. If you give this column a value of -1 (the default value), it will use the fillcolor or linecolour setting; as with polygons, you can specify...
-
"show mark" command I think "3" means fill+border? Please switch to using a fillstyle. Yes. As you say, "3" means fill+border, but it is inappropriate as the default value for mode. In the code at hand, the default value of mode has been changed to follow the fillstyle. Also change the mode value as follows. mode(0) FILLSTYLE mode(1) STROKE ONLY mode(2) FILL ONLY mode(3) FILL AND STROKE What is the "-1"? "-1" means the fill color using a fillcolor or linecolor setting. Would it be feasible to report...
-
I have just posted an announcement of the creation of this ticket to gnuplot-beta. plot with linesmarks I realize that this was already an issue for "plot with linespoints", but the current program design isn't flexible enough to permit specifying both a complete set of line properties and a complete set of point (or in this case mark) properties in a single plot component. Is it really so bad to require "plot <foo> with lines, '' with marks" rather than providing a separate plot style that combines...
-
new plotting style 'marks', 'linesmarks' and new object 'mark'
-
No warn for calling of plot (via function block) in invalid context
-
"binary_blank_if_NaN.patch" has been applied to my environment and confirmed to work. So if the first column contains NaN, the record is considered a blank row. I am satisfied with this behaviour, without the need to modify plot3d_polygons!
-
Thank you for working on this matter. Your solution with the keyword option blank=NaN is preferable and sufficient for me. I like the fact that this method is only valid when a break line with NaN is required and has no side effects in other cases. Another good part is that it can be applied to cases other than polygons. There are certainly plotting styles that treat NaN as valid data (hsteps), so I agree with the solution by introducing this keyword option.
-
Sorry. Attached is my test script.
-
Thank you for the detailed explanation. I now understand the direction regarding colour fills in Version 6. Unrelated to this ticket, but regarding fillcolor, I sometimes encounter a bit strange behaviour in 2D plots: with circles, for example, only the fourth plot in the script below does not work as expected. It seems that the colour filling behaviour may be sensitive to the positional relationship between fillcolor and fillstyle. I have been unable to determine whether this is a bug or a specification,...
-
I am attaching a sample script. Sorry for the insufficient verification. * lc variable NG 5.4.8 OK 6.0.0 OK develop * fc rgb variable NG 5.4.8 OK 6.0.0 OK develop * lc rgb variable NG 5.4.8 OK 6.0.0 NG develop I didn't notice because I usually work with the develop version, but 'lc rgb variable' worked fine in 6.0.0. On the other hand, 'lc rgb variable' does not work in the develop version. Maybe there was a change somewhere that made it not work. So it might be better to investigate the above changes...
-
Allows input from binary data for 'splot with polygons'
-
Enabling the use of 'lt rgb variable' in 'splot with polygons'
-
A Google search for the keywords "volunarability com_line command.c" will find the page "https://nvd.nist.gov/vuln/detail/CVE-2020-25412". The vulnerability listed on this page is related to [bugs:#2303]. Is the SentinelOne's warning related to this? If so, it is likely to have been fixed in later versions.
-
Replotting in v6.0.0 doesn't remove the original plot first
-
If your goal is to get the same output as v5.4.10.png using gnuplot 6.0.0, it might work by replacing set style fill solid transparent 0.10 noborder with set style fill solid 0.10 noborder This would mean excluding transparency from the fill attribute for the filledcurves style. You will probably get similar results on both png and pngcairo terminals. If a transparent v6.0.0.png is preferable, and simply overlaying by replot is a problem, then it is better to adopt the suggestion by Ethan not to...
-
As an another approach, if I add the transparent option to 'set term png ', 5.4 outputs similar results as 6.0. Could this be related to the following commit? commit a72cb572040360ff80932d7981cccdd893bac897 Author: Ethan A Merritt <merritt@u.washington.edu> Date: Fri Jan 13 13:53:38 2023 -0800 png (gdlib): Change default to "set term png butt truecolor" Newer gdlib versions do a much better job of antialiasing, but only if truecolor is selected. On the other hand our previous workaround for bad antialiasing,...
-
I am only one of the homebrew users, but I would like to comment. Unfortunately, gnuplot installed with homebrew only supports qt as an interactive terminal, x11 and wxt are disabled. Before homebrew version 2.0.0 it was possible to enable x11 using the install option, but now that option is gone. Because of this situation, I build gnuplot myself. For reference, when using Xquartz, I pass the following options to configure --with-x --x-includes=/opt/X11/include --x-libraries=/opt/X11/lib To build...
-
For what it's worth, I think "smooth cspline" is also inappropriate as an extrapolation method. Even for interpolation it can exhibit severe overshoot, which is why I thought it was important to add "smooth mcs" (splines with monotonic constraints) as an alternative. The 'mcspline' story was very informative. I would like to use it in the right situation. Thank you again.
-
I think that is a good idea. If I could get the original poster's opinion, there may be a use for it that I am unaware of. Also, it may be a feature that most people don't need.
-
Thank you for your comments. My starting point is that gnuplot should help you to visualize your data and to present it clearly to others. From that perspective it is important to show the actual data points; I do not like the idea of resampling, especially when there are only a few data points. Does this mean that this is a general opinion, not limited to 'smooth linear'? I understand that if the data is unequally spaced or the sampling is out of phase with the original equally spaced data, the...
-
Have you tried looking at variable ARG0? test.gp: show variables ARG print "Script name is " . ARG0 This script produces output like Variables beginning with ARG: ARGC = 0 ARG0 = "test.gp" ARGV = <0 element array> ARG1 = "" ARG2 = "" ARG3 = "" ARG4 = "" ARG5 = "" ARG6 = "" ARG7 = "" ARG8 = "" ARG9 = "" Script name is test.gp My environment is gnuplot 5.4.8 installed via Macports on MacOS.
-
Have you tried looking at variable ARG0? test.gp: show variables ARG print "Script name is " . ARG0 This script produces output like Variables beginning with ARG: ARGC = 0 ARG0 = "test.gp" ARGV = <0 element array> ARG1 = "" ARG2 = "" ARG3 = "" ARG4 = "" ARG5 = "" ARG6 = "" ARG7 = "" ARG8 = "" ARG9 = "" Script name is test.gp
-
Thank you for your comment. When I read the original post, the feature I wanted was not the ability of arithmetic computation between two spectra, but simply linear resampling. I may have posted this in the wrong place. I did not want to discuss in depth with you about the arithmetic computation between two spectra. As for linear resampling, it is the most basic interpolation of observed data. To begin with, drawing discrete data with lines is itself linear interpolation. My 'sample3.gp' is an realistic...
-
Thank you for your comment. As for linear resampling, it is the most basic interpolation of observed data. To begin with, drawing discrete data with lines is itself linear interpolation. My 'sample3.gp' is an realistic example of what I consider the most important in this Feature. The idea is to get an inverted grid of monotonic observed data. I prepared pseudo data for this example due to licensing issues, but the process would be the same with real data.
-
Revised patch file (v2) with the following changes Placed codes in 'filters.{c,h}' instead of 'interpol.{c,h}' Use 'cp_extend(plot,0)' instead of 'free(plot->points)'
-
Although the plot command is a bit verbose, this feature can be emulated by the 'sectors' style introduced in gnuplot version 6. The sector style is designed to draw annular segments. But if the sector angle is greater than 360 deg, it is designed to draw perfect annulars. And then, by setting the inner radius of annular to 0, a perfect circle can be drawn. Please check help document of the 'sectors' style for details. Here is a sample script executable with gnuplot 6.0rc1. # # Drawing a circle whose...
-
Although the plot command is a bit verbose, this feature can be emulated by the 'sectors' style introduced in gnuplot version 6. The sector style is designed to draw annular segments. But if the sector angle is greater than 360 deg, it is designed to draw perfect annulars. And then, by setting the inner radius of annular to 0, a perfect circle can be drawn. Please check help document of the 'sectors' style for details. Here is a sample script executable with gnuplot 6.0rc1. # # Drawing a circle whose...
-
I think this Feature Request is reasonable. I would like to have this feature, so I implemented it. A patch file is attached. Any comments are welcome. About 'smooth linear' filter I imagine 'smooth linear' is rarely used for smoothing during drawing. Instead, as the title of this Feature Request suggests, it will most often used for data resampling. Therefore, I did not position 'smooth linear' as a derivative of existing spline interpolations, and I implemented it consciously so that it is easy...
-
Thank you for your quick fix. Even after this workaround, another problem with GNUTERM still remains. The following example is not at all normal usage, but it can cause gnuplot to fail even if 'set term wxt' is valid command. GNUTERM="wxt; plot '+'" gnuplot For terminal initialization using GNUTERM, 'do_string()' which is a gready eater is called and allows command injection. To prevent such command injection, I came up with a workaround that only the first part of which the GNUTERM string is separated...
-
Failt caused by combination of invalid GNUTERM value and psuedofile "+"
-
SEGV caused by combination of invalid GNUTERM value and psuedofile "+"
-
SEGV caused by combination of invalid GNUTERM value and psuedofile "+"
-
The candlestick style also provides you with simpler solution than the boxxyerror style. load "polybench.plot" unset arrow set output 'polybench-candlesticks.pdf' set boxwidth 0.5 set title "Boxed bars (narrow width)" plot "polybench.dat" using 0:(1):(1):2:2:xtic(1) with candlesticks,\ 1 with lines lt -1 set title "Colorize" plot "polybench.dat" using 0:(1):(1):2:2:($2>=1?0xff0000:0x0000ff):xtic(1) \ with candlesticks fc rgb variable fill solid 0.5,\ 1 with lines lt -1
-
The boxxyerror style is quite versatile. As Ethan pointed out, with hsteps is a style only in the development version, but I believe it can be suitable for your request. Building on the example code provided by Ethan, I'd like to showcase various plot variations using with hsteps. load "polybench.plot" unset arrow set output 'polybench-hsteps.pdf' set title "Continuous bars (full width)" plot "polybench.dat" using 0:2:(1):xtic(1) \ with hsteps y=1, \ 1 with lines lt -1 set title "Separated bars (full...
-
Small modification patch. For the purpose of eliminating instability of determination if there is a gap between adjacent horizontal line segments caused by floating-point rounding errors, I would like to change the determination method of gap to use terminal coordinates (mapped by map_x). As a side effect, line segments that are close to the smallest unit of terminal coordinates are assumed to have no gap. And such behaviour depends on the resolution of the terminal.
-
Additional fix patch for v5 (and master branch) This is a patch to correctly handle the 'lc variable' option and border color in hsteps, fillsteps, and histeps. Sample script code is also attached.
-
Many thanks for all the advice. As a result, the syntax and code have been simplified. Most of the features I requested have been implemented. Comments on the document If not provided in the plot command, the baseline is take to be y=0. 'the baseline is taken to be y=0.' ? pillar: At each end of each step a vertical line is drawn to the baseline. Note that no horizontal line segments are drawn at the baseline. set style data hsteps pillar y=0 In the document for 'pillar' variant, the sample code...
-
It appears that autoscaling in the y-axis direction fails if 'offset' option is used. An additional patch to improve this is attached.
-
Hsteps Version 5 looks good to me. I am willing to add it to the development branch, and I have started to adapt your documentation and some of the figures for inclusion in the user manual. Thank you for letting me know. Question How useful is the new command set style {data|function} hsteps {options} in practice? I realize that you modeled it on the equivalent command for filledcurves, but I discovered to my surprise that the filledcurves style command has never been documented! So probably very...
-
I have been unable to find any generic name for plots that exactly match this style. The best I can come up with to describe what the individual steps look like after adding the left+right edges but removing the connection along the baseline is pillars. I thought 'box' would be confusing with 'boxes'. I feel that 'pillow' is a good choice because it also has the image of being grounded (to the baseline). I am attaching patch v5 which changes the 'split' keyword to 'pillow' and merges the changes...
-
I suggest to keep the emulated code. Thanks for your advice. OK, I will revert the histeps emulation code to the initial one. On top of that, I would like to add the explicit fillstyle option to histeps as well. Next, about 'split': I think 'split' should be an exclusive option with 'baseline/link/nolink', which is an option to specify the shape of the connecting line. If so, a better word for the shape of the connecting line should be like ' sides', 'sidewalls' or 'edges', which should have the...
-
I suggest to keep the emulated code. Thanks for your advice. OK, I will revert the histeps emulation code to the initial one. On top of that, I would like to add the explicit is fillstyle option to histeps as well. Next, about 'split': I think 'split' should be an exclusive option with 'baseline/link/nolink', which is an option to specify the shape of the connecting line. If so, a better word for the shape of the connecting line should be like ' sides', 'sidewalls' or 'edges', which should have the...
-
Thank you for your sample script. Your sample script really shows that the 'histeps' style is "similar but much different" to 'hsteps'. And my 'sorting step' implementation for trying also failed to reproduce the plots using your sample script :-( So I came to realise that the 'histeps' implementation should remain the original code, not an emulation for compatibility reason.
-
Thank you for indicating the canonical usage of histeps. Although the sorting step can be implemented in the emulation of 'histeps', I think it is not needed to include the sorting step in the emulation of 'histeps'. Instead, the behavior that the 'histeps' skips the empty line or invalid data should be emulated. The attached small patch for v4.1 supports the emulation of skipping the undefined or invalid data. The following script is an example to demonstrate the difference. $data <<EOD 1 5 2 8...
-
Incompatibilities in 'histeps' regarding sorting of input data still remain. The 'histeps' documentation does not contain any description of input data sorting, which has been an undocumented behaviour. If the "input data sorting" behaviour of the 'histeps' style needs to be retained, it may be better to remove the 'histeps' style from the emulation by 'plot_hsteps()' function and revert to use the existing 'plot_histeps()' function.
-
Minor fixes for the emulation after patch v4. Fixed a mistake in which the 'steps' emulation was set to have baseline introduced in patch v3. Fix for the 'fillsteps' emulation's '{above|below}' option not working. The value of point.z was changed from 0 to -1, meaning "default width". This makes the value of point.z common between hsteps in the case of "default width" and emulation. The attached files are patch v4.1 and the difference between v4 and v4.1.
-
Thank you for your patches and comments. handles the 'set style {data|function}' case for emulation of older plot styles Did not merge due to the integrated set style data/function support described later. deals with compiler warnings for unused variables and unused code. Also allows a keyword "baseline" to describe the default state baseline/link/nolink Merged. The key sample does not always match the plot style options. Fixed. The choice of color in these same cases is also unexpected. Maybe fixed....
-
Thank you for your comments. I initially expected that "hsteps above/below" would only affect the fill area. Having it also affect the border is not terrible; but it's not what I expected. If you don't mind, I would like to revert to patch v1 behavior for drawing 'above/below'. And I would like to leave open the possibility of changing to v2.1 behavior if there are problems by the time of release. There are lots of cases where if you set a parameter to NaN it will produce a bad plot. Consider set...
-
The first plot in existing demo timedat.dem , which using "with fsteps", fails to reproduce previous output. Indeed, the current code only prepares for the emulation of "steps/fsteps/histeps/fillsteps" in the parsing of 'plot ... with'. The macro CHECK_BASELINE_OPTION() is called repeatedly, but I do not understand why this check is necessary at all. I checked that 'y=<baseline>/above/below' should be prohibited when link/nolink is specified, as the baseline is undefined. Multiple CHECK_BASELINE_OPTION...
-
Thank you for your positive comments regarding the 'split' keyword. Aside from that, I would be very pleased if you could look at patch v2.1, which includes various fixes.
-
I removed the 'split' keyword in patch v.2, and I wrote, Why would one ever use this rather than "with boxes"? It was implemented with the intention of being used with vsteps. But, in the new patch, the split option has been removed along with the removal of vsteps. Sorry, but, there are some examples to describe I needed this option, although you might feel it is a slight difference. Please, check the following sample codes which show the different aspect of 'hsteps split' from 'boxes'. First example...
-
I changed the above/below behavior as Ethan mentioned. But, I want to revert it as in original patch (v1). That is, the above/below option restricts the border drawing area as well as the fill area. This is because expression through v1 behaviour is more flexible than v2 behaviour. First of all, the second figure of Ethan's attached file 'above_below.png' is somewhat incorrect regarding the handling of baselines. The option 'above y=2.5' defines the lowest limit of filling at y=2.5 and simultainously...
-
I changed the above/below behavior as Ethan mentioned. But, I want to revert it as in original patch (v1). That is, the above/below option restricts the border drawing area as well as the fill area. This is because expression through v1 behaviour is more flexible than v2 behaviour. First of all, the second figure of Ethan's attached file 'above_below.png' is somewhat incorrect regarding the handling of baselines. The option 'above y=2.5' defines the lowest limit of filling at y=2.5 and simultainously...
-
I changed the above/below behavior as Ethan mentioned. But, I want to revert it as in original patch (v1). That is, the move/below option restricts the border drawing area as well as the fill area. This is because expression through v1 behaviour is more flexible than v2 behaviour. First of all, the second figure of Ethan's attached file 'above_below.png' is somewhat incorrect regarding the handling of baselines. The option 'above y=2.5' defines the lowest limit of filling at y=2.5 and simultainously...
-
Here is patch v2.1 which fixes some bugs in patch v2. v.2 -> v2.1 fixed broken fillsteps emulation fixed double free of 'plot->points' array fixed memory leak of 'state' and 'gap' array
-
I changed the above/below behavior as Ethan mentioned. But, I want to revert it as in original patch (v1). This is because expression through v1 behaviour is more flexible than v2 behaviour. First of all, the second figure of Ethan's attached file 'above_below.png'. The option 'above y=2.5' defines the lowest limit of filling at y=2.5 and simultainously it defines the baseline at y=2.5. Anyway, the second figure in 'above_below.png' can be realised even in original patch (v1). array A = [2, 1, 6,...
-
A patch (v2) incorporating the content of the exchange so far and the revised documentation is attached. The main changes in patch v1->v2 are as follows, Specification remove vsteps style remove width keyword remove split keyword replace the role of y=NaN option to link keyword nolink also makes the baseline undefined Code revert the coordinate designation (u,v) to (x,y) use coordinate struct instead of histep_point struct introduce of pilot implementation of steps/fsteps/fillsteps/histeps emulation...
-
A patch (v2) incorporating the content of the exchange so far and the revised documentation is attached. The main changes in patch v1->v2 are as follows, Specification remove vsteps style remove width keyword remove split keyword replace the role of y=NaN option to link keyword nolink also makes the baseline undefined Code revert the coordinate designation (u,v) to (x,y) use coordinate struct instead of histep_point struct introduce of pilot implementation of steps/fsteps/fillsteps/histeps emulation...
-
A patch (v2) incorporating the content of the exchange so far and the revised documentation is attached. The main changes in patch v1->v2 are as follows, Specification remove vsteps style remove width keyword remove split keyword replace the role of y=NaN option to link keyword nolink also makes the baseline undefined Code revert the coordinate designation (u,v) to (x,y) use coordinate struct instead of histep_point struct introduce of pilot implementation of steps/fsteps/fillsteps/histeps emulation...
-
A patch (v2) incorporating the content of the exchange so far and the revised documentation is attached. The main changes in patch v1->v2 are as follows, Specification remove vsteps style remove width keyword remove split keyword replace the role of y=NaN option to link keyword Code revert the coordinate designation (u,v) to (x,y) use coordinate struct instead of histep_point struct introduce of pilot implementation of steps/fsteps/fillsteps/histeps emulation The following is a short reply to the...
-
A patch (v2) incorporating the content of the exchange so far and the revised documentation is attached. The main changes in patch v1->v2 are as follows, Specification remove vsteps style remove width keyword remove split keyword replace the role of y=NaN option to nobase$line keyword Code revert the coordinate designation (u,v) to (x,y) use coordinate struct instead of histep_point struct introduce of pilot implementation of steps/fsteps/fillsteps/histeps emulation The following is a short reply...
-
Thanks for the reply. The intended drawing target of the hsteps style is a staircase curve drawn with continuous data, like steps, fsteps and histeps. Due to my greed, there are variations in the shape of the connecting lines, but basically, the style is for drawing curves. Therefore, the hsteps style implements functionality similar to fillsteps and filledcurves concerning filling. So I think you expected a hsteps style border to have a box border as drawn with boxes or histogram because I did not...
-
Thanks for the reply. The intended drawing target of the hsteps style is a staircase curve drawn with continuous data, like steps, fsteps and histeps. Due to my greed, there are variations in the shape of the connecting lines, but basically, the style is for drawing curves. Therefore, the hsteps style implements functionality similar to fillsteps and filledcurves concerning filling. So I think you expected a hsteps style border to have a box border as drawn with boxes or histogram because I did not...
-
New plotting style 'hsteps' and 'vsteps'
-
What you want to draw seems to be a heatmap of equally spaced grids, regardless of whether the axes are log-scale or not. Here is a method to generate matrix indexes using pseudo columns in the using specification and using the xtic() and ytic() to use x, y values from data file as axis tic labels. # retrieving record number of first block stat 'data.txt' every :::1::1 nooutput NY = STATS_records # defining macros rowidx = '(column(-1))' colidx = '(int($0) % NY)' xtstr = '(@colidx == 0) ? strcol(1)...
-
Thank you for taking the time to stop and consider this issue. Based on the information you provided, I have come up with one crossplatform modification. The outline is as follows. As it is now, adopt the method of rendering colorbox as image. Only if maxcolors is given, oversample steps by a multiple of maxcolors so that steps is around 1000. Since we are only embedding image data (1000x1 pixels), there should be no performance impact due to oversampling. Attached is a patch file, a script for checking,...
-
Thank you for taking the time to stop and consider this issue. Based on the information you provided, I have come up with one crossplatform modification. The outline is as follows. As it is now, adopt the method of rendering colorbox as image. Only if maxcolors is given, oversample steps by a multiple of maxcolors so that steps is around 1000. Since we are only embedding image data (1000x1 pixels), there should be no performance impact due to oversampling. Attached is a patch file, a script for checking,...
1 >