INTRINSIC STATEMENT for functions overloaded for user defined types
in [Fortran]
|
From: Hifi-Comp on 17 Sep 2009 23:17 On Sep 17, 10:02 pm, steve <kar...(a)comcast.net> wrote: > On Sep 17, 5:11 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote: > > > > > > > On Sep 17, 5:46 pm, steve <kar...(a)comcast.net> wrote: > > > > On Sep 17, 2:25 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote: > > > > > On Sep 16, 11:27 pm, steve <kar...(a)comcast.net> wrote: > > > > > > On Sep 16, 8:09 pm, nos...(a)see.signature (Richard Maine) wrote: > > > > > > > steve <kar...(a)comcast.net> wrote: > > > > > > > When you put "intrinsic sin" in your code, you are telling the Fortran > > > > > > > processor that when it encounters the symbol 'sin' that it is the > > > > > > > intrinsic procedure defined in the standard. You, as the programmer writing a > > > > > > > program that a compiler will compile, cannot write an intrinsic > > > > > > > procedure it is entity provided by the Fortran processor. > > > > > > > Well, that was what it did in f77. In f90 and later it is more > > > > > > complicated because of generic resolution rules. > > > > > > Given that Hifi-comp is modifying BLAS from netlib and given > > > > > Hifi-comp's post of the last few days, the intricacies to which > > > > > you elude ... > > > > > > > You can, in fact, extend the generic sin with user-written specifics. > > > > > > You can even override some of the standard's specifics. The details of > > > > > > generic resolution, including how it is affected by a declaration like > > > > > > "INTRINSIC SIN" are complicated - enough so that I don't have them > > > > > > memorized. And no, I don't feel like trying to describe them fully here. > > > > > > Doing a full description is a lot of work; I know because I did that > > > > > > once (insert self-promoting pitch for book). > > > > > > > Fortunately, most of the time it is simple and you don't need the full > > > > > > rules. But if you really do want the full story, I don't think it is > > > > > > accurately summarized by the above. > > > > > > ... are probably irrelevant. > > > > > > -- > > > > > steve > > > > > Thanks a lot Steve. In fact, what I am trying to do is not to avoid > > > > modifying BLAS if at all possible, but let it do the math of the new > > > > data structure I defined. I myself never used the INTRINSIC statement > > > > before. So the more relevant question is: can I just simply delete the > > > > INTRINSIC statement if the function is overloaded to the new data > > > > type? Or can I simply change the statement to another statement and it > > > > will not have any side effects? I am an engineer, and trying to dig > > > > out the details in the standard making my head big. It is way beyond > > > > my comprehension. > > > > The simple thing to do is to remove INTRINSIC SIN from DDOT > > > and see what happens. > > > > troutmask:sgk[261] gfc4x -o z dnad.f90 test1.f90 blas.f > > > troutmask:sgk[262] ./z > > > 0.84147098480789650 0.54030230586813977 > > > > PS: If it's of any comfort, I also get headaches after reading the > > > Standard. > > > > -- > > > steve- Hide quoted text - > > > > - Show quoted text - > > > Steve, > > > Thanks for your comfort. The code I provided is not real. In the real > > blas.for, there are several INTRINSIC statements. It might not be > > possible for me to exhaust all the possibilities. Hence I want to know > > what INTRINSIC does in addition to pass a intrinsic procedure as an > > argument. Note, Compaq Visual Fortran has no complains about the > > INTRINSIC statement and the compiled code behaves nicely. In other > > words, how does CVF handle this situation. > > See my previous post. Remove the INTRINSIC statments. > > -- > steve- Hide quoted text - > > - Show quoted text - So that if I remove such statements and the compiler does not complain, I am probably ok?
From: steve on 18 Sep 2009 00:01 On Sep 17, 8:17 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote: > On Sep 17, 10:02 pm, steve <kar...(a)comcast.net> wrote: > > > > > On Sep 17, 5:11 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote: > > > > On Sep 17, 5:46 pm, steve <kar...(a)comcast.net> wrote: > > > > > On Sep 17, 2:25 pm, Hifi-Comp <wenbinyu.hea...(a)gmail.com> wrote: > > > > > > On Sep 16, 11:27 pm, steve <kar...(a)comcast.net> wrote: > > > > > > > On Sep 16, 8:09 pm, nos...(a)see.signature (Richard Maine) wrote: > > > > > > > > steve <kar...(a)comcast.net> wrote: > > > > > > > > When you put "intrinsic sin" in your code, you are telling the Fortran > > > > > > > > processor that when it encounters the symbol 'sin' that it is the > > > > > > > > intrinsic procedure defined in the standard. You, as the programmer writing a > > > > > > > > program that a compiler will compile, cannot write an intrinsic > > > > > > > > procedure it is entity provided by the Fortran processor. > > > > > > > > Well, that was what it did in f77. In f90 and later it is more > > > > > > > complicated because of generic resolution rules. > > > > > > > Given that Hifi-comp is modifying BLAS from netlib and given > > > > > > Hifi-comp's post of the last few days, the intricacies to which > > > > > > you elude ... > > > > > > > > You can, in fact, extend the generic sin with user-written specifics. > > > > > > > You can even override some of the standard's specifics. The details of > > > > > > > generic resolution, including how it is affected by a declaration like > > > > > > > "INTRINSIC SIN" are complicated - enough so that I don't have them > > > > > > > memorized. And no, I don't feel like trying to describe them fully here. > > > > > > > Doing a full description is a lot of work; I know because I did that > > > > > > > once (insert self-promoting pitch for book). > > > > > > > > Fortunately, most of the time it is simple and you don't need the full > > > > > > > rules. But if you really do want the full story, I don't think it is > > > > > > > accurately summarized by the above. > > > > > > > ... are probably irrelevant. > > > > > > > -- > > > > > > steve > > > > > > Thanks a lot Steve. In fact, what I am trying to do is not to avoid > > > > > modifying BLAS if at all possible, but let it do the math of the new > > > > > data structure I defined. I myself never used the INTRINSIC statement > > > > > before. So the more relevant question is: can I just simply delete the > > > > > INTRINSIC statement if the function is overloaded to the new data > > > > > type? Or can I simply change the statement to another statement and it > > > > > will not have any side effects? I am an engineer, and trying to dig > > > > > out the details in the standard making my head big. It is way beyond > > > > > my comprehension. > > > > > The simple thing to do is to remove INTRINSIC SIN from DDOT > > > > and see what happens. > > > > > troutmask:sgk[261] gfc4x -o z dnad.f90 test1.f90 blas.f > > > > troutmask:sgk[262] ./z > > > > 0.84147098480789650 0.54030230586813977 > > > > > PS: If it's of any comfort, I also get headaches after reading the > > > > Standard. > > > > > -- > > > > steve- Hide quoted text - > > > > > - Show quoted text - > > > > Steve, > > > > Thanks for your comfort. The code I provided is not real. In the real > > > blas.for, there are several INTRINSIC statements. It might not be > > > possible for me to exhaust all the possibilities. Hence I want to know > > > what INTRINSIC does in addition to pass a intrinsic procedure as an > > > argument. Note, Compaq Visual Fortran has no complains about the > > > INTRINSIC statement and the compiled code behaves nicely. In other > > > words, how does CVF handle this situation. > > > See my previous post. Remove the INTRINSIC statements. > > > -- > > steve- Hide quoted text - > > > - Show quoted text - > > So that if I remove such statements and the compiler does not > complain, I am probably ok? Well, I don't have blas.for nor a pointer to where to get blas.for, so I can't say with any certainty. I've also never tried to overload the name of an intrinsic procedure, so I can't say with certainty that whatever you're trying to do will work. So, let's try one more time. Remove the INTRINSIC statement. Then see what happens. I suspect that it will work just fine. -- steve
From: John Harper on 20 Sep 2009 18:07 Hifi-Comp said >So that if I remove such statements and the compiler does not >complain, I am probably ok? That's neither a necessary nor a sufficient condition for correctness. Not necessary as the compiler may have a bug. Not sufficient as you may have a standard-conforming program calculating something different from what you thought it was. I don't believe my results unless I have tried at least 2 compilers and done some checking of the run-time output. And contributors to this newsgroup have helped me many times when I'm still confused after doing that, especially when 2 or more of them disagree :-) -- John Harper
First
|
Prev
|
Pages: 1 2 3 Prev: reading config file Next: IMSL, NAG Fortran Library vs. Open Source libraries |