forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Native %PL - User-spec. x-axis Ranges
Goto page 1, 2  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Apr 11, 2018 7:56 pm    Post subject: Native %PL - User-spec. x-axis Ranges Reply with quote

ref. native %pl 2nd Example in the on-line documentation here:
https://silverfrost.com/ftn95-help/clearwinp/simplepl/native.aspx

Note - I'm here using v8.1 Personal combined with the recently 'aborted' new dlls22 ! so there may or may not be some influence there in what is reported here.

I've adapted the example referenced above to use to have a first look at some of the new features/fixes for %pl in v8.3 and I have come across a couple of problems.

Note that in the modified code (which follows after the plots ) :
a) I've commented out the 'Delay plotting' so that a plot appears on program start up
b) I've set the x and y limits (on start-up to be X --> -300 to 1200 y --> -0.3 to +0.3
c) Ive modded the limits in the Refresh call-back to be x --> 120 to 550 Y --> -0,5 to +0.5

There appears (unless I've made a silly mistake which is always+ possible) to be a problem in user-specifying the x-axis range when it is INSIDE the overall data-range.
If the user range envelopes at both ends the data range then there's no problem as seen by the first plot which is OK.
If however a smaller 'zoom-in' range is specified (as in the menu activated re-drawn plot, the lower limit is taken correctly into account (120) but the upper limit (550) is not, the plot being done with the maximum data range value (1000) as the range limit


Oh, note also Paul that the plot in the documentation is not the correct one produced if you run the code unchanged !!!


Note also that a few of the 'old annoying chestnuts' previously identified still seem to be present ....

i) the axes captions are still centred only on the possitive segment of the axes

ii) the y-caption (default position) is still too close to the y labels (yes I know there's the workaround, which I removed in order to test, but there should be some spacing there by default !)
also the x-caption offset fronm the axis/labels seems to be quite large, which for example, when the new 'frame' option is used to put the axes outside the plot space, would take up quite a large amount of (white) space especially for smaller plots

Ah yes, and by complete chance I noted another oddity that might be a bug:
if you minimise the window to the taskbar, when you recover it you only get a blank window with a relatively thin black band under the caption bar !!!

I post below also thìs erroneous window and the error message which appears when it is closed using the 'X' box.

Post editted 12/4/2018 with some highlighting (bold) and small clarifications
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Thu Apr 12, 2018 8:43 am; edited 2 times in total
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Apr 11, 2018 7:57 pm    Post subject: Reply with quote

Here are the 2 plots produced by the program first :-




_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Apr 11, 2018 7:57 pm    Post subject: Reply with quote

Then here are the window and error message when the window is reduced to then restored from the windows(7) taskbar.

The Daft Restored window


Error Message


Detailed Error Message

_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Apr 11, 2018 7:59 pm    Post subject: Reply with quote

And of course here's the modified %pl Example 2 code used .....
Note - modified 17_04_2018 with correct posting of code !!!

Code:
!
!  NpcPL-Ex2-v2a2TEST3
!
      WINAPP
      MODULE mydata
        USE clrwin

!        ENUM,BIND(C)
!         ENUMERATOR::link_none=0,link_lines,link_curves !values 0,1,2
!         ENUMERATOR::all_graphs=0,graph1                !values 0,1
!        END ENUM

   INTEGER, PARAMETER::link_none=0
   INTEGER, PARAMETER::link_lines=1
   INTEGER, PARAMETER::link_curves=2
   INTEGER, PARAMETER::all_graphs=0
   INTEGER, PARAMETER::graph1=1

        INTEGER,PARAMETER::n=1000
        LOGICAL shown
        DOUBLE PRECISION y(n)

        REAL*8 xx(n)

      CONTAINS

      INTEGER FUNCTION show()
        INTEGER errstate
        errstate = change_plot_int@(0,"link",graph1,link_curves)
        if(errstate /= 0) print*, clearwin_string@("ERROR_REPORT")
        errstate = change_plot_int@(0,"colour",graph1,RGB@(255,0,0))

!        errstate = change_plot_dbl@(0,"y_max",all_graphs,1.5d0)

        errstate = change_plot_dbl@(0,"x_min",all_graphs,120.0d0)
        errstate = change_plot_dbl@(0,"x_max",all_graphs,550.0d0)
        errstate = change_plot_dbl@(0,"y_min",all_graphs,-0.5d0)
        errstate = change_plot_dbl@(0,"y_max",all_graphs,0.5d0)

        shown = .true.
        CALL simpleplot_redraw@()
        show = 2
      END FUNCTION show


      INTEGER FUNCTION clear()
        INTEGER errstate
        errstate = change_plot_int@(0,"link",graph1,link_none)
        shown = .false.
        CALL simpleplot_redraw@()
        clear = 2
      END FUNCTION clear

      INTEGER FUNCTION legend()
        IF(shown) THEN
          CALL draw_characters@("Legend:..", 300, 100, 0)
          CALL draw_line_between@(300,120,360,120,RGB@(0,0,255))
        ENDIF
        legend = 2
      END FUNCTION legend
      END MODULE mydata
     
      PROGRAM main
      USE mydata
      INTEGER i,x
      DOUBLE PRECISION p1,p2,p3
      p1=1.5d0
      p2=150.0d0
      p3=15d0

      x=0

      DO i=1,n

        xx(i)=float(x)

        y(i)=p1*sin(x/p3)*exp(-x/p2)
        x=x+1
      ENDDO

      shown = .false.

      i=winio@('%ww[no_border]%ca[Damped wave]%pv&')
      i=winio@('%mn[Edit[Show, Clear]]&', show, clear)
      i=winio@('%fn[Tahoma]&')
      i=winio@('%ts&', 1.1d0)
      i=winio@('%tc&',rgb@(0,0,80))
      i=winio@('%it&')
      i=winio@('%`bg&',rgb@(230,255,225))
      CALL winop@("%pl[native]")
      CALL winop@('%pl[title="Sample plot"]')
      CALL winop@("%pl[x_axis=Time(Milliseconds)]")
! v2a2 - x-axis range extended (x_min set to be negative (test)
      CALL winop@("%pl[x_min=-200.0d0,x_max=1200.0d0]")   ! x_min/max set to -200/1200 to see what happens to axis caption
!      CALL winop@("%pl[x_min=120.0d0,x_max=550.0d0]")      ! x_min/max set to 120/550 to see what happens to axis caption
!      CALL winop@("%pl[x_max=500.0]")   ! x_max set to 500 to see what happens to axis caption


... missing end of code in later comment on 17/4/2018
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "


Last edited by John-Silver on Tue Apr 17, 2018 3:08 pm; edited 9 times in total
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Wed Apr 11, 2018 8:22 pm    Post subject: Reply with quote

Not that I followed the code, John, but after a resize you always need to test that the %gr size is not 0 (in either direction), otherwise you get a divide by zero error when you recalculate scales.

Eddie
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Wed Apr 11, 2018 8:32 pm    Post subject: Reply with quote

I haven't done any scales calculating in the code, just specified the ranges via x_min & x_max parameters for the %pl plots.
It could of course be that 'internally causing some problem but I'm guessing that it's just not changing the upper limit and just retaining the 'nominal one' initially calculated from the data range.

The re-size is done automatically when dragging the corners of the window !

Ah unless you mean the problem of when reducing to the taskbar - and the %pl (which is a %gr) is reset internally to 0 x 0 - but then again this has never been a problem I've noticed before (but then again I wasn't looking Smile )
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Sat Apr 14, 2018 5:40 pm    Post subject: Reply with quote

Paul, can you shed any light on this incorrect x_max definitions ?

Is it easy to fix ?
(The idea being to be able to plot the full plot and then a 'zoomed' portion only underneath it - in my business this is indispensible)

... and your thoughts about fixing the old chestnuts ?


Also can someone please run the code above woith v9ì8.3, just to confirm you get the same effects and thus throw out the possibility that it's because I'm using v8.1 with dlls for 8.3 . Thanks.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Apr 16, 2018 5:33 pm    Post subject: Reply with quote

John

The program that you posted is truncated.
What are the missing lines?
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Tue Apr 17, 2018 2:58 pm    Post subject: Reply with quote

Darn that post limit ! time it was changed Paul !

Here you go, I've first edited the original posting of the code above so that it posts correctly as code and then here's the last few lines to that version ....

continued from previous posting of code above ....

Code:
      CALL winop@("%pl[y_min=-0.3]")   ! y_min set to -0.3
      CALL winop@("%pl[y_max=0.3]")   ! y_max set to 0.3

! v2a2 - extend y-axis caption (test)
!      CALL winop@("%pl[y_axis=Amplitude@(-4.0)]")
      CALL winop@("%pl[y_axis='Amplitude (title extended very longly as a test']")

      CALL winop@("%pl[smoothing=4]") ! anti-aliasing
!      CALL winop@("%pl[link=none]")   ! delay drawing

! v2a2 - NEW options set
!     CALL winop@("%pl[SCALE=LOG_LOG]")
! v2a2 - Define left, top, right and bottom margin (in pixels) (test)
!      CALL winop@("%pl[margin=(80,120,300,100)]")   ! specify all 4 margins
      CALL winop@("%pl[x_array]")   ! specify x values in an array

!      i=winio@("%^pl",500,400,n,0.0d0,1.0d0,y,legend)
!      i=winio@("%^pl",1000,600,n,-500.0d0,1.0d0,y,legend)
      i=winio@("%^pl",1000,600,n,xx,y,legend)
      END



[/code]
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Wed Apr 18, 2018 9:54 am    Post subject: Reply with quote

John-Silver: The personal edition of 8.3 is now available, as you can see at www.silverfrost.com.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Apr 19, 2018 10:47 am    Post subject: Reply with quote

John

I have looked at your code and fixed the first bug that I noticed - the access violation when the window is minimised.

I started to look at the issue regarding x_max but it was not obvious to me what the problem is here. Is it not possible to present a short program and simpler information about what is wrong?
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Apr 19, 2018 5:11 pm    Post subject: Reply with quote

John

I have come back to this and I can now see the "problem".

x_min and x_max are provided for small adjustments to the end points. A small adjustment can reveal a missing end tick mark and value on the x axis. It says this somewhere in the documentation.

Clearly you were expecting something more fundamental but that is not in the current design.
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Fri Apr 20, 2018 5:40 am    Post subject: Reply with quote

Paul said:
Quote:
I have looked at your code and fixed the first bug that I noticed - the access violation when the window is minimised.


Thanks Paul, I assume this will be in the next dlls release then ?


Quote:
I started to look at the issue regarding x_max but it was not obvious to me what the problem is here.


The example code is based on the documented Example 2, I used it as I thought it would be a good reference for checking.

I thought my explanation of the problem was clear but I'll explain again:

The x-data range is from 1 to 1000
The plot displayed on r launching the program has the x-range set as -200 to 1200 (i.e. 200 (not small) outside of the range in each dorection) as a tst to see wha thappens.
IT PLOTS FINE with the range extended !

On clicking the menu item 'Show' the revisd requested x_range 120 to 550 is invoked, i.e. a range totally INSIDE the overall full data range.
The LOWER BOUND PLOTS FINE and none of the data below x=120 are plotted.
However ... THE UPPER SPECIFIED BOUND (550) seems to be ignored and all the data is plotted up to x=1000, which is used as the acales upper bound.

There's no obvious reason for this except that internally the data to be plotted is only truncated at the bottom end and not also at the top.
That's why I think it is a bug.

Note also that I truncate the Y-axis in a similar way (different range each time, in each cas inside the overall data range) and there's no problem with that.

The documentation you mentioned is under 'Additional Notes' just before the 2 examples in the native %pl options section.
I've seen that before but all that's saying is that it was introduced to 'tweak' the acales tick marks and scaling.
My ''problem'' is not to do with any tick marks not being optimal it's more serious.

I also tried with smaller truncation of the range (say for example changing to 5-to-995 but th same appears to happen (although it's difficult to see as the end points are not labelled !

As for:
Quote:
Clearly you were expecting something more fundamental but that is not in the current design

Not at all - I assume that when x_min and x_max are specified that %pl then plots data only between those 2 values no ?
That must be the case from what I've written above and seen for the lower bound which is truncated correctly.

Unless of course I'm missing something subtle.

Of course, the idiocyncracies of the scales algorithms for default case are still there and still far from desireable, but that isn't the subject matter of this post.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Apr 20, 2018 7:06 am    Post subject: Reply with quote

John

As I said, x_min and x_max are only provided for you to make small adjustments to the end points. What you are expecting is not currently in the design and so is not implemented. Please don't ask for this to be changed because there are many far more important things that need doing.
Back to top
View user's profile Send private message AIM Address
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Fri Apr 20, 2018 3:39 pm    Post subject: Reply with quote

I understand that you have many 'important things to do', that's been implied for a long time and so I'm not asking for a change (enhancement).
( ... even if I personally consider that there's nothing more important than the capability to be able to present results graphically ! but that's a philosophical argument for another time)

I'm just trying to understand what you keep repeating, when my results seem to indicate otherwise (the fact that the lower range works wihout problem and for quite an important shift of range requested).

Are you just saying then that it is a bug, but for smaller values it wouldn't be, and so because that was the design intention you won't be fìxing this bug ?

If it is then , if I may say so, it's not a robust approach to be taking.
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group