|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Thu Sep 14, 2017 8:00 am Post subject: |
|
|
Dan beat us to it ! (all valid points of course).
Which begs the question, is it first come-first served as far as the wish-list is concerned ?
I started to compile a list of things from memory which I was ready to post ... then I stopped and thought.
First I'd suggest that we need a specific post, or better still a seperate forum topic ('Wish Lists' maybe ?) dedicated simply to requests without much discussion, otherwise I'm certain some things will inevitablt get 'lost'/obscured, as they have on the Native %PL post(s).
A 'Wish Lists' forum topic could for example have a first post 'Wish List for Native %PL Improvements Prior to 'mmm yyyy' Release'.
Such a forum topic could then be used for other Wish Lists. I remember Eddie doing a fine one a couple of years or more back now , but not easy to find.
I'm not exactly sure what your 'schedule' is Paul in terms of - next release date ? time available for dedication to native %PL ? but I'm sure it's limited !
As such, I think there's a need to fix the very simple things first then progressively treat the wishes in terms of their importance/complexity.
Categorising/prioritising the wishes as, for example :-
Simple
Medium
Major Complexity
Then of course my understanding is that your call for help is relating to previously identified shortcomings as buried somewhere in this/these posts.
After that there will clearly be other wishes for enhancements, equally valid/desireable but which will be out of scope of your immediate resources.
Prioritising getting the Simple gremlins out of Linear Plots first would be logical before ploughing into log plotting. Then again Mr Murphy says Simple Gremlins are oft more complex creatures than we appreciate.
The worst thing that could happen is that a 'new' feature wish request is attacked and some really simple annoying stuff gets left behind again by the time of the next release.
The above are just suggestions of course, but it would be a shame to 'officially launch' native %PL (remember it's still in beta) with simple (and not so simple) shortcomings both minor (stuff like axis labels ! , curves plotted off-plot frame !, ) and major (I'm thinking log plotting here).
I'm sure there are technical restrictions on what you can implement as I think you've touched on concerning several prevous suggestions but, despite your valiant efforts over the last year, plotting is still imo a major deficiency in FTN 95 at the moment. It seems not to have had the priority it deserves.
The ideal way to categorise/track the requests and check them off would be a spreadsheet !
... but how to organise that ? maybe you (there can only be one controller) could publish a template which people could use to submit their suggestions/requests then send it to you and you could control a 'master' version, filtering requests in terms of priority, which you then regularly post to the relevant Wish Forum post ?
Note - a reminder that there are in fact 3 heritage posts, not just this one, which contain mention of shortcomings/wishes for future improvements.
For reference ...
This post :-
Title: Native %pl (Paul's 2nd post)
April - Sept (now) 2017 - 6 pages
http://forums.silverfrost.com/viewtopic.php?t=3487&start=60 20th
Title: Native %pl (Kenneth Smith's originated post) (27th Feb-20th April 2017 - 8 pages)
http://forums.silverfrost.com/viewtopic.php?t=3427
Title: Native %pl (Paul's original native %PL launch post) (26th Oct 2016 - 12th March 2017 - 9 pages))
http://forums.silverfrost.com/viewtopic.php?t=3357&postdays=0&postorder=asc&start=0 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Thu Sep 14, 2017 8:41 am Post subject: |
|
|
John
I will aim to fix any obvious bugs. At the moment I am not compiling a wish list.
Also I am very short of time so I will need new posts with working programs and all the data. If a program and its data are too large to post then you can either use Dropbox or I can supply an email address to use.
I have already fixed a number of bugs so you may prefer to wait for the new DLL upload due shortly. |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Fri Sep 15, 2017 8:27 am Post subject: |
|
|
Paul,
I appreciate that you are not compiling a wish list, but please don't forget my request way back in May which you did say might be a simple addition:
Quote: | A useful possible addition would be a flag which forces %pl to place the scales external to the frame, this would avoid the situation where data points obscure the numbers on the scale, and would give a more uniform appearance when groups of plots a combined together. |
Thanks,
Ken |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Sep 19, 2017 8:26 pm Post subject: |
|
|
... or indeed to place the full frame WITHOUT ANY tick marks on top and rh edges ! |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Tue Sep 19, 2017 8:27 pm Post subject: |
|
|
What are the current MAXIMUMs for:
Number of curves (graphs) per plot (i.e. N_GRAPHS ) ?
Number of points per curve (graph) ?
I can't find mention of the limits in the documentation.
This could be an important limitation (if there is one) which could prove debilitating.
For my normal useage I would expect the limit to be in the order of hundreds in each case. |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Fri Sep 22, 2017 2:25 pm Post subject: |
|
|
Not sure where to post this. I have been using the latest DLLs no 13, and playing about with the new native %pl with a view towards using it to update data plots as a simulation progresses. The following code reveals some issues.
Code: | module data_mod
implicit none
integer, parameter :: dp = SELECTED_REAL_KIND(15,307)
integer, parameter :: npts_max = 10000
integer :: npts = 2000, npts_now(2) = 0
real(kind=dp) :: x(npts_max) = 0.d0, y(npts_max) = 0.d0, xend=0.d0, yend=0.d0
real(kind=dp), parameter :: pi = 3.1415926535897932d0
real(kind=dp), parameter :: two_pi = 2.d0*pi
real(kind=dp) :: len = 1.d0
real(kind=dp) :: ang = 0.0123d0
end module data_mod
module calc_mod
use data_mod
implicit none
contains
integer function build_gui()
include<windows.ins>
integer i
npts_now = 0
len=1.d0 !#### NEEDED WHEN complied in 64bit mode
i = winio@('%mn[Exit]&','exit')
i = winio@('%bg[grey]&')
i = winio@('%7.1ob&')
i = winio@('%ws&','Number of points')
i = winio@('%cb&')
i = winio@('%il&', 0, npts_max)
i = winio@('%rd&',npts)
i = winio@('%cb&')
i = winio@('%ws&','Length')
i = winio@('%cb&')
i = winio@('%rf&',len)
i = winio@('%cb&')
i = winio@('%ws&','Angle increment')
i = winio@('%cb&')
i = winio@('%rf&',ang)
i = winio@('%cb&')
i = winio@('%^tt[Plot]&',plot)
i = winio@('%cb&')
i = winio@('%ff&')
call winop@('%pl[native]')
call winop@('%pl[smoothing=4]')
CALL winop@("%pl[width=1]")
CALL winop@("%pl[x_array]")
call winop@("%pl[independent]")
call winop@("%pl[N_GRAPHS=2]")
CALL winop@("%pl[link=lines]")
CALL winop@("%pl[colour=blue,colour=red]")
call winop@("%pl[symbol=0,symbol=11]")
call winop@("%pl[pen_style=0]")
i = winio@('%`bg[white]&')
i = winio@('%pl&',650,600,npts_now,x,y,xend,yend)
i = winio@('%ff')
build_gui = 1
end function build_gui
integer function plot()
include<windows.ins>
integer i, counter
real(kind=dp) ang_last
write(6,*) 'Beginning FUNCTION PLOT'
x(1) = 0.d0 ; y(1) = 0.d0 ; xend = 0.d0 ; yend = 0.d0
ang_last = 0.d0
counter = 0
do i = 2, npts
ang_last = ang_last + ang*real(i,kind=dp)
if (ang_last .gt. two_pi) ang_last = ang_last - two_pi
if (ang_last .lt. two_pi) ang_last = ang_last + two_pi
x(i) = x(i-1) + len*cos(ang_last)
y(i) = y(i-1) + len*sin(ang_last)
npts_now(1) = i
npts_now(2) = 1
xend = x(i)
yend = y(i)
counter = counter + 1
if (counter .eq. 5 )then
call YIELD_PROGRAM_CONTROL@(Y_TEMPORARILY)
call simpleplot_redraw@()
counter = 0
end if
end do
write(6,*) 'Completed FUNCTION PLOT'
plot = 1
end function plot
end module calc_mod
program main
use calc_mod
implicit none
integer i
i = build_gui()
end program main
|
Last edited by Kenneth_Smith on Fri Sep 22, 2017 2:30 pm; edited 1 time in total |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Fri Sep 22, 2017 2:29 pm Post subject: |
|
|
/cont
When complied with the 32 bit complier, strange things happen with the x and y scales.
Set Number of points to 5000, length = 1 and observe the y axis at the end of the run.
Set Number of points to 7000, length = 1 and observe the y axis at the end of the run. Different even although the extents of the y axis data has not changed.
Set Number of points to 5000, length = 10 and observe the x axis data at the end of the run. Note the value display at X=100.
These only occur when compiled with the 32 bit compiler - 64 bit is fine, BUT without the
line at the beginning of the function build_gui, the 64 bit program plots nothing as the initial value of len specified in the module data_mod is not picked up. |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Fri Sep 22, 2017 2:33 pm Post subject: |
|
|
/cont
Some pictures:-
|
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1892
|
Posted: Fri Sep 22, 2017 4:48 pm Post subject: Re: |
|
|
Kenneth_Smith wrote: | 64 bit is fine, BUT without the
line at the beginning of the function build_gui, the 64 bit program plots nothing as the initial value of len specified in the module data_mod is not picked up. |
Here is a simplified test code for reproducing this problem.
Code: | module data_mod
implicit none
real :: len = 1.d0
end module data_mod
module calc_mod
use data_mod
contains
integer function build_gui()
print *,'len = ',len
build_gui = 1
end function build_gui
end module calc_mod
program main
use calc_mod
implicit none
integer i
i = build_gui()
end program main
|
The program prints 1.00000 without /64 and 0.00000 with /64. If the variable 'len' is changed to something else, such as 'xlen', the problem goes away. Perhaps the variable 'len' is confused with the intrinsic string length function?
P.S. May I highlight the fact that this bug (failure to honour initialisation of module variable) is a compiler bug and quite independent of Clearwin64 and graphical output? I am sure that Paul recognises this point, but this post is in the ClearWin+ forum and most of this thread is about graphics, so I felt that I needed to stress the point.
Last edited by mecej4 on Sat Sep 23, 2017 12:05 pm; edited 3 times in total |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Fri Sep 22, 2017 9:31 pm Post subject: |
|
|
Ken,
I love https://www.youtube.com/watch?v=aZF0s8yWvQM
But I digress.
Your problem is definitely https://www.youtube.com/watch?v=6vdTRyxPZLY
With dlls13 .....
I ran your cases and observed the following...
CASE 1 (5000 & 1)
the scales change several times duting the run. Not just the ranges but also the format of the labelling ! This is clearly not desireable as it appears to be arbitrary.
I'd be interested to know what the basic algorithm is for selecting the format as a function of the scale being plotted becasue this has been seen on earlier examples on this & the other posts, sometimes even changing within the scale !
The final scale status appears during the 8th curly wurly (of the 9 total). format while the others are F8.5
�Note the first label on the Y axis has more zeros than the rest. i.e. it's a fixed width format that's written ! this may or may not help tracing where the problem might be in the compiler.
CASE 2 (7000 & 1)
This one is interesting because the scales once again change during the run but this time 'more violently' with a lot of flickering (rapid changing) often occurring sometimes.
The final scale appears first again at the 8th curly wurly. during the 11th wurly the program takes on the guise of The Doctor re-gnerating time and again with I think 4 changes ! returning finally to the ultimate state in the 12th re-incarna- err curly wurly.
I don't know if you see this as you don't mention it as it may be more disguised on a very much faster machine, mine is quite old.
More in�teresting is the observation that the strange 100.0000X values are not constant, the 'X' 'cycle' s at high speed through the integer digits and some symbols (difficult to see whichones w�but it appears to change for every point plotted when it does !
I tried a few other combinations of the iput values as well as varying the angle value.
Results appear arbitrary.
50000 & 50 for example gives only a small aount of variation on curly wurly 12.
Probably not much use these comments but you never know.
Whatever it turns out to be I'm sure, as is usual in programmingll,the reason wi be found to be something https://www.youtube.com/watch?v=5Qf6Sv3A9zs
In the meantime a bit of background music to focus your mind on while watching those hypnotising spirographical generations (do they have a name btw ?) in action ..... https://www.youtube.com/watch?v=UZHgxA1S1DMu
(there's also a punk version if you search on YT - useful for those difficult 'devilry' moments. |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Sat Sep 23, 2017 12:01 am Post subject: |
|
|
John,
I forgot to mention the flicker, which is slightly irritating.
I guess Paul will read this in despair and remind us that users will always find faults, and we are all trying to plot different data over widely different ranges, but clearly the algorithm for selecting the scales needs improved. I know from my own experience that automatic selection of scales and format codes is difficult - caused me a lot of grief over the years with my own plotting routines - there's always some data that breaks the algorithm and I end up looking at ******!
These loci, which have fascinated me for many years are Euler Spirals.
Ken |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7934 Location: Salford, UK
|
Posted: Sat Sep 23, 2017 8:22 am Post subject: |
|
|
By today's standards, the original 32 bit %pl does not produce polished results and my aim was to port it to 64 bits. I am limited by a) starting from an existing interface and b) other demands on my time.
I am pleased that the native %pl is being used and that it often produces results that can be published in professional journals. At the same time I have to avoid the "black hole" of continual improvements.
Initially I did not contemplate log-log scales with data from a random number generator with values out of range but the native %pl now has a reasonable go at it.
Making the tick marks and values always right for various scalings and fonts is unfortunately beyond my capacity in the time at my disposal. So for some data and some purposes the native %pl may not be good enough.
Having said all of that I am grateful to Ken and mecej4 for reporting bugs that should be easy to fix. |
|
Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012 Posts: 697 Location: Hamilton, Lanarkshire, Scotland.
|
Posted: Sat Sep 23, 2017 1:41 pm Post subject: |
|
|
Paul, the new %pl is a great addition. I am beginning to see more ways to use it in interactive programs and it removes one on the primary reasons I have a tendency towards procrastination. Hopefully the forum collective will not identify too many bugs but post some good working examples.
Thanks for your efforts. It is appreciated.
Ken |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Sep 24, 2017 6:09 pm Post subject: |
|
|
Paul,
amongst all the spiraly wurlings you musn't have seen my simple question ...
What are the current MAXIMUMs for:
Number of curves (graphs) per plot (i.e. N_GRAPHS ) ?
Number of points per curve (graph) ?
I can't find mention of the limits in the documentation.
Ta. |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Sep 24, 2017 6:12 pm Post subject: |
|
|
2nd question is, why don't the scales labelling always use the same format once it has been determined ?
we've seen this in several examples and I don't understand how it can possibly change from one to another .... unless the format is decided for each individual value ? which would seem odd if it is, although no doubt with good reason |
|
Back to top |
|
|
|
|
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
|