Welcome to our forums
I am wanting to generate plots based on historical data over a period of years.
Can %PL provide an X axis as date format ?
This also requires the conversion of date to a reference date. Please not 1/1/1900 with the Excel error. Perhaps using 1/1/1 as the first day ? with function JDATE
What might be available ?
John
The native %pl uses %gr so you can call draw_characters@ to draw text. Also link=columns can be used to present vertical columns. The function GET_PLOT_POINT@ gets the pixel coordinates of a particular point relative to the axes.
Here is a simple example that calls draw_characters@...
WINAPP
MODULE mydata
USE clrwin
INTEGER,PARAMETER::n=1000,link_none=0,link_lines=1,link_curves=2
INTEGER,PARAMETER::all_graphs=0,graph1=0
LOGICAL shown
DOUBLE PRECISION y(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)
shown = .true.
CALL simpleplot_redraw@()
show = 2
END FUNCTION show
INTEGER FUNCTION clear()
INTEGER errstate
call clear_screen@()
errstate = change_plot_int@(0,'link',graph1,link_none)
shown = .false.
CALL simpleplot_redraw@()
clear = 2
END FUNCTION clear
INTEGER FUNCTION legend()
IF(shown .AND. clearwin_string@('CALLBACK_REASON') == 'PLOT_ADJUST') 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,z
!read*,i
p1=1.5d0
p2=150.0d0
p3=15d0
x=0
DO i=1,n
z=p1*sin(x/p3)*exp(-x/p2)
!print*, i-1,x,z
y(i) = z
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,gridlines]')
CALL winop@('%pl[title='Sample plot']')
CALL winop@('%pl[x_axis=Time(Milliseconds)]')
CALL winop@('%pl[y_axis=Amplitude]')
CALL winop@('%pl[smoothing=4]') ! anti-aliasing
CALL winop@('%pl[link=none]') ! delay drawing
!CALL winop@('%pl[scale=log_linear]')
i=winio@('%^pl',500,400,n,0.0d0,1.0d0,y,legend)
END
I can look later for date routines if no one else knows how to do this.
Here is a link to a module which has three subroutines based on the excel algorithm - without the 29/Feb/1900 bug.
Note: Link above has changed. Dragged the wrong file over to dropbox this morning.
Thanks Paul and Ken for your info.
This has given me a way forward.
The history of Julian years is interesting. I am not certain, but i think it was defined in about 45 BC. The year after 1 BC was 1 AD; no year 0 The concept of leap years being every 4 years was not finalised until about 25 AD, so the leap years that were applied between 45BC to 25AD are not as the present formulas define. (not sure of the accuracy of claimed leap years used before 25AD) So the formula for day of the week for the 1st of Jan for years prior to about 25AD is only arbitary.
I have been using a subroutine JDATE (below) to calculate the julian day since a nominal '1/1/1' for many years (since 2002), which can usefully be modified for any other reference 'day 1'. As for day of week, I have to keep checking, as I vary the day_1 reference.
integer*4 FUNCTION jdate (year,month,day)
!
! Converts DAY/MONTH/YEAR to a Julian date transformed to 1/1/2000
!
INTEGER*4 day, month, year, yyyy
!
if (year > 1800) then
yyyy = year
else if (year > 100) then
yyyy = -1
else if (year > 79) then
yyyy = year + 1900
else if (year > 0 ) then
yyyy = year + 2000
else
yyyy = -1
end if
!
! 'Tony T. Warnock' <u091889@lanl.gov>
! Sent by: fortran-owner@lahey.com
! 31/10/2002 02:04 AM
!
! jdate = 367*year
! 1 - 7*(year+(month+9)/12)/4
! 1 - 3*((year+(month-9)/7)/100+1)/4
! 1 + 275*month/9+day
! 1 - 730516
!
jdate = 367*yyyy &
- 7*(yyyy+(month+9)/12)/4 &
- 3*((yyyy+(month-9)/7)/100+1)/4 &
+ (275*month)/9 - 30 &
+ day $
- 1 ! 1/1/0
! offset for selected first day reference
! - 693961 ! 1900/1/1
! - 723180 ! 1980/1/1
! - 726833 ! 1990/1/1
! - 728659 ! 1995/1/1
! - 730485 ! 2000/1/1
!
END FUNCTION jdate
Interestingly, I have recently created a database of historical records, using 31 days in every month, which greatly simplifies the conversion from date to days and also simplifies the calculation of the number of months or years between two dates. It stores an extra 7 days per year, which is not much to waste! The day_of_week is not so easy using this simplification !
The current usage is from the Gregorian calendar (1582).
Satellite orbits are (sometimes) computed using Julian dates. This also allows ephemeris data from before the adoption of the Gregorian calendar to work smoothly for planetary calculations.
It is also interesting that Julian dates use solar noon as the start of the day, so satellite software subtracts 0.5 from the Julian time to reference midnight.
I'm not an expert; I learned this from working with orbital data and the tutelage of a mathematician who specialized in orbitology.
There is a short but fascinating discussion on the change from Julian and Gregorian calendars here:
Also answers the question why does the UK tax year start on the 6th April each year?
I first became aware of the accuracy of calendars when modelling tides. The accuracy of tidal prediction based on lunar and planetary movement is incredible. The history of the calendar is also amazing. First to consider how they were able to predict leap years so accurately (Ceasar 45 BC) based on the period of planetary movements. While Pope Gregory adopted the latest calendar in 1582, Galileo was tried by the Inquisition for his views in 'Dialogue Concerning the Two Chief World Systems' (1632). Yet, after all this Microsoft declares 1900 was a leap year ! ( this has been annoying to me as many tide prediction coefficients have been based on 1-Jan-1900 )
The Gregorian calendar defines a cycle that has a period of 400 years. If you count the common years in that cycle, multiply by 365, and add 366 times the number of leap years in that cycle, you get a multiple of 7, which explains why our current calendars are, in essence, so simple. Here is a function that returns an integer day-of-week, with 0-7 signifying Su-Sa:
function dowts(y,m,d) !0-6, Su to Sa
! Tomohiko Sakamoto
implicit none
integer, intent(in) :: y,m,d
integer :: t(12)= &
[0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4]
integer :: mm, yy,v,yl,dowts;
yl=y; if (M < 3)yl=y-1
v=Yl + Yl / 4 - Yl / 100 + Yl / 400
v=v+t(m)+d
dowts=mod(v,7)
return
end function dowts
If you add this routine to your own code, it is up to you to check that the input arguments are valid: for instance, if d =30 for m=2, or d=31 for m=4, etc., you will not obtain a correct day-of-week!
The following is a noteworthy occurrence and you may wish to write a short main program that invokes dowts() (code posted above) to verify it (and reinforce @danrright's devotion to Devilry): Next year, there are three months in which Friday the 13th exists. The sum of the month numbers is 16 (if someone says 'sixteen', I am tempted to say, 'bless you'), and the doomsday of 2026 is 'Saturday'. In some cultures, Saturn is associated with a localized version of Satan. From, the Web, I note: '2015 was the last time this happened - it occurs in 1/7 of years, but not evenly spaced. (any common year where 1/1 is Thursday or leap year where 1/1 is Sunday; 2009 and 2012 both had it, but 2037 is the next occurrence after 2026. It would seem that three Friday-13ths in a year is a more rare occurrence than eclipses! Here is a list of such years starting from 1900: 1903, 1914, 1925,1928, 1931, 1942 1953,1956,1959 1970 1981,1984,1987, 1998, 2009,2012,2015, 2026, 2037, 2040,2043