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 

Corrupted page

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
DanRRight



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

PostPosted: Sat May 16, 2020 3:55 pm    Post subject: Corrupted page Reply with quote

This main page for Clearwin of Silverfrost website looks corrupted in Google Chrome browser
https://silverfrost.com/18/ftn95/clearwin.aspx
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Sun May 17, 2020 8:58 pm    Post subject: Reply with quote

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 ... Smile "
Back to top
View user's profile Send private message
silverfrost
Site Admin


Joined: 29 Nov 2006
Posts: 191
Location: Manchester

PostPosted: Thu Jun 25, 2020 9:32 am    Post subject: Reply with quote

Finally fixed that one.
Back to top
View user's profile Send private message Visit poster's website
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Fri Jun 26, 2020 9:24 am    Post subject: Reply with quote

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
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Fri Jun 26, 2020 11:09 am    Post subject: Using intrinsic functions in initialization expressions Reply with quote

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
View user's profile Send private message
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Fri Jun 26, 2020 12:54 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mecej4



Joined: 31 Oct 2006
Posts: 1884

PostPosted: Fri Jun 26, 2020 1:47 pm    Post subject: Re: Reply with quote

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
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Jun 27, 2020 7:07 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Sat Jun 27, 2020 12:56 pm    Post subject: Reply with quote

Thanks Paul,

So I can define the complex 'j' and 'a' operators used in circuit analysis as parameters Very Happy

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Sat Jun 27, 2020 1:59 pm    Post subject: Reply with quote

Ken

Yes if you get the correct results.

They should all work without error in the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Sat Jun 27, 2020 3:30 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Sat Jun 27, 2020 4:28 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
John-Silver



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

PostPosted: Sat Jun 27, 2020 6:01 pm    Post subject: Reply with quote

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 ... Smile "
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Jun 27, 2020 8:39 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
John-Silver



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

PostPosted: Sun Jun 28, 2020 5:25 pm    Post subject: Reply with quote

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 ... 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 -> Suggestions All times are GMT + 1 Hour
Page 1 of 1

 
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