 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
DanRRight
Joined: 10 Mar 2008
Posts: 2777
Location: South Pole, Antarctica
|
|
| Back to top |
|
 |
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
 Posted: Sun May 17, 2020 8:58 pm Post subject: |
 |
|
Dan, I suppose you mean the plot hanging over the menus on the rh side of the page ?
Same in Firefox.
I have noted of late what appears to be the beginning of a re-hash of the online documenttion, ranging t=from a fundamental font hange to the addition of some plots (always welcome - a picture's better than a dozen lines of text, etc ....) and diagrams (example results of code snippets).
Only to be expected a few teething troubles I'd guess.
Would be interesting to know what the overall strategy is though.
_________________
''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 ...  " |
|
| Back to top |
|
|
silverfrost
Site Admin
Joined: 29 Nov 2006
Posts: 191
Location: Manchester
|
| Posted: Thu Jun 25, 2020 9:32 am Post subject: |
|
|
| Finally fixed that one. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2505
Location: Sydney
|
| Posted: Fri Jun 26, 2020 9:24 am Post subject: |
|
|
Could have a few improvements to the code.
Fixes to new_x, last_x and parameter.
I tried the following adaptation, but it would not compile. I thought RGB@ was a FTN95 intrinsic ?
Anyway, possible tidy-ups, but may need some more ? | Code: | PROGRAM main
use clrwin
integer, external :: winio@
integer, parameter :: width = 800, height = 350, gutter = 20
integer :: black = 0, red ! = RGB@(255,0,0)
integer :: iw, ctrl
integer :: last_x, last_y, mid_y, len_x
integer :: new_x, new_y
real :: x,y
!
red = RGB@(255,0,0)
iw = winio@ ('%ca[sin(x)exp(-x/10)]&')
! set up the surface to draw onto. Remove [smooth4] to see what anti-aliasing has given you
!z iw = winio@ ('%gr&', width, height)
iw = winio@ ('%gr[smooth4]&', width, height)
iw = winio@ ('%lw', ctrl)
! draw axes
mid_y = height / 2
len_x = width-(2*gutter)
call draw_line_between@ (gutter, gutter, gutter, width-gutter, black )
call draw_line_between@ (gutter, mid_y, width-gutter, mid_y, black )
do i = 0,len_x
! make the width of the x-axis span 0..8pi. REAL(len_x) is the width of that axis
x = (i/REAL(len_x))*8*3.1415926
y = sin(x)*exp(-x / 10)
new_x = gutter+i
new_y = mid_y + y*(mid_y-gutter)
if (i > 0) then
call draw_line_between@ (last_x, last_y, new_x, new_y, red )
end if
last_x = new_x
last_y = new_y
end do
END PROGRAM main |
|
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1840
|
| Posted: Fri Jun 26, 2020 11:09 am Post subject: Using intrinsic functions in initialization expressions |
|
|
| JohnCampbell wrote: | | I thought RGB@ was a FTN95 intrinsic ? |
Only some intrinsic functions may be used in initialization expressions. See docs for list.
The explanation for this is that such intrinsics would have to be called and the function values evaluated at compile time. Letting all intrinsic functions become available here would require the compiler itself to contain code for all these functions, which codes are now most often in run-time libraries.
Finally, RGB@ is an extension provided by FTN95.
Last edited by mecej4 on Fri Jun 26, 2020 1:35 pm; edited 1 time in total |
|
| Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012
Posts: 682
Location: Hamilton, Lanarkshire, Scotland.
|
| Posted: Fri Jun 26, 2020 12:54 pm Post subject: |
|
|
Thanks mecej4, that answers why ftn95 does not allow the following, whilst other compilers do.
| Code: | real*8, parameter :: pi = 4.d0*atan(1.d0)
print*, pi
end |
|
|
| Back to top |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1840
|
| Posted: Fri Jun 26, 2020 1:47 pm Post subject: Re: |
|
|
| Kenneth_Smith wrote: | Thanks mecej4, that answers why ftn95 does not allow the following, whilst other compilers do.
| Code: | real*8, parameter :: pi = 4.d0*atan(1.d0)
print*, pi
end |
|
That code is allowed in F2003 and later. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Sat Jun 27, 2020 7:07 am Post subject: |
|
|
The error report 921 can be suppressed in this context by using /ignore 921 on the FTN95 command line.
I will review this and similar cases. |
|
| Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012
Posts: 682
Location: Hamilton, Lanarkshire, Scotland.
|
| Posted: Sat Jun 27, 2020 12:56 pm Post subject: |
|
|
Thanks Paul,
So I can define the complex 'j' and 'a' operators used in circuit analysis as parameters 
| Code: | winapp
options (ignore 921)
integer, parameter :: dp = kind(1.d0)
real(kind=dp), parameter :: pi = 4.d0*atan(1.d0)
real(kind=dp), parameter :: twopi = 2.d0*pi
real(kind=dp), parameter :: piover3 = pi/3.d0
real(kind=dp), parameter :: twopiover3 = twopi/3.d0
real(kind=dp), parameter :: sqrt2 = sqrt(2.d0)
real(kind=dp), parameter :: sqrt3 = sqrt(3.d0)
real(kind=dp), parameter :: oneoversqrt2 = 1.d0/sqrt2
real(kind=dp), parameter :: oneoversqrt3 = 1.d0/sqrt3
complex(kind=dp), parameter :: j = cmplx(0.d0,1.d0,kind=dp)
complex(kind=dp), parameter :: a = cmplx(-0.5d0,sqrt3*0.5d0,kind=dp)
real(kind=dp), parameter :: e = exp(1.d0)
real(kind=dp), parameter :: c = 299792458.d0
real(kind=dp), parameter :: mhu0 = 4.d0*pi*(10.d0**(-7))
real(kind=dp), parameter :: epsilon0 = 1.d0/(mhu0*c*c)
!complex(kind=dp), parameter :: a = exp(j*(twopi/3.d0)) !##### Does not like these forms
!complex(kind=dp), parameter :: a = exp(j*twopiover3) !#####
!complex(kind=dp), parameter :: a = e**(j*twopiover3) !#####
print*, 'Real maths constants'
print*, 'pi ', pi
print*, 'twopi ', twopi
print*, 'piover3 ', piover3
print*, 'twopiover3', twopiover3
print*, 'sqrt2 ', sqrt2
print*, 'sqrt3 ', sqrt3
print*, '1/sqrt2 ', oneoversqrt2
print*, '1/sqrt3 ', oneoversqrt3
print*
print*, 'Complex contants used in phasor analysis of ac circuits'
print*, 'j ', j
print*, '1*j*j ', 1.d0*j*j
print*, '1*j*j*j ', 1.d0*j*j*j
print*, '1*j*j*j*j ', 1.d0*j*j*j*j
print*, 'a ', a
print*, '1*a*a ', 1.d0*a*a
print*, '1*a*a*a ', 1.d0*a*a*a
print*
print*, 'Physical contants used in power systems'
print*, 'e ', e
print*, 'c ', c
print*, 'mhu0 ', mhu0
print*, 'epsilon0 ', epsilon0
end |
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Sat Jun 27, 2020 1:59 pm Post subject: |
|
|
Ken
Yes if you get the correct results.
They should all work without error in the next release of FTN95. |
|
| Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012
Posts: 682
Location: Hamilton, Lanarkshire, Scotland.
|
| Posted: Sat Jun 27, 2020 3:30 pm Post subject: |
|
|
That’s great. I can expand this to also protect (as PARAMETERS) a number of complex transformation/connection matrices as well.
This will certainly eliminate some future head scratching!
| Code: | winapp
options (ignore 921)
implicit none
integer, parameter :: dp = kind(1.d0)
complex(kind=dp), parameter :: a = cmplx(-0.5d0,sqrt(3.d0)*0.5d0,kind=dp)
complex(kind=dp), parameter :: c1 = cmplx(1.d0,kind=dp)
complex(kind=dp), parameter :: a_mat(3,3) = reshape((/c1,c1,c1,c1,a*a,a,c1,a,a*a/),shape(a_mat))
complex(kind=dp), parameter :: inv_a_mat(3,3) = (1.d0/3.d0)*reshape((/c1,c1,c1,c1,a,a*a,c1,a*a,a/),shape(inv_a_mat))
complex(kind=dp) check(3,3)
integer row, col
print*
print*, 'Transformation matrix 012 to ABC'
print*
do row = 1, 3
print*, (a_mat(row,col),col=1,3)
end do
print*
print*, 'Transformation matrix ABC to 012'
print*
do row = 1, 3
print*, (inv_a_mat(row,col),col=1,3)
end do
check = matmul(a_mat,inv_a_mat)
print*
print*, 'Matrix product of transformation matrices, should be the identity matrix'
print*
do row = 1, 3
print*, (check(col,row),col=1,3)
end do
end |
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Sat Jun 27, 2020 4:28 pm Post subject: |
|
|
These will all work but not the ones that you have commented out...
| Code: | complex(kind=dp), parameter :: a1 = exp(j*(twopi/3.d0)) !##### FTN95 Does not like these forms
complex(kind=dp), parameter :: a2 = exp(j*twopiover3) !#####
complex(kind=dp), parameter :: a3 = e**(j*twopiover3) !#####
|
|
|
| Back to top |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Sat Jun 27, 2020 6:01 pm Post subject: |
|
|
Paul wrote:
| Quote: | | The error report 921 can be suppressed in this context by using /ignore 921 on the FTN95 command line. |
I assume this is an eror message which JohnC got running his problem ?
then
| Quote: | Ken
Yes if you get the correct results.
They should all work without error in the next release of FTN95. |
Doesn't this show the inherent misgivings about over-riding errors being flagged ?
If an error is flaggd it's for a good reason.
Letting 'the program 'go' ' may be useful for debugging porpoises but the danger is that people can use it, to create a program which has errors in it !!!
There should be a BIG WARNING in the documentation about the possible consequences, and imo there should also be a BIG WARNING MESSAGE in the compile time and runtime echos which also warns of this !!!
The 'should' in the last line makes me nervous.
_________________
''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 ... " |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 7772
Location: Salford, UK
|
| Posted: Sat Jun 27, 2020 8:39 pm Post subject: |
|
|
This illustrates an exception that proves the rule. It is simply an error because it does not conform to the Fortran 95 standard. It is permitted in the Fortran 2003 standard and FTN95 will catch up with this in the next release.
Take away the error report and all is OK. The fix can be safely anticipated in this context because the values are parameters that are there to see and can not change as the program runs. |
|
| Back to top |
|
|
John-Silver
Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley
|
| Posted: Sun Jun 28, 2020 5:25 pm Post subject: |
|
|
So,it would be better classified (and flagged up) as a, for example' 'CONFLICT WITH STANDARD ERROR' message rather than simply an ERROR message ... to avoid confusing fools like me.
_________________
''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 ... " |
|
| 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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
