forums.silverfrost.com

[DanRRight]

[silicondale]

John - I puzzled over the white space at the top in the 256-colours case, as well. But the explanation is quite simple. The plots represent x,y,value where the value is mapped to a colour. The data set is ordered by value, and mapped to colours so that there is (as far as possible) an equal number of points of each colour. In the 128-colour case all of the points are plotted as coloured squares. In the 256-colour case, the first half of the points map to colours 1 - 128. The second half of the points should map to colours 129 - 256 but in fact plot as black squiggles. Most of the high values are at the top of the plot. This plot shows sonar reflections and these are strongest at the top nearest to the sonar pinger. So what should plot as coloured squares near the top of the plot instead gets displayed as curved bezier lines all over the plot since the order of the x,y coordinates is completely arbitrary. You can see what happens in the 240-colour case where the higher values disappear and are replaced by curved lines.

Also showing the colour ramp - the only colours that ever get plotted are those in the left-hand half, blue to green.

I'm not sure why the lines in the 256 case don't go right to the top, but I guess by that stage the system has its knickers so twisted that the bezier curve fitting algorithm is itself struggling.

But why is the default setting black curved lines with no symbol ?
_________________
(Steve Henley)

[DanRRight]

Steve, Without demo I'm always puzzling what is done and what the problem is. Hopefully Paul gets that and will react. But if it looks like not many people are interested the solution may take longer time. In graphics typically always possible to make relatively small demo.

[silicondale]

John - we don't yet have the 255 limit version: I guess that will come with the next clrwin DLL release. I could do a 255 test but I think it will look very like the 256. Anyway, if I can use a 255-colour ramp instead of 256, not a basic problem. And I guess we have to accept Paul's statement that we are tied to some existing limitations in underlying code - at least for now. A matter of priorities, dependent on how many users want particular upgrades. It's the "art of the possible" and from my own viewpoint I am quite happy for now that Paul has been very responsive and helpful.
_________________
(Steve Henley)

[silicondale]

Good point, John. And interesting results. It blows up ! Two plots from two runs of the same program, same parameters, both using 255 colours.



I ran the program several times. Got these two plots, but also two or three times it blew up or hung without producing any plot at all. I guess this is the sort of unpredictable behaviour you might expect when exceeding array limits. Would be helpful, however, to have some check within the %pl coding to prevent it, and instead give some proper error message.
_________________
(Steve Henley)

[Kenneth_Smith]

A minor suggestion.

We have the subroutine get_plot_point@(x1,y1,xx1,yy1) which returns the pixel coordinates xx1, yy1, of the real world data x1, y1.

It would make programming interactively with mouse clicks etc on a %pl graphics area easier if there was a second subroutine which performed the reverse function, i.e. given pixel coordinates xx1, yy1, returns the real world coordinates x1, y1. I know this functionality can be achieved in otherways, but this complicates the programming.

Just a thought.

Ken

[Kenneth_Smith]

And another suggestion, maybe a way of detecting the first call to the %pl call back function via CLEARWIN_STRING@( STR )

Ken

[PaulLaidler]

Ken

The routine that you want is already included but perhaps not yet released.

The clearwin_info@("CALLBACK_REASON") for a %pl callback is "PLOT_ADJUST". I guess that the user's code could flag the first call.

[silicondale]

Hi, John-S: 30 years ago I implemented an interactive graphics system that did exactly that, all in standard Fortran77. I'll see if I can find the low-level parts of the coding (should still have it somewhere). However, it won't fit easily with %pl because it overlapped a lot with the Simpleplot / %pl functionality. There seems to be a lot of reinventing of wheels, because mine was far from the only package that did the same job.
_________________
(Steve Henley)

[DanRRight]

Paul,

I checked 8.30 with DLL23

Looks like for linear scale plots the placing of numbers on axis were fixed so that plot has now reasonable amount of numbers per axis and the numbers itself are not looking "bad".

The next would be great to fix bugs in LOG scale which are long overdue. The %pl then will be very useful tool. The examples of the bugs are described and pictured in detail in my last post on page 4 of this thread.

One more thing: a bug was introduced with the framed plot, you can see here that the thickness of the line of the frame is not the same:

[PaulLaidler]

The option [frame_pen=dval] now provides the line width of the frame where dval is the width.

If you can post or send me the code for the bug then I will aim to look into it when time permits.

[DanRRight]

Thanks for new option. As to the codes they are here, cited from page 4 above

[PaulLaidler]

Item 1 has now been fixed.
Improvements relating to item 3 might be possible later if time permits.

[DanRRight]

John,

1) There is no way to get not only production quality but any quality if axes_pen=1,width=1. But i agree my axes_pen=3, width=3 are probably too aggressive for anyone who uses less then 4K monitors. Try =2 and tell if that will look better (but take in mind that there is a bug with the frame width Paul just fixed)

So size=1 is too small for almost anyone but 3 are too large for anyone who use smaller resolutions. Of course with time all monitors will be 4K, 5K 8K, their prices dropped 10 times in last 3 years, i'v heard the first cell phone with 4k screen was just made. But the best solution which will fit everyone would be ( before it is too late and user base will be large) for Paul to consider the fp numbers for axes_pen and line width instead of integer numbers because antialiasing can allow any intermediate numbers like 1.4 and the plot automatically will look much better with line sizes larger then primitive 1 pixel

Though there might be people with low res monitors I strongly insist to not use 1 pixel for default, because no one in the world use that. Everyone who did all got out of business, just look at any packages of scientific graphics for Fortran over last 30 years supplied by such losers. While at the same time the Matlab for example almost killed all, taking lion part of the market share from Fortran. And when you will think why, you will find that the only what Matlab sells (having similar language with Fortran while Fortran is faster and more modern) all others missed is 1) ultimate simplicity 2) stellar graphics. Same was with Apple for example: ultimate simplicity, top parameters and stellar aesthetics. Same with Amazon: ultimate simplicity (one click orders), top convenience, good design. At the end anyone with very low res monitors can decrease line widths but for everyone else first look of the plot has to cause WOW effect (not the feelings that Fortran is the neanderthal's language like right now)

2) If i either decrease the plot size to zero by mouse resizing or minimize the plot it immediately crashes.

[DanRRight]

Paul, I hope you received on May 28 my email with demonstration of native PL crashing.