forums.silverfrost.com

[DanRRight]

Paul,

My answer could be surprising and i hope you will like it: with LOG scale you do not have to worry about limits or try to implement them. Just use for the LOG plots limits usual natural limits the plotting data has. Everyone doing exactly that as a #1 option and generally it looks very good with LOG plots.

The "exact decade limits" i posted two posts back here (or the ones posted by Ken earlier) is another options for LOG scale plotting but we used it as a hack only because currently LOG scale plotting has a bug and it can not use existing plotting data min and max as its limits. Or, saying more precise, it can use but has bugs there, so the tic marks all are wrong and plot itself often goes out of frame. Older Simpleplot %pl works fine here, see the source code and the picture i posted also here week or two back on page 9. Just implementing the same will solve most of our LOG plotting problems.


The "exact decade limits" can be done only temporally or as a second option. If you will do that like i or Ken posted then you have to take in mind that in my case i used restriction 1e-30 which is used only because %pl does not accept double precision numbers for the limits like 1d-50 or 1d150 (unless i am mistaken, and this was already fixed, i did not check this lately)

[PaulLaidler]

Silicondale

Item (2) has already been added for the next release.

[silicondale]

Paul - many thanks. I thought I had seen that.

Still the problem remains that if you have 10 or more separate sets of data to plot, the winio@('%pl',...) argument list quickly becomes very long and unwieldy. If using a colour-ramp as in my example a few posts back (Oct 16, 2017 12:36 pm), it would be impossible to use anything like the full set of colours available (maybe 255 or more).

Also you need to know beforehand exactly how many sets of data you want to plot - though of course you can define a maximum number and some of the x,y arrays can be zero-length.

These problems would both be avoided if each x,y point could carry its own attributes - symbol, size, colour, and type of link from the previous point - in separate arrays. If you could implement this, then the need for multiple arrays and use of N_GRAPHS and long argument lists can possibly be avoided altogether.

Having said all this - it's just suggestions for improvement. I think the native %pl is an excellent set of tools! It takes a lot of the pain out of plotting.

[Kenneth_Smith]

Paul,
I not sure that you get a consensus on what are "nice" limits with users coming from very different subject areas. The overall objective, which I think we could all agree on is to get acceptable limits for xmin and xmax, a reasonable dx value, and minimise the wasted space on the axis.

Here's my initial thoughts below on how this might be done for linear scales - see subroutine select_scale. This is based on the routine I mentioned previously (page 1), with the slight variation that the routine is called a number of times with different numbers of intervals to find a combination that limits wasted space.

For the log scales "exact decade limits" whilst not essential in general, would netherthelss be a valuable "option" for those of us working in the electrical power world.

Ken

[Kenneth_Smith]

[DanRRight]

Couple minor comments about LOG plotting (in the post above i was talking only about LOG plotting. Here I also do not touch linear plotting)

I use both exact decade limits in LOG plotting (i.e. rounding actual data limits to exact decade, for those who did not follow discussion above, or using 1 and 1000 limits if actual plotting data minimum and maximum are at, say, 3 and 500) and actual data limits (where limits are just data limits, or 3 and 500) in my own plotting for decades. There exist one negative property of exact decade plotting when displaying changing data in realtime. Imaging you drive the car and measure its speed: the plot permanently jumps when the data minimum or maximum switch to the next decade making you crazy. In my extreme electrical power world the operator will think that this was North Korean nuc attack on the power grid. With the actual data limits the LOG plot or the numbering move smoothly.

But there also exist one positive property of exact decade limits in LOG plotting and it is specific only to %pl: it is needed to prevent new %pl from switching to linear plotting if numbers get to zero or negative or crash. Same can be done though by additional call to winop@('%pl[y_min=some_min_value]').

There actually is nothing to debate or get a consensus in LOG plotting. The LOG plot numbering is MUCH simpler then LINEAR:

1) Ideally to get both options for LOG plotting: the actual data limits like in linear and log plotting in older Simpleplot and the exact decades limits. Do not see here any problems with the consensus among the users. May be just which option to make as a default. .

2) With just one option in %pl the user still can make exact decade limit plots from actual data limit plots as it was shown above, but one can not do the opposite due to bugs. The only what needed is to fix the scale, tics and numbering bugs in LOG native %pl and then reproduce one line code with LOG_LOG made in older Simpleplot %pl on page 9. This why wrote above that nothing new to do was needed given the fact how difficult the native %pl moving forward.

[DanRRight]

This is surfplot program demo made with native %pl done in 20-30 minutes.


It can display all 24bit gamma of colors and need less then 10 lines of code done in the function cb_Surfplot_plotting, the rest is just definition of function and usual GUI and XY plotting code. This is how simple to implement 2D graphics.

Few problems currently:
- Why it does not work with smaller resolution then 800x600 (try to resize it with mouse)?
- Why it does not like INCLUDE <clearwin.ins> and needs USE clrwin ?
- Why RGB colors inverted BGR?

Was stopped on these problems for 10x more time then these 20-30 minutes

[JohnCampbell]

Dan,

Thanks very much for the example. I have tried to learn from what you have presented and generated the following expanded version

[JohnCampbell]

../ctd
Questions:
1) compiling with /64 /check reports error with argument 7 (??) on:
i = winio@ ('%pl&',900,600,2,x,y)
I could not find the documentation of %pl for this call, which I expect is contained in this very long post. Is there a 7th argument ?
2) I needed to add
integer(7) handle
i = winio@ ('%hw', handle) ! return the handle of the current window
and
call UPDATE_WINDOW@(handle)
for my environment, so that the screen updated (when running in PLATO). Is this not a requirement for your test ?
3) Instead of using call DRAW_LINE_between@(ix,iy,ix,iy,iCol),
would draw_point@ (ix,iy,iCol) work as well ?
4) with "iCol = rgb@(0,0,ir)", why is the display red ? I checked z is in the range [0:1]

Again, thanks Dan for the example, as it does help to understand some of the devilry that you use.

John

[DanRRight]

John,
Have fun with that, glad you are joining growing crowd of living debuggers polishing new %pl, hopefully things will go faster.

By the way compiling with /64 /check gives me no errors and screen updates by itself if screen size is larger then 800 x 600. Thanks for the hint with window update, that solves the problem for smaller size screens

draw_point@ (ix,iy,iCol) is Ok. Also set_pixel@(ix,iy,iCol) works too but only in 32 bits

BGR colors order clearly is a bug.
Also both X and Y axis have range 0 - 1 but numbering mechanism by some reason made hell amount of numbers on Y axis

[PaulLaidler]

Silicondale

An option [stacked] has already been added. This avoids the problem of multiple arguments by allowing you to stack the y-values etc. for the various graphs into one array.

I guess that, for refined data (allowing each point to have its own symbol etc.) we could use an array of "user-defined" TYPE to provide the (x,y), symbol, etc. for each point in turn. If this suits your purpose then I will add it to the wish list.

[JohnCampbell]

Dan,

My "7th argument" error could relate to the .dll version I am using.
draw_point@ is no different to DRAW_LINE_between@

I looked at the problems of
1) colour for rgb@
2) speed of plotting ( which looks slow)
by defining a %gr region.
With %gr region, colour is fixed and also speed is much faster ( x20 faster )
I suspect these problems relate to using DRAW_LINE_between@ (ix,iy,ix,iy,iCol) in a %pl region, which may be reasonable ?

this is my %gr patched test (hope it posts - nope)

[JohnCampbell]

[DanRRight]

John,
Yes, i also noticed %gr is much faster. Why? This question is to Paul.
And the %gr version does not distort RGB. Here is the same code of your simpler edition where i made just two lines change and it turns to %gr surfplot. These two places are marked with exclamation sign

[PaulLaidler]

I don't know. At a quick glance neither is using smoothing (GDI+).