Prev: hollywood hot scenes of hollywood
Next: Fortran compiler suitable for Apple AND Windows?
From: Gordon Sande on 8 Mar 2010 08:48
On 2010-03-07 22:00:44 -0400, monir <monirg(a)mondenet.com> said:

> On Mar 7, 6:44�pm, Terence <tbwri...(a)cantv.net> wrote:
>> On Mar 7, 5:33�pm, monir <mon...(a)mondenet.com> wrote:
>>
>
> 1) Couple of points:
> First: I failed to mention in the OP that array X(10,20) is a local
> variable
> Second: Item 1 of the OP should read:
> " ... and intentionally only a few nonzero elements are assigned in
> the subprogram to generate a sparse matrix."

Whne you get past the current programming foibles one would remark
that sparse techniques are related to not even representing the zeros.
Typically the data structures become more elaborate and only make sense
when the density of nonzeros is small, certainly less than 10% and often
much less than 1%. But it makes no sense to try sparse techniques if you
can not make the dense version work, as seems to be the current state of
play.

> I hope the above clarifications would answer many of your concerns.
>
> 2) Back to my question, and based on your collective replies, it is
> reasonable to conclude:
> a) do not rely on the compiler to set the initial values of the real
> variables to zero
>
> b) the preferred remedy in my case is to use the (F90) array
> assignment:
> ...Real X(10,20)
> ...X = 0.0
> or
> ...Real :: X(10,20) = 0.0

These are very diferent! First is an assignement and happens every time.
Second is an alternate (clean , no fuss, modern) way of expressing what
the data statement does. Namely, initialization exactly once before execution.

> c) in situations where a DATA statement is appropriate for zero
> initialization, X is a local variable, and m & n are parameter
> constants, one may use:
> ...Real X(m,n)
> ...Integer, parameter :: mn = m*n
> ...Data X /mn*0.0/
>
> d) if X, m, n are dummy arguments, then one can't use Data statement,
> but maybe:
> ...Real :: X(m,n) = 0.0

No. Same reason as with data. This is just a clean and fuss free representation
of what data does.

> e) if X is a local variable and m & n are dummy arguments, then
> obviously one can't even declare:
> ...Real X(m,n)

Actually you can. Look up automatic arrays. Beware that there is no automatic
keyword or declaration attribute.

> Thank you ALL; James, Glen, Robin, Gordon, Richard, Terence for your
> insights and helpful comments.
>
> Regards.
> Monir


From: Gordon Sande on 8 Mar 2010 08:48
On 2010-03-07 22:20:30 -0400, "robin" <robin_v(a)bigpond.com> said:

> "monir" <monirg(a)mondenet.com> wrote in message
> news:d2e296f5-92c8-4f23-b6cd-6b574d6d254c(a)f8g2000yqn.googlegroups.com...
> On Mar 7, 6:44 pm, Terence <tbwri...(a)cantv.net> wrote:
>> On Mar 7, 5:33 pm, monir <mon...(a)mondenet.com> wrote:
>
>> 1) Couple of points:
>> First: I failed to mention in the OP that array X(10,20) is a local
>> variable
>> Second: Item 1 of the OP should read:
>> " ... and intentionally only a few nonzero elements are assigned in
>> the subprogram to generate a sparse matrix."
>
> You haven't generated anything at all until you set all the
> remaining values to zero.
> Only then will you have a sparse matrix.

If he had some other way of avoiding the zero (undefined here!) values it
would be a plausible sparse matrix. Not anything that would be recommended
but still somthing that only stores and uses the nonzeros. As presetnted it
sounds more like confused programming full of errors.

>> 2) Back to my question, and based on your collective replies, it is
>> reasonable to conclude:
>
>> a) do not rely on the compiler to set the initial values of the real
>> variables to zero
>
> I think that all the responders have answered this unequivocally.
> So why have you ignored that advice?
> and have come back with the same question?
>
> And it's not just REAL variables.
> It applies to ALL variables, including INTEGER, COMPLEX, etc.
>
>> b) the preferred remedy in my case is to use the (F90) array
>> assignment:
>> ...Real X(10,20)
>> ...X = 0.0
>> or
>> ...Real :: X(10,20) = 0.0
>
>> c) in situations where a DATA statement is appropriate for zero
>> initialization, X is a local variable, and m & n are parameter
>> constants, one may use:
>> ...Real X(m,n)
>> ...Integer, parameter :: mn = m*n
>> ...Data X /mn*0.0/
>
> Best to avoid a DATA statement for such a trivial task.
>
>> d) if X, m, n are dummy arguments, then one can't use Data statement,
>> but maybe:
>> ...Real :: X(m,n) = 0.0
>
> That's right.
>
>> e) if X is a local variable and m & n are dummy arguments, then
>> obviously one can't even declare:
>> ...Real X(m,n)
>
> Yes you can.


From: Ron Shepard on 8 Mar 2010 10:18
In article <2010030809481516807-gsande(a)worldnetattnet>,
Gordon Sande <g.sande(a)worldnet.att.net> wrote:

> > b) the preferred remedy in my case is to use the (F90) array
> > assignment:
> > ...Real X(10,20)
> > ...X = 0.0
> > or
> > ...Real :: X(10,20) = 0.0
>
> These are very diferent! First is an assignement and happens every time.
> Second is an alternate (clean , no fuss, modern) way of expressing what
> the data statement does. Namely, initialization exactly once before
> execution.

Most compilers put the initialized values in static storage in the
executable file. For a large array this means that the exe file is
large, and it will take a long time to load from disk. The
executable statement will execute many thousands of times faster
than the equivalent disk i/o, and without the static storage the exe
file will be smaller and will load faster.

$.02 -Ron Shepard
From: Gordon Sande on 8 Mar 2010 10:55
On 2010-03-08 11:18:19 -0400, Ron Shepard
<ron-shepard(a)NOSPAM.comcast.net> said:

> In article <2010030809481516807-gsande(a)worldnetattnet>,
> Gordon Sande <g.sande(a)worldnet.att.net> wrote:
>
>>> b) the preferred remedy in my case is to use the (F90) array
>>> assignment:
>>> ...Real X(10,20)
>>> ...X = 0.0
>>> or
>>> ...Real :: X(10,20) = 0.0
>>
>> These are very diferent! First is an assignement and happens every time.
>> Second is an alternate (clean , no fuss, modern) way of expressing what
>> the data statement does. Namely, initialization exactly once before
>> execution.
>
> Most compilers put the initialized values in static storage in the
> executable file. For a large array this means that the exe file is
> large, and it will take a long time to load from disk. The
> executable statement will execute many thousands of times faster
> than the equivalent disk i/o, and without the static storage the exe
> file will be smaller and will load faster.
>
> $.02 -Ron Shepard

The issue of load time is both technically true and good practice. But
the question is the load time cost compared to the time to type a "return"
or "enter". The comparison in 1970 for a heavily loaded mini may not be
the same as that of multicore desktop with a 7200 RPM disk connected with
a SATA controller. One can enter into long technical discussions about the
effects of RAM caching that will confuse everyone including the discussers!

My concern is not that it is useful commentary between experts over a beer
but that is misguided and misleading for beginners to treat it as a priority
concern.



From: Richard Maine on 8 Mar 2010 11:33
Gordon Sande <g.sande(a)worldnet.att.net> wrote:

> On 2010-03-08 11:18:19 -0400, Ron Shepard
> <ron-shepard(a)NOSPAM.comcast.net> said:

> > Most compilers put the initialized values in static storage in the
> > executable file. For a large array this means that the exe file is
> > large, and it will take a long time to load from disk. The
> > executable statement will execute many thousands of times faster
> > than the equivalent disk i/o, and without the static storage the exe
> > file will be smaller and will load faster.
>
> The issue of load time is both technically true and good practice. But
> the question is the load time cost compared to the time to type a "return"
> or "enter". The comparison in 1970 for a heavily loaded mini may not be
> the same as that of multicore desktop with a 7200 RPM disk connected with
> a SATA controller. One can enter into long technical discussions about the
> effects of RAM caching that will confuse everyone including the discussers!
>
> My concern is not that it is useful commentary between experts over a beer
> but that is misguided and misleading for beginners to treat it as a priority
> concern.

I dunno. I suspect it is still a real issue that can well hit even
beginners - perhaps even more so than the experienced users. I have seen
static initialization actually crash what was then a fair-sized server
machine during compilation by running it out of disk space. That was
circa mid 90's. Even when it didn't crash, there was a huge performance
hit during compilation - as in differences between several tens of
minutes versus probably about the same number of seconds. I'm not at all
convinced that all that stuff is now irrelevant. I wonder about things
like limits on exe file sizes in windows.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: hollywood hot scenes of hollywood
Next: Fortran compiler suitable for Apple AND Windows?