Getting xmin,...,ymax from current plot

[Blaubeer Marmelade]

Hello Thomas,

thank you for the Plus42 App, you did a wonderful job!

I want to realize parametric curves [x(t),y(t)] in the plot "App", (mis-)using a PRG-function which seems to be evaluated WIDTH+2 times for each plot process. The PRG should contain LINE/PIXEL commands to draw the curves. The corresponding coordinates however need to be scaled into the current plot window xmin,xmax,ymin,ymax, which can be changed eg. by interactive cursor operations within the app.

Is it possible to read these values somehow from within the PRG-plotfunction?

Best regards,

Dominik 

[Thomas Okken]

Hi Dominik, I'm not sure I understand how your parametric plot will work, but yes, it is possible to access the limits of the plot window from a function: PPAR[4] is XMIN, PPAR[5] is XMAX, PPAR[8] is YMIN, and PPAR[9] is YMAX.

[Blaubeer Marmelade]

Got it, this was the last missing piece, thank you!

My proof-of-concept works now as expected - except one flaw, which I can't understand why: Could it be, that PPAR is not updated internally right before(!) the first plotfunction evaluation, if the 2-cursor-points method is used in the plot-app for interactive replotting? (All other interactive replotting methods seem to feed PPAR directly before the plotfunction is called for first evaluation...)

For your better understanding, allow me to explain the intended algorithm for parametric plotting [x(t),y(t)] in more detail:

Prerequisit: 

  Initialize tmin, tmax, dt=(tmax-tmin)/(WIDTH+2),   SF 00 [Flag setting will be explained later]

Start Plot-App (manual, interactive handling!)

   Set PGM to MYPSTUFF

   Set PARM to  x:STK, y:STK

   Set VIEW : xmin, ..., ymax

With these settings, I assume that MYPSTUFF will be executed/called WIDTH+2  times.

Ending MYPSTUFF by  " ...(body)... 0 END " will plot the x-axis  - does not harm.

In (body) however, you are allowed to do whatever you want: In the current PLUS42-implementation, LINE and PIXEL commands within (body) will generate arbitrary line-segments or dots/axes in the current plot window. This behavior opens the door to realize nearly arbitrary visualizations within the plot-app (not only parametric curves). Example: Using [x(t_i-1), y(t_i-1)] and [x(t_i), y(t_i)] as coordinates for LINE will plot the corresponding parametric curve, where the i-th evaluation of MYPSTUFF will add the i-th line segment.

Scaling parameters:

Of course, to produce the dots at the right position, LINE or PIXEL need display-coordinates nx, ny  instead of x,y directly. Scaling parameters SCLxxx are necessary here:

nx = SCLXF * x(t) + SCLXAD

ny = SCLYF * y(t) + SCLYAD

The current xmin, ....ymax are required within MYPSTUFF to initiate the SCLxxx at begin of a new plot-process, i.e., at begin of the first evaluation of MYPSTUFF. In principle, you could calculate the SCLxxx during each evaluation of MYPSTUFF -- but this would be... you know...

I use the flag 00 to test the "first evaluation"-status (see initiation for tmin, ... as given above)

All in all, (body) looks roughly like this in my current POC:

FS? 00   ; if yes, we are in first round

    do scaling factors + CF 00 + set counter for evaluation number ( 1 STO EC )

...

Do what you want to do during each evaluation: Calculating sth from EQN-objects or SOLVE-Processes or ...

Make it appear on screen by LINE or PIXEL:   nx+i*ny  PIXEL

...

1 

STO+ EC   ; current evaluation is done

RCL EC

WIDTH + 2

-

X=0?       ; was this the last evaluation?

    SF 00    ; Next call will be a new plot and required new scaling setup

0

end

Now, I could verify that this idea works with the current PLUS42 as expected - except if you initiate a re-plot by the 2-cursor-points method in the plot-app: Doing so, the curve [x(t),y(t)] stays at the same place on the screen and is not reframed according to the intended new plot-window. This means, SCLxxx are "updated" during first evaluation based on the old xmin, ...,ymax instead of the new values.

Can you verify this from the internal update-behavior for PPAR?

(sorry for this lengthy message - hope you get my points...)

(Maybe, you or somebody else knows a more elegant way of doing parametric plots in PLUS42. Or maybe you plan a corresponding feature for upcoming versions. I am open for hints to other ways... just tried here to use the wonderful efficient plot-app interface for other visualizations as well...)

Thank you in advance!

BR

Dominik

[Blaubeer Marmelade]

Update:

Just found, that I asked the wrong question in my last message above.

The bad guy is not the two-cursor-point reframing method. It seems to be already the setting of a single cursor mark [move cursor cross and press ENTER]. This action initiates a re-plot process taking WIDTH+3 evaluations of MYPSTUFF instead of the usual WIDTH+2.  Why is this necessary?

Anyway, this behavior corrupts the "starting-new-plot" criterion in MYPSTUFF and causes wrong SCLxxx settings.

After all these experiences so far, here is a proposal for a (simple? but powerful!) extension of the PLUS42 plot-app: What about a further PARM-option (sth like X: iter; Y:none) to plot axes/annotations only and iterativly evaluate PGM until a certain flag is set by PGM, while putting the current iteration number into X-Reg at start of each PGM call... this would open a short way into various 2D-visualization like parametric plots, parameter scenarious for curves, implicite functions, histogramms, discrete (x,y)-sequences, ... a very inspirating playground, all within the available plot app comfort for moving/rescaling the x-y-window.

What do you think?

BR

Dominik

[Thomas Okken]

On Tuesday, September 10, 2024 at 6:43:17 PM UTC+2 blaubeer...@googlemail.com wrote:

Update:

Just found, that I asked the wrong question in my last message above.

The bad guy is not the two-cursor-point reframing method. It seems to be already the setting of a single cursor mark [move cursor cross and press ENTER]. This action initiates a re-plot process taking WIDTH+3 evaluations of MYPSTUFF instead of the usual WIDTH+2.  Why is this necessary?

When you set a mark, the function is evaluated in order to display the <Y>=value line at the top of the screen, and then the plot is repeated. That initial evaluation accounts for the difference in evaluation counts you noticed.

After all these experiences so far, here is a proposal for a (simple? but powerful!) extension of the PLUS42 plot-app: What about a further PARM-option (sth like X: iter; Y:none) to plot axes/annotations only and iterativly evaluate PGM until a certain flag is set by PGM, while putting the current iteration number into X-Reg at start of each PGM call... this would open a short way into various 2D-visualization like parametric plots, parameter scenarious for curves, implicite functions, histogramms, discrete (x,y)-sequences, ... a very inspirating playground, all within the available plot app comfort for moving/rescaling the x-y-window.

What do you think?

 I like the idea. In fact, at first I was going to implement more than just 2D X-Y plots; I scrapped the other plot types because they were taking too much time and I wanted to release Plus42 after having worked on it nonstop for half a year. But I would like to add more plot types eventually, like 3D surface plots, and, yes, 2D parameter plots.

[Blaubeer Marmelade]

Thank you for your explanation and for the encouraging feedback, glad that I could contribute an inspiration!

Just out of curiosity: Why is it necessary to replot/recalculate everything for setting a marker only?

As a closing remark from my side concerning the mentioned idea: At its core, it is about enabling a fast, versatile and intuitive way for the user from his data/mathmatical content to a suitable 2D visualization. To generate fast 2D-plot prototypes with high degree of customization, LINE and PIXEL is all he needs (maybe AGRAPH as well) - together with plot-app functionalities for axes/annotations and zoom, move, reframe, ...

There is currently a further obstacle however, which brakes the workflow on this way a little bit: From the user view, caring for SCLxxx is an unproductive pain only. You could give him support here as well. E.g. by providing a built-in transfer function from (x,y) to (nx,ny) - according to the current settings in PPAR for xmin, ..., ymax. 

Something like "xy2disp" which eats y and x from Y-/X-register, replacing them by ny, nx. Ideally, the function works same way with complex coords x+iy in X-reg, replacing it by nx+i ny. 

(Going much further later on towards 3D, the same concept could be handy in the form of "xyz2disp". Of course maybe you need here next to the x,y,z coords an extended PPAR with all min/max and a projection direction towards display...)

So, let me conclude: Whatever you plan to implement for the next release, I am thrilled to try out what will be possible with it;-)

Thank you for your engaged work on Free/Plus42!

BR

Dominik

[Blaubeer Marmelade]

Thread Refreshing...

[Thomas Okken]

It sounds like what you're looking for is the ability to do completely arbitrary drawing in a plot. If that's the case, trying to fit that into PLOT does not look to me like a good way forward; wouldn't it be more useful to have commands to draw the axes and run the plot viewer under program control? That way the program would control the plot rather than the other way around, and the end result would be cleaner and easier to use.

Note that I'm not committing to implement such commands. I'm still trying to understand the actual use case.

[Blaubeer Marmelade]

Yes, the option for arbitrary drawing in a plot is exactly what I am after.
Of course, adding suitabe command extensions for program controlled plot generation would completly solve my request in a technically clean way.
Would it be worth it considering the certainly high implementation effort to get there?
My usage experience: it would be not, according to my personal intension which is "Get from data to a (quick and dirty) visualization as effortless and intuitively as possible". It would be even obstructive according to my current plus42 usage habits on mobile phone: I like to focus on data generation/interpretation, I dislike to be forced in dealing with parasitic technical stuff such as "what is the correct keyword, syntax, procedure,...". So far, it is not my intension to automize plot generation or to get programmable control over sth what is already possible within PLOT app or should be possible there in future.
I love the current PLOT app - it is not perfect but for me it is very useful and efficient. An integrated workflow extension in PLOT to
visualize more than single y(x) 1D kind of data would fit my current needs perfectly. My corresponding proposal could be one way with
possibly minimal implementation effort only, acting as low threshold enabler/showcase, presumably without harmful side effects. Afterwards, you could wait for user feedbacks, and - if needed by the community - still proceed with corresponding command based implementation... (Until then: "done" is better than "perfect";-)

[Thomas Okken]

I don't foresee any big problems with making the axis-drawing, XY-function-plotting, and plot-viewing components separately accessible, but of course the devil will be in the details.

I will think about it.