Home > Archive > Fortran > January 2008 > allocating arrays, trouble
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
allocating arrays, trouble
|
|
| Förster vom Silberwald 2007-11-26, 4:25 am |
| ==
program unhappy
integer :: buff1=100,bugg2=500
....
contains
subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
real*8, dimension(buff1,buff1,buff2) :: ger
real*8, dimension(buff1,buff2) :: ger2
.....
end subroutine i_want_my_bigloo_compiler_back
==
will give me a segmentation fault after executing a.out.
However:
==
integer :: buff1=100,buff2=500
contains
subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
real*8, dimension(100,100,5000) :: ger
real*8, dimension(buff1,buff2) :: ger2
.....
==
works.
ifort -convert big_endian unhappy.f90
Thanks
| |
| Förster vom Silberwald 2007-11-26, 4:25 am |
| On Nov 26, 9:21 am, "F=F6rster vom Silberwald" <chain_l...@hotmail.com>
wrote:
> =3D=3D
> program unhappy
>
> integer :: buff1=3D100,bugg2=3D500
>
> ...
>
> contains
>
> subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
>
> real*8, dimension(buff1,buff1,buff2) :: ger
> real*8, dimension(buff1,buff2) :: ger2
> ....
> end subroutine i_want_my_bigloo_compiler_back
> =3D=3D
>
> will give me a segmentation fault after executing a.out.
>
> However:
>
> =3D=3D
> integer :: buff1=3D100,buff2=3D500
>
> contains
>
> subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
>
> real*8, dimension(100,100,5000) :: ger
> real*8, dimension(buff1,buff2) :: ger2
> ....
> =3D=3D
>
> works.
>
> ifort -convert big_endian unhappy.f90
>
> Thanks
sorry it should read:
=3D=3D
program unhappy
integer :: buff1=3D100,buff2=3D500
=2E..
contains
subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
integer, intent(in) :: buff1,buff2
real*8, dimension(buff1,buff1,buff2) :: ger
real*8, dimension(buff1,buff2) :: ger2
=2E...
end subroutine i_want_my_bigloo_compiler_back
=3D=3D
will give me a segmentation fault after executing a.out.
However:
=3D=3D
integer :: buff1=3D100,buff2=3D500
contains
subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
integer, intent(in) :: buff1,buff2
real*8, dimension(100,100,5000) :: ger
real*8, dimension(buff1,buff2) :: ger2
=2E...
=3D=3D
| |
| Wade Ward 2007-11-26, 8:11 am |
|
"Förster vom Silberwald" <chain_lube@hotmail.com> wrote in message
news:8def7b9a-1168-4c04-bf8d-83ee3c99543f@g30g2000hsb.googlegroups.com...
On Nov 26, 9:21 am, "Förster vom Silberwald" <chain_l...@hotmail.com>
wrote:
> ==
> program unhappy
>
> integer :: buff1=100,bugg2=500
>
> ...
>
> contains
>
> subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
>
> real*8, dimension(buff1,buff1,buff2) :: ger
> real*8, dimension(buff1,buff2) :: ger2
> ....
> end subroutine i_want_my_bigloo_compiler_back
> ==
>
> will give me a segmentation fault after executing a.out.
>
> However:
>
> ==
> integer :: buff1=100,buff2=500
>
> contains
>
> subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
>
> real*8, dimension(100,100,5000) :: ger
> real*8, dimension(buff1,buff2) :: ger2
> ....
> ==
>
> works.
>
> ifort -convert big_endian unhappy.f90
>
> Thanks
sorry it should read:
==
program unhappy
integer :: buff1=100,buff2=500
....
contains
subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
integer, intent(in) :: buff1,buff2
real*8, dimension(buff1,buff1,buff2) :: ger
real*8, dimension(buff1,buff2) :: ger2
.....
end subroutine i_want_my_bigloo_compiler_back
==
will give me a segmentation fault after executing a.out.
However:
==
integer :: buff1=100,buff2=500
contains
subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
integer, intent(in) :: buff1,buff2
real*8, dimension(100,100,5000) :: ger
real*8, dimension(buff1,buff2) :: ger2
.....
==
It should read? Komisher Ausdruck.
real*8, dimension(buff1,buff2) :: ger2
Why the non-portable declaration? Would it work with silverfoerster 95?
--
wade ward
wade@zaxfuuq.net
435 -838-7760
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
| |
| Förster vom Silberwald 2007-11-26, 8:11 am |
| On Nov 26, 10:26 am, "Wade Ward" <w...@zaxfuuq.net> wrote:
> real*8, dimension(buff1,buff2) :: ger2
>
> Why the non-portable declaration? Would it work with silverfoerster 95?
Why is it non-portable? What do you mean by silverfoerster 95?
Thanks
| |
| Arjen Markus 2007-11-26, 8:11 am |
| On 26 nov, 11:38, "F=F6rster vom Silberwald" <chain_l...@hotmail.com>
wrote:
> On Nov 26, 10:26 am, "Wade Ward" <w...@zaxfuuq.net> wrote:
>
>
[color=darkred]
>
> Why is it non-portable? What do you mean by silverfoerster 95?
>
> Thanks
"real*8" is a (popular) extension to the FORTRAN 77 standard
for:
double precision
(The "8" refers to the fact that on many machine double
precision reals are implemented with 8 bytes. But that
is not guaranteed.)
Current F90/95/... practice is this:
real(kind=3Dkind(1.0d00))
(or any of a variety of means to determine the kind of
double precision reals).
Regards,
Arjen
| |
| Wade Ward 2007-11-26, 8:11 am |
|
"Arjen Markus" <arjen.markus@wldelft.nl> wrote in message
news:f2583e1d-5dd5-432d-80e4-b54b38673971@o6g2000hsd.googlegroups.com...
On 26 nov, 11:38, "Förster vom Silberwald" <chain_l...@hotmail.com>
wrote:
> On Nov 26, 10:26 am, "Wade Ward" <w...@zaxfuuq.net> wrote:
>
>
>
> Why is it non-portable? What do you mean by silverfoerster 95?
>
> Thanks
"real*8" is a (popular) extension to the FORTRAN 77 standard
for:
double precision
(The "8" refers to the fact that on many machine double
precision reals are implemented with 8 bytes. But that
is not guaranteed.)
Current F90/95/... practice is this:
real(kind=kind(1.0d00))
^^^^^^^^^^^ whoops, mpj
(or any of a variety of means to determine the kind of
double precision reals).
If you've taken precautions to portablt get yourself to dp, what do you have
to do to get to quad p?
Danke im voraus,
--
wade ward
wade@zaxfuuq.net
435 -838-7760
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
| |
| Förster vom Silberwald 2007-11-26, 8:11 am |
| On Nov 26, 11:20 am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> On 26 nov, 11:38, "F=F6rster vom Silberwald" <chain_l...@hotmail.com>
> wrote:
>
>
>
5?[color=darkred]
>
>
>
> "real*8" is a (popular) extension to the FORTRAN 77 standard
> for:
>
> double precision
>
> (The "8" refers to the fact that on many machine double
> precision reals are implemented with 8 bytes. But that
> is not guaranteed.)
>
> Current F90/95/... practice is this:
>
> real(kind=3Dkind(1.0d00))
>
> (or any of a variety of means to determine the kind of
> double precision reals).
>
> Regards,
>
> Arjen
hello: thanks for the answer. I saw that real*8 in some codes
colleagues put forward to me (okay, they are using f90 but their code
as far as I can tell is fortran 77).
But anyway: why isn't it possible to pass the buff1 and buff2 variable
and the compiler will allocate memory. I haven't checked it yet but
are you saying that I will go away without any segmentation fault if
using double precision instead of real*8?
I am not saying that I do'nt won't to improve my Fortran. But it is
this: I do not have much time right now to go through a Fortran 90
book because they want to see some results here. We don't even have
any Fortran 90 books here and I had to refresh my Fortran 90 knowledge
by means of the internet. I had some Fortran 90 lectures 10 years ago
(funny enough: I was alone when I took the Fortran 90 classes and the
lecturer were reall happy because nowadays nobody takes any Fortran
classes at all).
It is so hard for me to program in Fortran 90 because I am used to
Scheme (and the very stable and excellent Bigloo compiler) and I miss
so much: lists, map, lamba, etc.
Okay: the one good thing about Fortran 90: a(:,:) =3D b(1,:)
thanks
| |
| Förster vom Silberwald 2007-11-26, 8:11 am |
| On Nov 26, 11:43 am, "F=F6rster vom Silberwald" <chain_l...@hotmail.com>
wrote:
> Okay: the one good thing about Fortran 90: a(:,:) =3D b(1,:)
I meant this thing of array slicing: a(:,1,1) =3D b(:) etc.
| |
| Arjen Markus 2007-11-26, 8:11 am |
| On 26 nov, 12:43, "F=F6rster vom Silberwald" <chain_l...@hotmail.com>
wrote:
> On Nov 26, 11:20 am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>
>
>
>
>
>
>
>
95?[color=darkred]
>
>
>
>
>
>
>
>
>
>
>
> hello: thanks for the answer. I saw that real*8 in some codes
> colleagues put forward to me (okay, they are using f90 but their code
> as far as I can tell is fortran 77).
>
> But anyway: why isn't it possible to pass the buff1 and buff2 variable
> and the compiler will allocate memory. I haven't checked it yet but
> are you saying that I will go away without any segmentation fault if
> using double precision instead of real*8?
>
> I am not saying that I do'nt won't to improve my Fortran. But it is
> this: I do not have much time right now to go through a Fortran 90
> book because they want to see some results here. We don't even have
> any Fortran 90 books here and I had to refresh my Fortran 90 knowledge
> by means of the internet. I had some Fortran 90 lectures 10 years ago
> (funny enough: I was alone when I took the Fortran 90 classes and the
> lecturer were reall happy because nowadays nobody takes any Fortran
> classes at all).
>
> It is so hard for me to program in Fortran 90 because I am used to
> Scheme (and the very stable and excellent Bigloo compiler) and I miss
> so much: lists, map, lamba, etc.
>
> Okay: the one good thing about Fortran 90: a(:,:) =3D b(1,:)
>
> thanks- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -
Well, lists can be done via arrays and a bit of care:
passing arrays to subroutines/functions gives you much
freedom.
map: Fortran does this via array expressions
lambda: well, array expressions again ;)
etc.: All I can say is that you need to think in terms of
arrays, rather than lists.
Regards,
Arjen
| |
| Förster vom Silberwald 2007-11-26, 8:11 am |
| On Nov 26, 12:31 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> On 26 nov, 12:43, "F=F6rster vom Silberwald" <chain_l...@hotmail.com>
> wrote:
>
>
>
>
>
>
>
er 95?[color=darkred]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Well, lists can be done via arrays and a bit of care:
> passing arrays to subroutines/functions gives you much
> freedom.
>
> map: Fortran does this via array expressions
> lambda: well, array expressions again ;)
> etc.: All I can say is that you need to think in terms of
> arrays, rather than lists.
>
> Regards,
>
> Arjen
Hello: thanks.
Is it possible to have an array with different kind of members? e.g.
#((list 1 2 3), 3, (vector 3 4))?
Or do people use a struct in this case in Fortran?
I would like to shape my programming style a bit because I am not at a
point where I pass 10 or more different parameters to subfunctions. I
guess it would be easier to pass just one structure?
I am so much used to this kind of programming (especially when you do
a lot of experimenting): I start out with a function in Scheme and put
some return things into a list (e.g. vectors, and numbers etc.). 1
hour later I can extend the return list by some other stuff without
any hassle. In Fortran 90 I always have to declare and take care of
types and dimensions. This is going to kill me.
How would you this in Fortran: lets say you have a 3 dimensional array
but the 3rd dimension is variable in length? In Scheme I would have a
2 dimensional vector and the 3rd dimension would be a vraiable list or
variable vector?
Thanks
| |
| Arjen Markus 2007-11-26, 8:11 am |
| On 26 nov, 13:46, "F=F6rster vom Silberwald" <chain_l...@hotmail.com>
wrote:
> On Nov 26, 12:31 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>
>
>
>
>
>
>
>
>
>
>
ster 95?[color=darkred]
>
>
>
>
>
>
>
>
>
>
>
>
[color=darkred]
>
[color=darkred]
>
>
>
>
>
>
>
>
>
> Hello: thanks.
>
> Is it possible to have an array with different kind of members? e.g.
> #((list 1 2 3), 3, (vector 3 4))?
>
> Or do people use a struct in this case in Fortran?
>
> I would like to shape my programming style a bit because I am not at a
> point where I pass 10 or more different parameters to subfunctions. I
> guess it would be easier to pass just one structure?
>
> I am so much used to this kind of programming (especially when you do
> a lot of experimenting): I start out with a function in Scheme and put
> some return things into a list (e.g. vectors, and numbers etc.). 1
> hour later I can extend the return list by some other stuff without
> any hassle. In Fortran 90 I always have to declare and take care of
> types and dimensions. This is going to kill me.
>
> How would you this in Fortran: lets say you have a 3 dimensional array
> but the 3rd dimension is variable in length? In Scheme I would have a
> 2 dimensional vector and the 3rd dimension would be a vraiable list or
> variable vector?
>
> Thanks- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -
Well, arrays are collections of data of the same type only,
but nothing prevents you from using an array of derived types
where only one or two entries have a meaning. That would allow
you more flexibility (at the cost of some more programming,
but even that can be remedied!)
Fortran arrays (especially of the pointer variety) can
have any size per dimension:
p =3D> mk_3d_array( third_dim )
function mk_3d_array( dim ) result( p )
real, dimension(:,:,:), pointer :: p
allocate( p(20,20,dim) ) ! Only the 3rd dimension varies
end function
for instance.
Regards,
Arjen
| |
| Förster vom Silberwald 2007-11-26, 8:11 am |
| On Nov 26, 1:10 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> Fortran arrays (especially of the pointer variety) can
> have any size per dimension:
>
> p => mk_3d_array( third_dim )
>
> function mk_3d_array( dim ) result( p )
> real, dimension(:,:,:), pointer :: p
>
> allocate( p(20,20,dim) ) ! Only the 3rd dimension varies
>
> end function
>
> for instance.
>
> Regards,
>
> Arjen
That is interesting indeed. Thank you very much.
Btw: does one know whether that would be also possible with C
pointers? Just out of curisity cos I red a C pointer tutorial
yesterday.
Thanks
PS: However, still I am interested in my original question: why can't
I pass buffer integer variables to a subroutine so as to allocate an
array and memory? Is this due to my ifort compiler?
| |
| Gordon Sande 2007-11-26, 8:11 am |
| On 2007-11-26 07:20:35 -0400, Arjen Markus <arjen.markus@wldelft.nl> said:
> On 26 nov, 11:38, "Förster vom Silberwald" <chain_l...@hotmail.com>
> wrote:
>
>
> "real*8" is a (popular) extension to the FORTRAN 77 standard
> for:
>
> double precision
>
> (The "8" refers to the fact that on many machine double
> precision reals are implemented with 8 bytes. But that
> is not guaranteed.)
>
> Current F90/95/... practice is this:
>
> real(kind=kind(1.0d00))
>
> (or any of a variety of means to determine the kind of
> double precision reals).
>
> Regards,
>
> Arjen
It should be noted that Fortran 77, 90, 95, 2003 and future variants permit
DOUBLE PRECISION
to indicate double precision. Think of it as finger exercise or an indication
that the author has read the section of the programmer's editor on cut and
paste. If one is in an environment where there is a choice of machines with
some having 32 bit single and 64 bit double precision and others having 64
bit single and 128 bit (software emulated) double precision then the ability
to parametrically change precision is very valuable. But it also requires one
pay attention to literals. The above recipe is good for variables but is less
satisfactory for literals as the compiler will not understand it in that form.
The suitable technical form for literals can be found in the manual.
Getting  on precision of literals is a FAQ so it is not a great service
to recommend portability schemes that ignore literals. You will either have
to do things twice or have a mix of two styles of fix if you start with only
a partial solution.
| |
| Reinhold Bader 2007-11-26, 8:11 am |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Förster vom Silberwald wrote:
[snip]
> PS: However, still I am interested in my original question: why can't
> I pass buffer integer variables to a subroutine so as to allocate an
> array and memory? Is this due to my ifort compiler?
ifort puts automatics on the stack. There are two workarounds: Either
* increase your stack limit (e.g., via the "ulimit -s ..." command) in your
shell before running a.out
* use the -heap-arrays switch supported by newer ifort (9.1+) releases.
Regards
Reinhold
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFHStFfFVLhKuD7VgsRAn9EAJ43pnr2Uluw
foGB027LDBxlEekRCQCeOFy6
pQd3K8JNYAQiHnSnH6EjvMQ=
=Itq0
-----END PGP SIGNATURE-----
| |
| michael 2007-11-26, 8:11 am |
|
Maybe you meant
integer:: buff1=100, buff2=500
Funny you should call it bugg2.
Michael
In article <005013e5-ca91-4c56-a50d-20a9084b4caa@s6g2000prc.googlegroups.com>,
chain_lube@hotmail.com says...
>
>==
>program unhappy
>
>integer :: buff1=100,bugg2=500
>
>...
>
>contains
>
>subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
>
>real*8, dimension(buff1,buff1,buff2) :: ger
>real*8, dimension(buff1,buff2) :: ger2
>....
>end subroutine i_want_my_bigloo_compiler_back
>==
>
>will give me a segmentation fault after executing a.out.
>
>However:
>
>==
>integer :: buff1=100,buff2=500
>
>
>contains
>
>subroutine i_want_my_bigloo_compiler_back(buff1,buf
f2,....)
>
>real*8, dimension(100,100,5000) :: ger
>real*8, dimension(buff1,buff2) :: ger2
>....
>==
>
>works.
>
>ifort -convert big_endian unhappy.f90
>
>Thanks
| |
| Arjen Markus 2007-11-26, 7:17 pm |
| On 26 nov, 14:59, Reinhold Bader <Ba...@lrz.de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> F=F6rster vom Silberwald wrote:
>
> [snip]
>
>
> ifort puts automatics on the stack. There are two workarounds: Either
>
> * increase your stack limit (e.g., via the "ulimit -s ..." command) in you=
r
> shell before running a.out
> * use the -heap-arrays switch supported by newer ifort (9.1+) releases.
>
> Regards
> Reinhold
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with SUSE -http://enigmail.mozdev.org
>
> iD8DBQFHStFfFVLhKuD7VgsRAn9EAJ43pnr2Uluw
foGB027LDBxlEekRCQCeOFy6
> pQd3K8JNYAQiHnSnH6EjvMQ=3D
> =3DItq0
> -----END PGP SIGNATURE-----
Well, actually there is another one:
Explicitly allocate the arrays you need at the start.
BTW, Steve Lionel posted a link the other day to a series
of articles that expose some of the finer details of Fortran.
One of these concerns the use of the stack. I recommend
reading it.
Regards,
Arjen
| |
| Förster vom Silberwald 2007-11-26, 7:17 pm |
| On Nov 26, 1:53 pm, Gordon Sande <g.sa...@worldnet.att.net> wrote:
> On 2007-11-26 07:20:35 -0400, Arjen Markus <arjen.mar...@wldelft.nl> said:=
>
>
>
>
>
5?[color=darkred]
>
>
>
>
>
>
>
>
>
>
>
> It should be noted that Fortran 77, 90, 95, 2003 and future variants permi=
t
>
> DOUBLE PRECISION
>
> to indicate double precision. Think of it as finger exercise or an indicat=
ion
> that the author has read the section of the programmer's editor on cut and=
> paste. If one is in an environment where there is a choice of machines wit=
h
> some having 32 bit single and 64 bit double precision and others having 64=
> bit single and 128 bit (software emulated) double precision then the abili=
ty
> to parametrically change precision is very valuable. But it also requires =
one
> pay attention to literals. The above recipe is good for variables but is l=
ess
> satisfactory for literals as the compiler will not understand it in that f=
orm.
> The suitable technical form for literals can be found in the manual.
>
> Getting on precision of literals is a FAQ so it is not a great se=
rvice
> to recommend portability schemes that ignore literals. You will either hav=
e
> to do things twice or have a mix of two styles of fix if you start with on=
ly
> a partial solution.
Please can anyone now elaborate if "portability" is a hardware, user
system, or compiler issue?
And on which machines (or user systems, or fortran compilers for that
matter) does "8" stands/is interpreted for/as something different.
Do such kind of things as "portability and numerics" also matter with
the C language?
Thanks for clarification
| |
| Förster vom Silberwald 2007-11-26, 7:17 pm |
| On Nov 26, 2:21 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> On 26 nov, 14:59, Reinhold Bader <Ba...@lrz.de> wrote:
>
>
>
>
>
>
>
>
our[color=darkred]
>
>
>
>
> Well, actually there is another one:
>
> Explicitly allocate the arrays you need at the start.
>
> BTW, Steve Lionel posted a link the other day to a series
> of articles that expose some of the finer details of Fortran.
> One of these concerns the use of the stack. I recommend
> reading it.
>
> Regards,
>
> Arjen
Thanks for all the tips (I really appreciate it). But still I do not
get it: what is the difference between passing a buffer variable
(which actually holds the dimension!) and hard coding the dimension
into the declare statement?
Is this a compiler issue or just prohibited in Fortran 90?
Thanks
| |
| michael 2007-11-26, 7:17 pm |
| To repeat, you did not declare the variable, as you misspelled it.
Michael
In article <13e70ff2-e276-428a-8ec6-8258be941aa5@e6g2000prf.googlegroups.com>,
chain_lube@hotmail.com says...
>
>On Nov 26, 2:21 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>our
>
>
>Thanks for all the tips (I really appreciate it). But still I do not
>get it: what is the difference between passing a buffer variable
>(which actually holds the dimension!) and hard coding the dimension
>into the declare statement?
>
>Is this a compiler issue or just prohibited in Fortran 90?
>
>Thanks
| |
| Förster vom Silberwald 2007-11-26, 7:17 pm |
| On Nov 26, 2:43 pm, m...@kt.dtu.dk (michael) wrote:
> To repeat, you did not declare the variable, as you misspelled it.
ks
That is not true. I have posted a correction (see my post shortly
after I first posted)!
Still, why isn't it possible!
| |
| Gordon Sande 2007-11-26, 7:17 pm |
| On 2007-11-26 10:26:28 -0400, "Förster vom Silberwald"
<chain_lube@hotmail.com> said:
> On Nov 26, 1:53 pm, Gordon Sande <g.sa...@worldnet.att.net> wrote:
>
> 5?
> t
> ion
>
> h
>
> ty
> one
> ess
> orm.
> rvice
> e
> ly
>
>
>
> Please can anyone now elaborate if "portability" is a hardware, user
> system, or compiler issue?
>
> And on which machines (or user systems, or fortran compilers for that
> matter) does "8" stands/is interpreted for/as something different.
>
> Do such kind of things as "portability and numerics" also matter with
> the C language?
>
> Thanks for clarification
Portability is
1. sometimes hardware
2. sometimes operating system
3. often compiler language extension
You have seen the problem with indicating "double precision" as REAL*8 was
an IBM hack from the 1970s. It was an issue as there was a variety of
word sizes for scientific computation. Popular values inclided 32, 36, 48
and 60 bits. Rather, 32 was common but not always popular as the arithmetic
accurracy degraded. If you were switching between IBM 32 bit systems and Cray
60 bit systems you want double on IBM and single on Cray. Cray double was
software like much of the current quad. Lots of folks grumbled about half
precision on 32 bit systems!
The form of file names is a bother. Is it forward slash or backward slash?
Or maybe a colon to indicate another level of directory. Is it relative or
global? Directory layouts differ even on the same hardware and software.
Every vendor offered their own very useful (to them to keep you on their stuff)
extensions to solve common awkwardnesses. A common bother was the issue of
record oriented vrs byte stream file systems. Is that "binary" or "transparent"
or something else? The confusion was sorted out by the standard choosing a
sensible value which was none of the above.
Numerics can be a pain if you think that 1.0/3.0 is something that makes sense
on a binary computer. Convergence is always a touchy subject. If changing
precision makes the effects of roundoff show up more somewhere than somewhere
else then you will be chasing ghosts until you undersand your algorithm. Over
precision in intermediates can change results as can different execution order
from changing optimization strategies.
You will notice that other than the buzzwords for file types this has
nothing to do with which language you are using.
Such is the use of computers. They were supposed to make life easier!
| |
| Arjen Markus 2007-11-26, 7:17 pm |
| On 26 nov, 15:29, "F=F6rster vom Silberwald" <chain_l...@hotmail.com>
wrote:
> On Nov 26, 2:21 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>
>
>
>
>
>
>
>
>
t[color=darkred]
[color=darkred]
>
>
your[color=darkred]
..[color=darkred]
>
>
>
>
>
>
>
>
>
> Thanks for all the tips (I really appreciate it). But still I do not
> get it: what is the difference between passing a buffer variable
> (which actually holds the dimension!) and hard coding the dimension
> into the declare statement?
>
> Is this a compiler issue or just prohibited in Fortran 90?
>
> Thanks- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -
The array b in the following fragment is a so-called
automatic array:
subroutine mysub( dim )
integer :: dim
real, dimension(dim) :: b
...
end subroutine mysub
The program must allocate the memory for this array at
run-time (if dim were a number or an integer parameter
the compiler might use a static piece of memory for it,
but now the size is unknown at compile-time).
Quite often it comes directly from the stack - and
stacks often have a ridiculously small and fixed size -
but they are very fast. As Steve Lionel indicates in his
article, modern compilers create code that is smart about
this: use the stack if it seems possible, use the heap
otherwise.
Rules of thumb:
If the size is likely to be a few 100 and not more,
use automatic arrays. Otherwise use allocatable
arrays and allocate yourself.
(I have tried to measure the performance penalty this
is supposed to have in a test program, but it seems
negligeable - at least:
there is little or no evidence that it is significant.
But measuring performance is really tricky!)
The advantage of allocatable arrays: they are deallocated
automatically in Fortran 95.
Regards,
Arjen
| |
| Förster vom Silberwald 2007-11-26, 7:17 pm |
| On Nov 26, 3:18 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> The array b in the following fragment is a so-called
> automatic array:
>
> subroutine mysub( dim )
> integer :: dim
>
> real, dimension(dim) :: b
> ...
>
> end subroutine mysub
>
> The program must allocate the memory for this array at
> run-time (if dim were a number or an integer parameter
> the compiler might use a static piece of memory for it,
> but now the size is unknown at compile-time).
>
> Quite often it comes directly from the stack - and
> stacks often have a ridiculously small and fixed size -
> but they are very fast. As Steve Lionel indicates in his
> article, modern compilers create code that is smart about
> this: use the stack if it seems possible, use the heap
> otherwise.
>
> Rules of thumb:
> If the size is likely to be a few 100 and not more,
> use automatic arrays. Otherwise use allocatable
> arrays and allocate yourself.
>
> (I have tried to measure the performance penalty this
> is supposed to have in a test program, but it seems
> negligeable - at least:
> there is little or no evidence that it is significant.
> But measuring performance is really tricky!)
>
> The advantage of allocatable arrays: they are deallocated
> automatically in Fortran 95.
>
> Regards,
>
> Arjen
Thank you very much. As already written I appreciate any help.
However, this leaves me still to wonder: why isn't the compiler smart
enough to see my buff1 and buff2 variables which have been assigned an
actual value by means of the 'parameter' keyword? I mean the compiler
knows at compile time how big I want my arrays to be.
I could somehow understand that it is a problem for a compiler when
lets say I would read in the buff1 and buff2 values from a file and
the compiler wouldn't know about the dimension.
Thanks all who tried to clarify. I think I need a Fortran 90 book now.
| |
|
| Förster vom Silberwald wrote:
> On Nov 26, 3:18 pm, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
>
....
[color=darkred]
> However, this leaves me still to wonder: why isn't the compiler smart
> enough to see my buff1 and buff2 variables which have been assigned an
> actual value by means of the 'parameter' keyword? I mean the compiler
> knows at compile time how big I want my arrays to be.
Fortran compilation is not global but by program unit where unit is a
program, subroutine or function. Hence, the compiler is _NOT_ "smart
enough" because it is the characteristic of the language that it is not so.
You can share variables and/or parameters via various mechanisms to make
them visible across compiling units, but you have not done so.
--
| |
| AnotherSquid 2007-11-26, 7:17 pm |
| On Nov 26, 7:21 am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> BTW, Steve Lionel posted a link the other day to a series
> of articles that expose some of the finer details of Fortran.
> One of these concerns the use of the stack. I recommend
> reading it.
I'd like to read this, but can't find it. (Searching for "Steve
Lionel" did not help -- to many matches.) Can you give me a word or
two from the subject line?
| |
| Charles Coldwell 2007-11-26, 7:17 pm |
| "Förster vom Silberwald" <chain_lube@hotmail.com> writes:
> ==
> program unhappy
>
> integer :: buff1=100,bugg2=500
What happens if you change this to
integer, parameter :: buff1=100, buff2=500
?
(N.B. "parameter")
Chip
--
Charles M. "Chip" Coldwell
"Turn on, Log in, Tune out"
| |
| Förster vom Silberwald 2007-11-26, 7:17 pm |
| On Nov 26, 6:04 pm, Charles Coldwell <coldw...@gmail.com> wrote:
> "F=F6rster vom Silberwald" <chain_l...@hotmail.com> writes:
>
>
>
> What happens if you change this to
>
> integer, parameter :: buff1=3D100, buff2=3D500
>
> ?
>
> (N.B. "parameter")
>
> Chip
>
> --
> Charles M. "Chip" Coldwell
> "Turn on, Log in, Tune out"
same: segmentation fault.
| |
| Förster vom Silberwald 2007-11-26, 7:17 pm |
| On Nov 26, 6:04 pm, Charles Coldwell <coldw...@gmail.com> wrote:
> "F=F6rster vom Silberwald" <chain_l...@hotmail.com> writes:
>
>
>
> What happens if you change this to
>
> integer, parameter :: buff1=3D100, buff2=3D500
>
> ?
>
> (N.B. "parameter")
>
> Chip
>
> --
> Charles M. "Chip" Coldwell
> "Turn on, Log in, Tune out"
as ad on: the funny thing I now tried to compile it with g95. oh my
good where ifort does not complain i get so many error messages with
g95:
Fatal Error: Too many errors, aborting.
But anyway this if Fortran.
| |
| Michael Metcalf 2007-11-26, 7:17 pm |
|
"Förster vom Silberwald" <chain_lube@hotmail.com> wrote in message
news:fa0532df-622e-4d90-9599-77d01c645fbf@j20g2000hsi.googlegroups.com...
On Nov 26, 6:04 pm, Charles Coldwell <coldw...@gmail.com> wrote:
as ad on: the funny thing I now tried to compile it with g95. oh my
good where ifort does not complain i get so many error messages with
g95:
Fatal Error: Too many errors, aborting.
But anyway this if Fortran.
========================================
====
Förster,
I think you are trying to do too many things at once. The ifort
compiler accepts, by default, many (often weird) extensions to the standard.
As you've found, g95 is much less forgiving. If you can persuade your
program to work with ifort, perhaps with smaller arrays, in a test version,
you could then post your code here and receive some helpful comments about
it. Thrashing around and working without any form of documentation will, at
best, be but a stochastic form of progress.
An instant form of Fortran 95 documentation, without older, redundant
features, can be seen at
http://en.wikipedia.org/wiki/Fortran_language_features.
Hope that helps,
Mike Metcalf
| |
| Förster vom Silberwald 2007-11-26, 7:17 pm |
| On Nov 26, 6:44 pm, "Michael Metcalf" <michaelmetc...@compuserve.com>
wrote:
> "F=F6rster vom Silberwald" <chain_l...@hotmail.com> wrote in messagenews:f=
a0532df-622e-4d90-9599-77d01c645fbf@j20g2000hsi.googlegroups.com...
> On Nov 26, 6:04 pm, Charles Coldwell <coldw...@gmail.com> wrote:
>
> as ad on: the funny thing I now tried to compile it with g95. oh my
> good where ifort does not complain i get so many error messages with
> g95:
> Fatal Error: Too many errors, aborting.
>
> But anyway this if Fortran.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
3D=3D=3D=3D=3D=3D=3D
> F=F6rster,
> I think you are trying to do too many things at once. The ifort
> compiler accepts, by default, many (often weird) extensions to the standar=
d.
> As you've found, g95 is much less forgiving. If you can persuade your
> program to work with ifort, perhaps with smaller arrays, in a test version=
,
> you could then post your code here and receive some helpful comments about=
> it. Thrashing around and working without any form of documentation will, a=
t
> best, be but a stochastic form of progress.
>
> An instant form of Fortran 95 documentation, without older, redundant
> features, can be seen athttp://en.wikipedia.org/wiki/Fortran_language_feat=
ures.
>
> Hope that helps,
>
> Mike Metcalf
Hello: Thanks for all the help. I cannot post the program because it
is more than 1500 lines long in the meantime. And I am bound to ifort
because I need this -convert big_endian (I am not sure if g95 has such
a feature; but that is not the reason why it complaint) because I use
some code from a third party which relies on a specific binary file
format from the output of the model.
Meantime problem is solved: I hard code and initialise the array by a
huge dummy buffer. that is okay.
Maybe there will come time where I will find some spare time to delve
deeper into Fortran but for now I will just use it though that means
that I have to fit myself to Fortran and not the other way round (as
it was the case with Scheme). Yes I knwo bad idea but what will you do
if don't like to program in Fortran.
Really hat off to all the people who are productive in Fortran (I do
not mean just solving some algebra problems with stupid arrays but all
the problems which require logic, testing, experimenting, data
structures, etc).
Thanks (some postings were interesting especiall the contribution that
one can create array where the third dimension is variable)
| |
| John Harper 2007-11-26, 7:17 pm |
| In article <1196076343_6793@sp12lax.superfeed.net>,
Wade Ward <wade@zaxfuuq.net> wrote:
>
>real(kind=kind(1.0d00))
>^^^^^^^^^^^ whoops, mpj
Unwhoops. That's perfectly legal. Two different meanings of "kind" are
in use there. This sort of thing is not unusual. After all, "*" has
seven different meanings in these two statements:
character c(*)*(*)
write(*,*) 'a*b =',a*b
>If you've taken precautions to portablt get yourself to dp, what do
>you have to do to get to quad p?
One way to ask for precision at least twice that of double:
INTEGER,PARAMETER::dp=kind(1d0),qp=selec
ted_real_kind(precision(1d0)*2)
REAL(dp):: xdouble
REAL(qp):: xquad
But in some systems it's not available, so qp < 0, so REAL(qp) fails.
I use compilers both with and without quad precision, and I like to
have a high precision hp that's qp if available, dp if not. The merge
intrinsic could be used to get it in f2003, but not in f95 when
defining a parameter. One well-known method that does work in f95 is
INTEGER,PARAMETER:: hp = qp*(1+sign(1,qp))/2 + dp*(1-sign(1,qp))/2
Some systems don't have quad precision as defined above but do have a
precision higher than dp. On those, you could change *2 to +2, or even
define some more INTEGER,PARAMETERs to deal with every possible case.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| John Harper 2007-11-26, 7:17 pm |
| In article <0acefd87-d218-41ef-9df1-dce9abf6e4e0@i29g2000prf.googlegroups.com>,
Förster vom Silberwald <chain_lube@hotmail.com> wrote:
>Please can anyone now elaborate if "portability" is a hardware, user
>system, or compiler issue?
All of those are possible.
>And on which machines (or user systems, or fortran compilers for that
>matter) does "8" stands/is interpreted for/as something different.
With our NAG f95 compiler, real*8 gives a compile-time error, and double
precision is real*2, unless you use the -kind=byte compile-time option.
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
| |
| Richard Maine 2007-11-26, 10:12 pm |
| Arjen Markus <arjen.markus@wldelft.nl> wrote:
> Current F90/95/... practice is this:
>
> real(kind=kind(1.0d00))
I doubt it. While it is legal, I do not often see that particular
construct, and I do not advise it, so I would not call it "current
practice".
I'd have gone along with something like
integer, parameter :: dp = kind(1.0d0)
real(dp) :: whatever
or, as you say, any number of other ways to get an appropriate kind
value. The distinction I'm making is that the kind value is put in a
parameter instead of generated directly in the REAL statement.
While you might consider that "of course, that's what you meant, but you
were just using shorthand", be aware that it doesn't come over this way
when you are first explaining this stuff to someone who hasn't seen it
before. It looks like a suggestion to really put that while expression
in every REAL statement....
which I might add is a quite bad idea in my opinion. It pretty much
destroys all the benefits of using a kind parameter. You can't readily
change it on a program-wide basis. If one is going to do that, one might
as well just declare things as double precision. That is still standard,
and while I don't particularly like it, all the reasons that I don't
like it are pretty much equally there with the long-winded form above.
That form is, after all, nothing but a long-winded, roundabout way to
declare exactly the same thing. I regard double precision as the least
of those evils. At least it is simple and obvious.
Now if you separate out the kind value in a named constant, that is a
whole different matter. To me, that is one of the most useful parts of
the kind system. If one leaves that part out of the explanation, it
might seem like it simplifies the explanation, but it also makes it all
seem sort of pointless.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
| |
| glen herrmannsfeldt 2007-11-27, 4:29 am |
| John Harper wrote:
(snip)
> But in some systems it's not available, so qp < 0, so REAL(qp) fails.
> I use compilers both with and without quad precision, and I like to
> have a high precision hp that's qp if available, dp if not. The merge
> intrinsic could be used to get it in f2003, but not in f95 when
> defining a parameter. One well-known method that does work in f95 is
> INTEGER,PARAMETER:: hp = qp*(1+sign(1,qp))/2 + dp*(1-sign(1,qp))/2
there should be a simpler one that that..
INTEGER,PARAMETER:: hp = dp+(qp-dp)*(1+sign(1,qp))/2
If non-negative qp were always greater than dp:
INTEGER,PARAMETER:: hp = dp+dim(qp,dp)
-- glen
| |
| Victor Eijkhout 2008-01-15, 7:16 pm |
| Wade Ward <wade@zaxfuuq.net> wrote:
> "real*8" is a (popular) extension to the FORTRAN 77 standard
> for:
>
> double precision
>
> (The "8" refers to the fact that on many machine double
> precision reals are implemented with 8 bytes. But that
> is not guaranteed.)
>
> Current F90/95/... practice is this:
>
> real(kind=kind(1.0d00))
> ^^^^^^^^^^^ whoops, mpj
>
> (or any of a variety of means to determine the kind of
> double precision reals).
How do you portably determine the type of real if you're interfacing to
a C program that dictates the lenght of a real?
Victor.
--
Victor Eijkhout -- eijkhout at tacc utexas edu
| |
|
|
|
|
|