forums.silverfrost.com

Kenneth_Smith · Posted: Fri Sep 01, 2023 12:12 pm Post subject: %pl dx and dy values

Question, is there a way to interrogate the clearwin data to determine the currently applied %pl dx and dy values?

I think I already know the answer as I cannot see a documented function something like: GET_PLOT_DBL@(id, option, index, fval), but it may exist?

Ken

Kenneth_Smith · Posted: Fri Sep 01, 2023 3:24 pm Post subject:

I am unable to remove my first post of today, something went horribly wrong. Perhaps the forum admin can do this?

The question above, stems from the code at the link below, which shows that the value returned by change_plot_dbl@ to adjust dx is always zero, even when the requested change is not made (maybe a silly value, or a value which would cause the text to overlap depending on the plot aspect ratio).

If a non-zero value was returned (as implied in the documentation), the code could detect this and "try again" with an alternative value. Consequently, the fortran code cannot keep track of the current dx value.

This means that if I use %pl without gridlines, if I then draw the grid lines within the %pl call back, the dx spacing may, or may not correspond to the value that was specified in the last call change_plot_dbl@ for dx.

At the moment, I cannot see a way to ensure that the %pl call back uses the correct dx value when drawing the vertical gridlines, i.e. aligned with the numbers on the x axis.

I was not initially looking at the return value from change_plot_dbl@ when I observed this occasionally occurring, and I thought the return value would provide a solution, but this does not appear to be the case.

Same issue can occur with the dy value.

Is this a possible bug in change_plot_dbl@ ?
https://www.dropbox.com/scl/fi/or7hmrqffpb2jpduhsjy3/dxproblem.f95?rlkey=rflboeyfatxygn50qbopqfdr9&dl=0

PaulLaidler · Posted: Sat Sep 02, 2023 7:54 am Post subject:

Ken

I have tested your sample program.

After clicking the CB4 button I get -521, -511, -501 on the x axis. The same for both 32 and 64 bits.

Am I missing the point?

Kenneth_Smith · Posted: Sat Sep 02, 2023 11:05 am Post subject:

Paul,

I knew this would be difficult to explain.

You and I can, but the fortran code cannot view the graph, so how can the code keep track of the presently applied dx value after the last call to change_plot_dbl@, since this always returns zero?

Consider the sample program (which is rather artificial), where CB1 and CB5 are called in sequence.

When the window is formed, %pl is setting its own xmin, xmax, and dx.

After the call to CB1 Xmin, and xmax are changed to “nice” values i.e. – 520 and -500.

After the call to CB5 which fails to set the dx value to 20, the more complex / extended program logic thinks the values are:

Xmin = -520 Xmax = -500 dx = 20

But in reality they are:

Xmin = -520 Xmax = -500 dx = 10

Additional code, which now attempts to draw the vertical grid lines based on a dx value of 20 which it thinks has been applied, means that the grid line which is required in the actual grid produced (with dx =10) at Xmin + dx = -520 + 10 is omitted. The resulting graph is shown below:

https://www.dropbox.com/scl/fi/417081clejrz4lo9smgzo/missing_dx.JPG?rlkey=efqq4ybp4nk87yod2e01e8s88&dl=0

This is the issue which started me off looking at the return value from change_plot_dbl@.

Perhaps the solution to my problem is simply to prevent the case where dx = (xmax – xmin) ever occurring, but that may generate another problem when the x/y grid aspect ratio is low (x axis becomes cluttered). I will explore this further. (An even simpler solution, remove the option to redraw the grid lines and use the default %pl gridlines, but they become somewhat lost under all the other data in the graph.)

I’m now curious, under what circumstances does change_plot_dbl@ actually return a non-zero value?

Kenneth_Smith · Posted: Sat Sep 02, 2023 12:03 pm Post subject:

This may better illustrate the issue.

Kenneth_Smith · Posted: Sat Sep 02, 2023 2:05 pm Post subject:

Issue now resolved by changing slightly the code that selects the desired xmin, xmax and dx values.

Examining the value returned by change_plot_dbl@ was the wrong path to follow, although it seemed logical on Thursday morning!

A very presentable contour plot:

https://www.dropbox.com/scl/fi/ybmjm965j7yghmdif8nve/dxdy_fixed.JPG?rlkey=necdjvj9h8gu7dykuxqzas2sp&dl=0

PaulLaidler · Posted: Sat Sep 02, 2023 2:21 pm Post subject:

It looks very impressive.

Kenneth_Smith · Posted: Thu Sep 07, 2023 8:56 pm Post subject:

Paul,

I have looked at this a little more closely, as my "fix" fails in one test.

In the following code, the failure of change_plot_dbl@ to change the dy value is demonstrated.

There are three %pl regions which are created sequentially. In each case the pl graph frame is initially the unit square. The callback associated with the button CB, calls change_plot_dbl@ to change the following values:

x_min = -5, x_max = 5, dx = 5, y_min = -5, y_max = 5, and dy = 5

and thereafter calls simpleplot_redraw@.

The code works as expected for the first two cases, but fails in the final case where the plotted dy value is 2.5 rather than the requested 5.

The only difference is that the final case has the %pl margins explicitly specified via a call to winop. The presence of this margin specification appears to be the cause of the problem.

Kenneth_Smith · Posted: Fri Sep 08, 2023 12:28 pm Post subject:

The solution to the last problem is to ensure that the ratio of (top margin + bottom margin)/graphics_height is greater than 0.2

PaulLaidler · Posted: Sat Sep 09, 2023 6:54 am Post subject:

Thanks for the feedback Ken.

Here is some background information for the general reader.

The functions CHANGE_PLOT_INT@, CHANGE_PLOT_DBL@ and CHANGE_PLOT_CHR@ return the integer value zero on success. Other values indicate an error. These functions change the data but the user will need to call a routine like SIMPLEPLOT_REDRAW@ in order to redraw the graph. At that point the graph ought to be redrawn in the form that would appear if the new data had be used at the outset.

Kenneth_Smith · Posted: Wed Sep 13, 2023 11:02 am Post subject:

This may help to identify the source of the problem.

The same issue can be replicated without calling CHANGE_PLOT_DBL@.

PaulLaidler · Posted: Wed Sep 13, 2023 12:05 pm Post subject:

Ken

I have logged this issue for investigation.

PaulLaidler · Posted: Thu Sep 14, 2023 8:22 am Post subject:

Ken

I can see in the ClearWin+ code where this value is limited but a change might affect user's existing code.

I have added an option CLEARWIN_OPTION@("no_pl_dy_limit") that will allow you to experiment with this internal limit removed.

Our code changes are currently locked pending a full release so if I send you the update now it may be out of step with the next release.

I could send you updated DLLs on this understanding.

Kenneth_Smith · Posted: Thu Sep 14, 2023 11:23 am Post subject:

Paul,

Yes, the "no_pl_dy_limit" is probably the solution I am looking for. I have tried, but failed to work out the functioning of that limit which I have long suspected is in the Clearwin code.

A "no_pl_dy_limit" would certainly provide a solution to an issue encountered previously. A common range in the electrical world for % voltage is y_min=97.5, y_max=102.5, and most power transformers have a 1.25% taps on the HV side, so dy = 1.25 and it is not possible to use these values in a %pl plot.

I am certain the dy increment value I am requesting is reasonable, but I guess what is reasonable, may be a moot point!

If you could provide a 64 bit dll, I can experiment with that. Issues with upcoming full release understood. Many thanks for taking the time to look at this.