replica nfl jerseysreplica nfl jerseyssoccer jerseyreplica nfl jerseys forums.silverfrost.com :: View topic - The first argument (A) to intrinsic DABS must be of REAL?
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 

The first argument (A) to intrinsic DABS must be of REAL?

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



Joined: 03 Dec 2012
Posts: 31

PostPosted: Fri Dec 14, 2012 10:13 am    Post subject: The first argument (A) to intrinsic DABS must be of REAL? Reply with quote

I have a line of command as follows"

DIX(I) = DABS((DIXR + DIXL)/2.0)

Compiler gives the following error message

The first argument (A) to the intrinsic DABS must be of REAL(KIND=2) type, not REAL(KIND=1)

What is the meaning of this message?
Where can I afind info on FORTRAN commands from SilverFrost on DABS?
I don't understand the what does it mean by first argument (A) and also the kind 1 and 2 on Real.
Back to top
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 506
Location: Sunderland

PostPosted: Fri Dec 14, 2012 12:59 pm    Post subject: Reply with quote

The generic function is "ABS()", whereas "DABS" is expecting a double precision/real*8 variable.
The following would work:
Code:

      REAL*8 DIXR, DIXL
      DIX(I) = DABS((DIXR + DIXL)/2.0)

Your code must be using single precision for the variable, i.e. "REAL*4" and therefore only has about 7 digits precision, REAL*8 is a much better option for all your variables. The "/DREAL" compilation option can help otherwise define every real variable as REAL*8.
Code:

      IMPLICIT REAL*8 (A-H,O-Z)
as the first statement of a routine will ensure that the standard Fortran assignments of real variables uses the higher precision.

Actually, you don't need to use "DABS()" at all these days, just use "ABS()" for any numeric variable and the compiler will sort it out.
The same really goes for other functions that at one time requred preceding by a D or an I, e.g. IABS, DCOS etc.

In your case, the first argument is everything in the brackets "(DIXR + DIXL)/2.0" as there is only one argument for this function. An argument being an input/output variable or and input value/expression.

Real kind 1 is a real number stored in 4 bytes.
Real kind 2 is a real number stored in 8 bytes.
Real kind 3 is a real number stored in 10 bytes for FTN95.

Ian
Back to top
View user's profile Send private message Send e-mail
khoshravan



Joined: 03 Dec 2012
Posts: 31

PostPosted: Fri Dec 14, 2012 5:03 pm    Post subject: Re: Reply with quote

IanLambley wrote:
The generic function is "ABS()", whereas "DABS" is expecting a double precision/real*8 variable.
The following would work:
Code:

      REAL*8 DIXR, DIXL
      DIX(I) = DABS((DIXR + DIXL)/2.0)

Your code must be using single precision for the variable, i.e. "REAL*4" and therefore only has about 7 digits precision, REAL*8 is a much better option for all your variables. The "/DREAL" compilation option can help otherwise define every real variable as REAL*8.
Code:

      IMPLICIT REAL*8 (A-H,O-Z)
as the first statement of a routine will ensure that the standard Fortran assignments of real variables uses the higher precision.

Actually, you don't need to use "DABS()" at all these days, just use "ABS()" for any numeric variable and the compiler will sort it out.
The same really goes for other functions that at one time requred preceding by a D or an I, e.g. IABS, DCOS etc.

In your case, the first argument is everything in the brackets "(DIXR + DIXL)/2.0" as there is only one argument for this function. An argument being an input/output variable or and input value/expression.

Real kind 1 is a real number stored in 4 bytes.
Real kind 2 is a real number stored in 8 bytes.
Real kind 3 is a real number stored in 10 bytes for FTN95.

Ian


Dear Ian

Thanks a lot for your valuable information. Now I understand what is the issue.

Just one more question.
In the beginning of my code, it is declared as

IMPLICIT Real*8 (A-H,O-Z)

As you have mentioned. I supposed having this declaration, it should work, but it didn't.
Also I have to add that after compilation it gets error and stops in the IMPLICIT line.

Will be happy to know your opinion
Back to top
View user's profile Send private message
khoshravan



Joined: 03 Dec 2012
Posts: 31

PostPosted: Fri Dec 14, 2012 5:05 pm    Post subject: Re: Reply with quote

[quote="IanLambley"]The generic function is "ABS()", whereas "DABS" is expecting a double precision/real*8 variable.
The following would work:[code]
REAL*8 DIXR, DIXL
DIX(I) = DABS((DIXR + DIXL)/2.0)
[/code]
Your code must be using single precision for the variable, i.e. "REAL*4" and therefore only has about 7 digits precision, REAL*8 is a much better option for all your variables. The "/DREAL" compilation option can help otherwise define every real variable as REAL*8.
[code]
IMPLICIT REAL*8 (A-H,O-Z)
[/code] as the first statement of a routine will ensure that the standard Fortran assignments of real variables uses the higher precision.

Actually, you don't need to use "DABS()" at all these days, just use "ABS()" for any numeric variable and the compiler will sort it out.
The same really goes for other functions that at one time requred preceding by a D or an I, e.g. IABS, DCOS etc.

In your case, the first argument is everything in the brackets "(DIXR + DIXL)/2.0" as there is only one argument for this function. An argument being an input/output variable or and input value/expression.

Real kind 1 is a real number stored in 4 bytes.
Real kind 2 is a real number stored in 8 bytes.
Real kind 3 is a real number stored in 10 bytes for FTN95.

Ian[/quote]

Dear Ian

Thanks a lot for your valuable information. Now I understand what is the issue.

Just one more question.
In the beginning of my code, it is declared as

IMPLICIT Real*8 (A-H,O-Z)

As you have mentioned. I supposed having this declaration, it should work, but it didn't.
Also I have to add that after compilation it gets error and stops in the IMPLICIT line.

Will be happy to know your opinion
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2402
Location: Yateley, Hants, UK

PostPosted: Fri Dec 14, 2012 9:12 pm    Post subject: Reply with quote

The problem is the type of the expression. If A and B are of type REAL*8,and the constant 2.0 is of type REAL*4, then it is possible that (A+B)/2.0 is REAL*4, and indeed, (A+B)/2 might turn out to be INTEGER! (Before anyone blasts me over this, I can never remember the exact rules). However, if A and B are definitely REAL*8, then (A+B)/2.0D0 (where the constant is also definitely REAL*8) will evaluate to a REAL*8 result.

Back in 1980 when your program was written, your REAL variables could easily have been 32 bits, 48 bits, or 60 bits long on the target computer, and if the standard length of a REAL was 48 bits or more, then single precision might have given a reasonable result. Also, it is quite possible that the compiler used was Fortran-66 and not Fortran 77, and so you had REAL and DOUBLE PRECISION and not REAL*4 or 8, and certainly none of the KIND stuff that came in the Fortran-90.

Eddie.
Back to top
View user's profile Send private message
davidb



Joined: 17 Jul 2009
Posts: 560
Location: UK

PostPosted: Fri Dec 14, 2012 10:23 pm    Post subject: Re: Reply with quote

LitusSaxonicum wrote:
The problem is the type of the expression. If A and B are of type REAL*8,and the constant 2.0 is of type REAL*4, then it is possible that (A+B)/2.0 is REAL*4, and indeed, (A+B)/2 might turn out to be INTEGER! (Before anyone blasts me over this, I can never remember the exact rules).


The rule is that a mixed precision expression like (A+B)/2.0 has the highest precision amongst the variables and constants. So if A or B are REAL*8 (double precision, kind=2) then the result will be REAL*8. BAsically, all REAL*4 variables/constants are promoted to REAL*8 before the calculation is performed.

Having said this, I tend not to use mixed mode very much, and would prefer to write the above as (A + B) / 2.0D0 or (A + B)*0.5D0 or (A+B)*0.5_wp where integer, parameter :: wp=kind(0.0d0).
_________________
Programmer in: Fortran 77/95/2003/2008, C, C++ (& OpenMP), java, Python, Perl
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2402
Location: Yateley, Hants, UK

PostPosted: Sat Dec 15, 2012 12:23 am    Post subject: Reply with quote

Thanks David (I said I could never remember). Certainly, if ever one assigns intermediate results to variables, you get the precision of the variable, not of the calculation ...

Not remembering the rules is a good reason to avoid mixed mode.

Eddie
Back to top
View user's profile Send private message
khoshravan



Joined: 03 Dec 2012
Posts: 31

PostPosted: Fri Dec 21, 2012 10:58 am    Post subject: Re: Reply with quote

LitusSaxonicum wrote:
Thanks David (I said I could never remember). Certainly, if ever one assigns intermediate results to variables, you get the precision of the variable, not of the calculation ...

Not remembering the rules is a good reason to avoid mixed mode.

Eddie


Above problem is solved thanks for all replies.
Now it gives following error message:
StackOverflowException was unhandled.
An unhandled exception of type 'system.StackOverflowException' occured in filename.exe.

It referes to following line in the code:
IMPLICIT REAL*8(A-H,O-Z)

Do you have any idea what is problem?
Back to top
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 506
Location: Sunderland

PostPosted: Fri Dec 21, 2012 1:36 pm    Post subject: Reply with quote

The IMPLICIT type of statement would need to be in each program segment where it is to apply. This type of statement, generally needs to be the first statement in the program segment after the "subroutine" or "function" statements.

Other definitions can override this and consistency is vital.

The error does not really appear to be caused by that statement as it is a run time error rather than a compilation error. It is something elsewhere in the overall program assembly. We would need to see the code. Send me a private message with your e-mail so we can communicate.

Regards
Ian
Back to top
View user's profile Send private message Send e-mail
khoshravan



Joined: 03 Dec 2012
Posts: 31

PostPosted: Fri Dec 21, 2012 6:30 pm    Post subject: Re: Reply with quote

[quote="IanLambley"]The IMPLICIT type of statement would need to be in each program segment where it is to apply. This type of statement, generally needs to be the first statement in the program segment after the "subroutine" or "function" statements.

Other definitions can override this and consistency is vital.

The error does not really appear to be caused by that statement as it is a run time error rather than a compilation error. It is something elsewhere in the overall program assembly. We would need to see the code. Send me a private message with your e-mail so we can communicate.

Regards
Ian[/quote]


Dear Ian

You are correct. Visual Studio stops at this line (IMPLICIT), because it is the first line of the code just after the comments. Also it is repeated at all subroutines.

My email is: khoshravan at gmail.com

I couldn't find any button to attach the code. Shall I copy/paste it here? Or I will wait for your email add to send as attachment.

Your cooperation is highly appreciated.
Back to top
View user's profile Send private message
khoshravan



Joined: 03 Dec 2012
Posts: 31

PostPosted: Fri Dec 21, 2012 6:31 pm    Post subject: Re: Reply with quote

Dear Ian

I faced an error sending a pm to you. Also another error occurred while sending reply to your post. But apparently has been sent despite getting error as I can see it in the list. It is a bit strange but anyway I am waiting your reply or email.

BR
Khoshravan
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 -> Support 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