forums.silverfrost.com
Welcome to the Silverfrost forums

 Native %pl Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Author Message
PaulLaidler

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

 Posted: Fri Jan 06, 2017 12:21 pm    Post subject: Dan I don't want to get into a long conversation on this. 64 bit %PL is just a quick stop gap aimed at getting existing 32 bit %PL code to draw something useful. I accept that it may not be very clever or generally useful at the moment.
DanRRight

Joined: 10 Mar 2008
Posts: 1872
Location: South Pole, Antarctica

Posted: Fri Jan 06, 2017 2:01 pm    Post subject: Re:

I understand that this is first pancake which is always not as perfect. I just afraid bad initial development decisions which may stay forever

 PaulLaidler wrote: Dan As you will have realised, the data does not lend itself to being joined by lines or curves. Best just to plot the points. y_max should be 30 (say).

I sometimes can not use it even with the simplest LINEAR x_array plotting. Here is what I get with the data above and this code (just linear plotting even without any y_max)

 Code: USE clrwin  integer, parameter :: n_dim = 1153  real*8 xstart, X(n_dim), Y(n_dim)  OPEN (UNIT=275,FILE='A.dat',STATUS='old',err=990)  do i=1,10000    if(i.gt.n_dim) goto 100    read(275,*,err=995,end=100) X(i), Y(i)  enddo  100 close(275)  n_points=i-1  xstart=0 ! X(1)              i=winio@('%ww[no_border]%es%ca[Default Plot]%pv&')        i=winio@('%fn[Tahoma]&')        i=winio@('%ts&', 3.1d0)        i=winio@('%tc&',rgb@(0,0,0))        i=winio@('%bf&')        i=winio@('%`bg&',rgb@(250,255,255)) !       CALL winop@("%pl[SCALE=log_log]")         CALL winop@("%pl[x_array]")         CALL winop@("%pl[n_graphs=1]")           CALL winop@('%pl[title="Sample plot"]')        CALL winop@("%pl[x_axis=Wavelength A]")        CALL winop@("%pl[y_axis=Intensity@(-4.0)]")        CALL winop@("%pl[width=3]") !       CALL winop@("%pl[Y_max=30.]")        CALL winop@("%pl[smoothing=4]") ! anti-aliasing        CALL winop@("%pl[colour=black]")           CALL winop@("%pl[style=0,pen_style=0]")           i=winio@("%pl",1502,880,n_points,x,y)  goto 10000  !................. errors ......................  990 Print*, 'Error opening file A.dat for read'  goto 10000  995 Print*, 'Error reading file A.dat'  goto 10000      10000 continue  end

- Do you see the same problem with the numbering for X axis tick marks?
- Do you see the same crazy curve (why I suspected that Bezier was used for smoothing)? With this is it possible just to offer linear approximation while connecting points?

Even if include rounded limit on X-min=12 the choice for tic numbers is not perfect

though this I think is fixable later. But the Log and Linear_Log is more important to fix first

Last edited by DanRRight on Fri Jan 06, 2017 2:35 pm; edited 1 time in total
PaulLaidler

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

Posted: Fri Jan 06, 2017 2:33 pm    Post subject:

I have added code to provide a better automatic x_min value but in the mean time you can set this in your code to 12.0 (say) or 10.0.

I have also corrected the code so that missing tick marks are now drawn.

I would use a smaller font (perhaps the default) and not bold.
As I mentioned before, you can't realistically plot a curve for this data.

 Code: i=winio@('%ww[no_border]%es%ca[Default Plot]%pv&')       i=winio@('%fn[Tahoma]&')       i=winio@('%`bg&',rgb@(250,255,255))       CALL winop@("%pl[x_array]")        CALL winop@('%pl[title="Sample plot"]')       CALL winop@("%pl[x_axis=Wavelength]")       CALL winop@("%pl[y_axis=Intensity]")       CALL winop@("%pl[x_min=12.]")       CALL winop@("%pl[symbol=9]")       CALL winop@("%pl[link=none]")        i=winio@("%pl",1502,880,n_points,x,y)

ps. I wonder if we are using the correct data.
DanRRight

Joined: 10 Mar 2008
Posts: 1872
Location: South Pole, Antarctica

Posted: Fri Jan 06, 2017 2:53 pm    Post subject:

 PaulLaidler wrote: ps. I wonder if we are using the correct data.

In the plots above I used small data file from previous page and large data I emailed to you (small or large here is not important, same problems I see in both cases). I also posted x_min=12 case probably at the same time as you posted your answer.

Right now new %pl is just for a fast draft data visualization not yet even reaching older Simpleplot %pl in some respects.

Missing are
- no bold fonts for numbering
- no settings for axis linewidth (right now it is 1 pixel no matter what plot size is).
- tic marks are wrong size and almost invisible and do not scale in length with the plot size.
- the amount of tic numbers is clearly excessive.

But these are minor details fixable easily. In short if you would be able to make this %pl approaching the look and feel of Ideal Plot #1 or #2 (I posted in other thread) and make the LOG data converted internally like in Simpleplot then this would be great and usable first version of new %pl !

In the future, in second version of %pl i'd add an option when you are scaling the plot size with the mouse all the fonts and line widths proportionally increase or decrease and make this style as universal scalable simplest default style, say, #100 so that you call it just in one single line

 Code: i=winio@('℅pv%pl[x_axis="Wavelength", y_axis="Intensity", n_graphs=1,style=100]',1502, 880, n_points, x, y)

and get exactly the perfect look of Ideal Plot #1 ready for any respectable publication. You will be increasing or decreasing its size with the mouse but the look will still be perfect. That will be great selling point and mass adoption of new %pl.

Future versions 3 will probably need to add 2D surface plotting or even 3D with OpenGL. I can send you my own 2D/3D plotting codes and examples if you need but I am sure you will be able to accomplish that much faster by themselves your way.

Last edited by DanRRight on Sat Jan 07, 2017 3:29 am; edited 1 time in total
PaulLaidler

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

 Posted: Fri Jan 06, 2017 5:21 pm    Post subject: Dan I can't do any more development on this for now. After the next full release we aim to revisit this subject and consider if there is a better way to get this kind of facility to the user.
DanRRight

Joined: 10 Mar 2008
Posts: 1872
Location: South Pole, Antarctica

Posted: Sat Jan 07, 2017 4:58 am    Post subject:

Paul,
Here are few other problems after I tried to plot in LOG-LINEAR scale.
On top for comparison is the same data plotted in scientific graphics software OriginLab. In this software when you increase or decrease image using mouse it proportionally scales all elements making the whole plot perfect for all sizes even the thumbnail one. That is what I was advocating to implement in %pl. Hope you will soon find the time to return to %pl.

 Code: USE clrwin  integer, parameter :: n_dim = 1153  real*8 xstart, X(n_dim), Y(n_dim)  OPEN (UNIT=275,FILE='A.dat',STATUS='old',err=990)  do i=1,10000    if(i.gt.n_dim) goto 100    read(275,*,err=995,end=100) X(i), Y(i)  enddo  100 close(275)  n_points=i-1  do i=1, n_points !  X(i) = alog10(X(i))   Y(i) = alog10(Y(i))  enddo  xstart=0 ! X(1)              i=winio@('%ww[no_border]%es%ca[Default Plot]%pv&')        i=winio@('%fn[Tahoma]&')        i=winio@('%ts&', 3.1d0)        i=winio@('%tc&',rgb@(0,0,0))        i=winio@('%bf&')        i=winio@('%`bg&',rgb@(250,255,255)) !       CALL winop@("%pl[SCALE=log_log]")         CALL winop@("%pl[SCALE=log_linear]")         CALL winop@("%pl[x_array]")         CALL winop@("%pl[n_graphs=1]")           CALL winop@('%pl[title="Sample Log-Linear"]')        CALL winop@("%pl[x_axis=Wavelength A]")        CALL winop@("%pl[y_axis=Intensity@(-4.0)]")        CALL winop@("%pl[width=3]")        CALL winop@("%pl[X_min=12.]")        CALL winop@("%pl[X_max=22.]")        CALL winop@("%pl[Y_min=0.1]") !      CALL winop@("%pl[Y_max=30.]")        CALL winop@("%pl[smoothing=4]") ! anti-aliasing        CALL winop@("%pl[colour=black]")           CALL winop@("%pl[style=0,pen_style=0]")           i=winio@("%pl",1502,880,n_points,x,y)  goto 10000  !................. errors ......................  990 Print*, 'Error opening file A.dat for read'  goto 10000  995 Print*, 'Error reading file A.dat'  goto 10000      10000 continue  end

Last edited by DanRRight on Sat Jan 07, 2017 10:36 am; edited 1 time in total
PaulLaidler

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

 Posted: Sat Jan 07, 2017 8:42 am    Post subject: Thanks Dan.
DanRRight

Joined: 10 Mar 2008
Posts: 1872
Location: South Pole, Antarctica

 Posted: Sat Jan 07, 2017 10:45 am    Post subject: As a good point one can note from these two pictures above that with its antialiasing FTN95 beats professional graphics software in line smoothness quality -- it produces MUCH less visible jaggedness. Here is one more small defect with axis numbering. Plotted with different data set but this thing is pretty reproducible with almost any. Also, in this plot antialiasing is switched off so one can see the sharp edges of lines
PaulLaidler

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

 Posted: Sat Jan 07, 2017 11:27 am    Post subject: Thanks Dan. For now you will probably need to use a smaller font size.
DanRRight

Joined: 10 Mar 2008
Posts: 1872
Location: South Pole, Antarctica

Posted: Mon Jan 16, 2017 1:27 pm    Post subject:

I do not know if this bug below should be fixed or we have to wait when the entire way of plotting LOG functions should be changed.

1) As i wrote that for example LOG_LINEAR way of plotting in new %pl is inconvenient as it requires LOG10 of all Y values. As the new %pl is in early development it would be easy to change things completely to the way older %pl doing same things. But may be it would be still a good idea to fix the current plotting way too. This simple annoying bug in tic numbering makes sometimes almost impossible to use %pl.

Here is the text for plotting of some simple function (i took y=x) where some y(i) take large values,like for example y(1)=1e20. In this case some tic marks here get crazy, like instead of 1e9 we see 1e909e7 etc

 Code: USE clrwin  integer, parameter :: n_dim = 5  real*8 X(n_dim), Y(n_dim), Z(n_dim)  do i=1, n_dim   A = i   X(i) = A   Y(i) = log10(A)  enddo   Y(5) = log10(1e20)         i=winio@('%ww[no_border]%es%ca[Default Plot]%pv&')   i=winio@('%pl[scale=log_linear,x_array,colour=black,colour=red,n_graphs=1]',600,400,n_points,x,y)! ,z)   end

2) Another problem is visible too but we discussed that already.
/* Trying to make smooth line we get the plot distorted in the area x = 3.8 - 4. Offering an option of having just the simpler linear interpolation between points should be in many cases OK i think
PaulLaidler

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

 Posted: Mon Jan 16, 2017 1:32 pm    Post subject: Dan In the next release I have taken logarithmic scales out of the native %PL until I get more time to work on this.
DanRRight

Joined: 10 Mar 2008
Posts: 1872
Location: South Pole, Antarctica

Posted: Tue Jan 17, 2017 2:54 pm    Post subject:

This bug looks easy fixable, may be it is worth for now just to fix it?

Also the question: why it was chosen to define the line width this way which is harder to change dynamically
 Code: CALL winop@("%pl[width=3]")

instead of doing that usual way
 Code: i=winio@('%XX&', LineWidth)
??
PaulLaidler

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

 Posted: Tue Jan 17, 2017 5:03 pm    Post subject: Unfortunately I don't have time to do anything more on this at the moment.
John-Silver

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

Posted: Sun Jan 22, 2017 4:54 am    Post subject:

Sorry I've not been following this thread since xmas and I'm only just catching up.

 Quote: For now you will probably need to use a smaller font size

How might that fix the problem ?
It's not only a problem of 'crowding' of the labels (I assume that's the reason for the 'gaps' too) but also some very strange scaling spacings are chosen.

Although I appreciate the sentiment of
 Quote: Unfortunately I don't have time to do anything more on this at the moment.

a very muchly lot of my own need would be logarithmic scales and regarding this .....
 Quote: In the next release I have taken logarithmic scales out of the native %PL until I get more time to work on this.

This isn't, if I may say so, a very 'logical' 'solution' to the problem.

If my boss were being asked to sign off to butėy FTN95 and I told him 'oh, but it can't do log-log graphs for the moment but they're promising it' I'd get laughed out of the office!

After all , some of log plotting works, so it might stil lbe useful for a lot of needs and that's being taken away with this philosophy.

Most of the niggles appear 'liveable with' and work-around-able' (like using smaller fonts) in the short term, except :

A. the scalings spacings
it seems to me like the 'checking' of proximity of labels is done 1-by-1, resulting in the progressive bigger spacing. A simple change in the short term would be to either
i) do the checks along the whole axis frst , and if ANY of the spacings are compromised then make ALL the spacings bigger
ii) don't do any checking and let labels overlap. This is then a visual indicator (for the programmer at least) that smallr fonts are required
This is obviously not ideal , since the programmer can't implement any specific algorithm to do this ... not knowinėg the spacing in advance.

In fact, thinking about it, there should be an option for the user to specify the scaling !!!! which of course it would mean that it was possible with %superPL first

B. the fact that on the log-linear exampke above the data itself looks to be plotted ok but the Y_axis is the log values plotted on a linear graduated scale !!!

(cue again more rolling over the floor from my boss)

Anyway,It's pity, having waited so long for such a fundamental capability to appear, to see the great work done recently in such a short space of time (hat doffed) put on the backburner for such a relatively simple problem.
So near and yet so far ' being the most appropriate phrase that springs to mind.[/quote][quote]
JohnCampbell

Joined: 16 Feb 2006
Posts: 1983
Location: Sydney

Posted: Tue Jan 24, 2017 4:47 am    Post subject:

Paul,

I am using a recent download of libraries date stamped 5/11/2016 10:29am
(I am not sure if this is the file date stamp, or the download date.)
I think I got it from this thread.

When I run my graphics program I get the message:
" Argument number 2 of WINIO@ (continuation 113)
should be an INTEGER(7) at address 1c007ee9"

The traceback gives:
Within file saplot.exe

This has me a bit stumped, as I have checked all WINIO@ arguments and can not find the problem. I have used INTEGER(7) for all handles or previously INTEGER*8.
(continuation 113) is not easy to locate !

Ver 8.05.00 (17/06/2016) does not produce this problem.
Could the problem be in something else, say a function call ?

My 64 bit attempt to get the date stamp of the .dll is:
 Code: subroutine echo_dll_version !       include       C_EXTERNAL SCC_LIB_VERSION@       '_scc_lib_version' :INTEGER*4 !      C_EXTERNAL INITLIBRARYFILEINFO@   '_InitLibraryFileInfo'():INTEGER*4 !      C_EXTERNAL GETLIBRARYVERSIONINFO@ '_GetLibraryVersionInfo'():STRING !      C_EXTERNAL GETLIBRARYPATH@        '_GetLibraryPath'():STRING !      C_EXTERNAL GETLIBRARYDATEINFO@    '_GetLibraryDateInfo'():STRING !       integer   dll_version !      character str_dll_version_info*256       character dos_date*9, dll_date*9, ftn95_ver*80       external  dos_date !          include !         ftn95_ver   = '[FTN95/Win32 Ver. 8.00 beta.14]'          dll_version = scc_lib_version@ ()          dll_date    = dos_date (ints(dll_version)) !          WRITE ( *,1001) trim(ftn95_ver), dll_date, dll_version          WRITE (98,1001) trim(ftn95_ver), dll_date, dll_version !       write ( *,1000) ' '       write (98,1000) ' '  1000 FORMAT (a,a)  1001 FORMAT (a/' Salford DLL code : ',a,i11) !       RETURN !       END

Is this a possibility ?
scc_lib_version@ () actually returns dll_version =17002 > 10-Mar-13 which looks wrong.

John
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First
 All times are GMT + 1 HourGoto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next Page 8 of 9