Avoid the repeat factor in namelist with arrays

[Hash]

Dear all,

Using gfortran 4.7.1, I'm writing an output namelist which contains an array.

When the elements of the array are identical, there is repeat factor "*" such like :

&OUTPUT_PARAM
K= 2*4.5 ,
/

Is there a way to tell (g)fortran to do not such repeat factor, but instead to write all the elements even if they are identical ?

Such like :

&OUTPUT_PARAM
K= 4.5, 4.5,
/

I do not want such repeat factor, because this output file is parsed by an other program not written in fortran, and thus does not know how to deal with this "*".

Best regards,

[dpb]

On 11/4/2012 8:07 AM, Hash wrote:
> Dear all,
>
> Using gfortran 4.7.1, I'm writing an output namelist which contains an array.
>
> When the elements of the array are identical, there is repeat factor "*" such like :
>
> &OUTPUT_PARAM
> K= 2*4.5 ,
> /
>

> Is there a way to tell (g)fortran to do not such repeat factor,...

Doubt it; that's the Standard form for NAMELIST output (in a form to be
parsed by NAMELIST input).

If you want a specific format, use a specific FORMAT statement.

--

[Gordon Sande]

When you use any of the convenience output forms you loose control over the
details of the formatting. They are often quite good but now and then they
are not exactly what you want as you have just found out.

There is nothing that prevents you from using a format statement to produce the
same characters that would have been produced by a NAMELIST write. Then
you have
complete control over the formatting. It is just less convenient. NAMELIST is a
form of formatted output so can be mixed with explicitly formatted output.

An alternate way is to develop a specialized text processing application,
like a small awk script, which expands the repeat counts. Again, not so
convenient.

[glen herrmannsfeldt]

Hash <julien.h...@gmail.com> wrote:

> Using gfortran 4.7.1, I'm writing an output namelist which contains an array.

> When the elements of the array are identical, there is repeat factor "*" such like :

> &OUTPUT_PARAM
> K= 2*4.5 ,
> /

> Is there a way to tell (g)fortran to do not such repeat factor,
> but instead to write all the elements even if they are identical?

Easiest is to use list-directed with the appropriate constants,
possibly using non-advancing I/O.

print *," &OUTPUT_PARAM"
print *," K="
do I=1,N
print *, X(I),","
enddo
print *,"/"


with non-advancing I/O it is not so hard to get three or four
on a line. Sometimes more readable by people.

-- glen

[Robin Vowels]

On Nov 5, 3:54 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

Each value comes out on a separate line, which is not helpful.
The array can be printed with just
print *, (x(i), ',', i = 1, n)
and it doesn't need non-advancing output to do it.

BTW, the equivalent in PL/I doesn't abbreviate output,
nor does it use the arcane syntax of NAMELIST.
For PL/I, one types:

put data (x);

[robert....@oracle.com]

On Sunday, November 4, 2012 6:07:51 AM UTC-8, Hash wrote:

>
> I do not want such repeat factor, because this output file is parsed by an other program not written in fortran, and thus does not know how to deal with this "*".

Open source is your friend. The change
you want should be trivial.

Bob Corbett

[glen herrmannsfeldt]

robert....@oracle.com wrote:
> On Sunday, November 4, 2012 6:07:51 AM UTC-8, Hash wrote:

>> I do not want such repeat factor, because this output file is
>> parsed by an other program not written in fortran, and thus
>> does not know how to deal with this "*".

(snip)

> Open source is your friend. The change you want should be trivial.

That's a good way. When you don't like a language feature, change it.

-- glen

[Robin Vowels]

If the program is not in Fortran, it won't know the
special format of NAMELIST output anyway.
If someone has coded the non-Fortran program to read
this output, it will be trivial to modify it to deal with
an asterisk !

[Rafik Zurob]

"glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in message
news:k77uiv$a5h$2...@speranza.aioe.org...

It's not changing a language feature. The standard gives the implementation
the choice of using a repeat specifier, but it's not required. The
implementation is required to support both ways on input, so either way is
fine.

10.11.4.3 Namelist output records
If two or more successive values for the same namelist group item in an
output record produced have identical values, the processor has the option
of producing a repeated constant of the form r*c instead of the sequence of
identical values.

Regards

Rafik

[Hash]

Dear all,

> It's not changing a language feature. The standard gives the implementation
>
> the choice of using a repeat specifier, but it's not required. The
>
> implementation is required to support both ways on input, so either way is
>
> fine.
>
>
>
> 10.11.4.3 Namelist output records
>
> If two or more successive values for the same namelist group item in an
>
> output record produced have identical values, the processor has the option
>
> of producing a repeated constant of the form r*c instead of the sequence of
>
> identical values.

I indeed does not mean that the langage has to changed to fullfill my needs ; I'm just asking is a way existed to disable this repeat factor thing.

Thank you for your answers.

Best regards.

[dpb]

On 11/8/2012 3:07 PM, Hash wrote:
...
...[earlier attribution(s) previously snipped]...

>> 10.11.4.3 Namelist output records
>> If two or more successive values for the same namelist group item in an
>> output record produced have identical values, the processor has the option
>> of producing a repeated constant of the form r*c instead of the sequence of
>> identical values.

> I indeed does not mean that the langage has to changed to fullfill
> my needs ; I'm just asking is a way existed to disable this repeat factor
>thing.

...

The key words in the above on that point are "processor has the option"
which means it's not required to be controllable by the user; whichever
the processor does is conformant (I think you know that; just confirming
the statement in all likelihood).

It means only if there's a compiler switch can you cause the code output
to be affected from whatever is the particular compiler's default set of
rules and I'd be surprised if that particular small feature ever reached
the level that it has ever been included by a vendor.

--

[glen herrmannsfeldt]

dpb <no...@non.net> wrote:

(snip, regarding NAMELIST output, someone wrote)

>> I indeed does not mean that the langage has to changed to fullfill
>> my needs ; I'm just asking is a way existed to disable this repeat factor
>>thing.
> ...

> The key words in the above on that point are "processor has the option"
> which means it's not required to be controllable by the user; whichever
> the processor does is conformant (I think you know that; just confirming
> the statement in all likelihood).

And, as someone previously noted, in the case of open source
compilers it can be done by changing the compiler. (Or library
routine, if that is where it is.)

> It means only if there's a compiler switch can you cause the code output
> to be affected from whatever is the particular compiler's default set of
> rules and I'd be surprised if that particular small feature ever reached
> the level that it has ever been included by a vendor.

But again, in the case of open source, you can add the switch, and
modify the compiler (and I presume library routine) to use that switch.

-- glen

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> But again, in the case of open source, you can add the switch, and
> modify the compiler (and I presume library routine) to use that switch.

Of course in this particular case, that's only multiple orders of
magnitude more work than just fixing the code to depend only on what is
specified by the standard.

Let's see. Start by learning another language (the compilers aren't
written in Fortran). Then learn how the compiler innards work enough to
figure out the modifications. Finally build and maintain your customized
version of the compiler, distributing it along with your code to anyone
who needs to use your code. Yup. That sounds like a good plan. :-(

Just because you *CAN* do things that way doesn't mean it is even
remotely a good idea. Though I suppose maybe we are off in some abstract
discussion of an imaginary world instead of giving practical advice.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

>> But again, in the case of open source, you can add the switch, and
>> modify the compiler (and I presume library routine) to use that switch.

> Of course in this particular case, that's only multiple orders of
> magnitude more work than just fixing the code to depend only on what is
> specified by the standard.

Well, I wasn't going to say more about that one, but that was a
follow-up to someone else.

Yes, if you only want one it is easiest just to write it out
using ordinary Fortran I/O statements.

> Let's see. Start by learning another language (the compilers aren't
> written in Fortran). Then learn how the compiler innards work enough to
> figure out the modifications. Finally build and maintain your customized
> version of the compiler, distributing it along with your code to anyone
> who needs to use your code. Yup. That sounds like a good plan. :-(

It does help to know C. Once in a while I can figure out how to
modify a program in a language I don't know by following the
pattern of existing code.

Without the option switch, this one probably isn't hard, but getting
the option all the way from the command line to where it is needed
is most of the work.

Guessing, without looking at the code, there should be a loop that
loops for repeats. Figure out the test inside the loop and make
sure it always fails to find a repeat, should do it.

Adding it as a #define option, not so much harder.

> Just because you *CAN* do things that way doesn't mean it is even
> remotely a good idea. Though I suppose maybe we are off in some abstract
> discussion of an imaginary world instead of giving practical advice.

Yes, the latter.

But impractical for some might not be for others.

Extra challenge to do it without the source code.

-- glen

[robert....@oracle.com]

On Thursday, November 8, 2012 2:45:59 PM UTC-8, Richard Maine wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> > But again, in the case of open source, you can add the switch, and
> > modify the compiler (and I presume library routine) to use that switch.
>
> Of course in this particular case, that's only multiple orders of
> magnitude more work than just fixing the code to depend only on what is
> specified by the standard.

In the specific case described by the OP, it is probably easier to
modify gfortran's run-time library than to modify the user's code.
The run-time library code almost certainly uses a test to check for
duplicate values. Replacing that test by a false value should
produce the desired result.

> Let's see. Start by learning another language (the compilers aren't
> written in Fortran). Then learn how the compiler innards work enough to
> figure out the modifications. Finally build and maintain your customized
> version of the compiler, distributing it along with your code to anyone
> who needs to use your code. Yup. That sounds like a good plan. :-(

The other language in question is C. I did assume that a Fortran
programmer is also likely to know C. The code that needs to be changed
should be in the run-time library, not the compiler. The run-time
library code should be much easier to understand than the compiler.

> Just because you *CAN* do things that way doesn't mean it is even
> remotely a good idea. Though I suppose maybe we are off in some abstract
> discussion of an imaginary world instead of giving practical advice.

Whether my advice is practical or not depends on the OP's circumstances.
If he wants the output in a given form for his own use, the approach I
suggested should be fine. If he intends to distribute his code for use
on a variety of platforms, he should probably do something else. Some
problems do not require general solutions.

Bob Corbett

[glen herrmannsfeldt]

robert....@oracle.com wrote:
> On Thursday, November 8, 2012 2:45:59 PM UTC-8, Richard Maine wrote:

(snip)

>> Of course in this particular case, that's only multiple orders of
>> magnitude more work than just fixing the code to depend only on what is
>> specified by the standard.

> In the specific case described by the OP, it is probably easier to
> modify gfortran's run-time library than to modify the user's code.
> The run-time library code almost certainly uses a test to check for
> duplicate values. Replacing that test by a false value should
> produce the desired result.

My first time looking at any code related to gfortran. Yes it is
in a library routine. Here is the actual if:


/* Check for repeat counts of intrinsic types. */

if ((elem_ctr < (nelem - 1)) &&
(obj->type != BT_DERIVED) &&
!memcmp (p, (void*)(p + obj_size ), obj_size ))
{
rep_ctr++;
}

So, yes, if you replace that with

if(0) {}

the following else will be executed, printing elements one at a time.

It didn't take long to find, and I didn't need to know
much C to find it.

Now, recompiling might take a little longer.

Then all one should need to do is link with this one before linking
with libgfortran.o (or .so or ..).

The next most complicated thing I could think of would be to
do a test with getenv() to check for an environment variable.
I probably wouldn't try to check that in to the development tree,
though.

-- glen

[Tobias Burnus]

Richard Maine wrot:

> glen herrmannsfeldt<g...@ugcs.caltech.edu> wrote:
>
>> >But again, in the case of open source, you can add the switch, and
>> >modify the compiler (and I presume library routine) to use that switch.

> Of course in this particular case, that's only multiple orders of
> magnitude more work than just fixing the code to depend only on what is
> specified by the standard.

Well, the latter is much work work if one wants to accept all valid
namelists. Especially with derived types and arrays (DT components with
arrays and array components), it can get extremely complex and one
variant or another will break compilers. Without derived types, it is
simpler, however, array sections with strides are also not that simple.

Fortunately, the output of a compiler ["write(nml=..."] is usually
simpler. Whether modifying the library or the program which reads the
output is simpler or makes more sense, I cannot judge. Changing the
library is probably simpler, but reduces the portability and requires
that one manually compiles the compiler (or at least the run-time
library). I probably would replace the namelist output by a manual
output, add a utility program which changes the output or modify the
code which reads the line.

Tobias

[dpb]

On 11/9/2012 3:15 AM, Tobias Burnus wrote:
...

> Fortunately, the output of a compiler ["write(nml=..."] is usually
> simpler. Whether modifying the library or the program which reads the
> output is simpler or makes more sense, I cannot judge. Changing the
> library is probably simpler, but reduces the portability and requires
> that one manually compiles the compiler (or at least the run-time
> library). I probably would replace the namelist output by a manual
> output, add a utility program which changes the output or modify the
> code which reads the line.

If'en can modify the reading code I'd investigate using C interop and
use a Fortran routine to read the namelist data rather than write a
parser from scratch...

--

[Richard Maine]

Why all the talk by multiple people about writing a parser? Does
everyone really want to look for the most complicated approach possible?
The OP was talking about the program that *WRITES* the file. Changing
something like that to use a write other than namelist is nowhere near
the complexity of writing something to parse namelist input.

[dpb]

On 11/9/2012 12:59 PM, Richard Maine wrote:
...

> Why all the talk by multiple people about writing a parser? Does
> everyone really want to look for the most complicated approach possible?
> The OP was talking about the program that *WRITES* the file. Changing
> something like that to use a write other than namelist is nowhere near
> the complexity of writing something to parse namelist input.

Agreed (but it's been a while in the thread)--I _think_ I told OP to use
a standard FORMAT statement in about the first response in the thread.

I was simply commenting that there's some advantages if arrays are
larger to have the repeated values not duplicated and so could have cake
and eat it too--and it shouldn't take much effort to tie in a Fortran
routine to the other program if can modify it at all.

But, yes, the original objective as outlined by the OP is most easily
solved simply by writing the data in the format desired/required by the
other program. Just that the alternative might be a little more elegant
in the end albeit w/ some effort. (I kinda' like doing those sorta'
"neaten it up" things meself but that's just me--it gives a little
satisfaction that it does something just a little beyond plain vanilla).

$0.02, ymmv, etc., etc., etc., ..., of course

--

[Dick Hendrickson]

On 11/9/12 3:30 PM, dpb wrote:
> On 11/9/2012 12:59 PM, Richard Maine wrote:
> ...
>
>> Why all the talk by multiple people about writing a parser? Does
>> everyone really want to look for the most complicated approach possible?
>> The OP was talking about the program that *WRITES* the file. Changing
>> something like that to use a write other than namelist is nowhere near
>> the complexity of writing something to parse namelist input.
>
> Agreed (but it's been a while in the thread)--I _think_ I told OP to use
> a standard FORMAT statement in about the first response in the thread.
>
> I was simply commenting that there's some advantages if arrays are
> larger to have the repeated values not duplicated and so could have cake
> and eat it too--and it shouldn't take much effort to tie in a Fortran
> routine to the other program if can modify it at all.

Since it's late on Friday, there's an even easier portable solution.
Write a DO loop that goes through the array, looks for duplicates, and
toggles the low order bit on the second of the duplicate pair. ;)

Dick Hendrickson

[Steven G. Kargl]

On Fri, 09 Nov 2012 15:53:42 -0600, Dick Hendrickson wrote:

> On 11/9/12 3:30 PM, dpb wrote:
>> On 11/9/2012 12:59 PM, Richard Maine wrote:
>> ...
>>
>>> Why all the talk by multiple people about writing a parser? Does
>>> everyone really want to look for the most complicated approach possible?
>>> The OP was talking about the program that *WRITES* the file. Changing
>>> something like that to use a write other than namelist is nowhere near
>>> the complexity of writing something to parse namelist input.
>>
>> Agreed (but it's been a while in the thread)--I _think_ I told OP to use
>> a standard FORMAT statement in about the first response in the thread.
>>
>> I was simply commenting that there's some advantages if arrays are
>> larger to have the repeated values not duplicated and so could have cake
>> and eat it too--and it shouldn't take much effort to tie in a Fortran
>> routine to the other program if can modify it at all.
>
> Since it's late on Friday, there's an even easier portable solution.
> Write a DO loop that goes through the array, looks for duplicates, and
> toggles the low order bit on the second of the duplicate pair. ;)
>
> Dick Hendrickson

Let's assume that we are talking about an integer type that is 4 bit.
Let's futher assume at the array as 3 elements with binary forms
of a(3) =[z'1111', z'1111', z'1110'] . Your algorithm won't work.
Starting with a(1), your first iteration gives [z'1111', z'1110', z'1110'].
Now, move to a(2) and since you've already distinguished a(1) from
all other values you need only compare to a(3). This gives
[z'1111', z'1110', z'1111']. Now, move to a(3), it's the last element
so stop the algorithm.

Ok, so there's a flaw in the above and I need to compare each element
to all others and flip bits. Let's start over with [z'1111', z'1111', z'1110']
and always do the comparison.

step 1: result after a(1) comparisons --> [z'1111', z'1110', z'1110']
step 2: result after a(2) comparisons --> [z'1111', z'1110', z'1111']
step 3: result after a(3) comparisons --> [z'1110', z'1110', z'1111']
step 4: goto to step 1?

--
steve

[Dick Hendrickson]

It's possible we're overthinking this, I did end with a smiley!

But, in my defense. My "algorithm" guarantees that no two successive
entries in the array have the same value (whenever it finds a duplicate
pair it changes the second one of them. (I could have stated it more
clearer, but I was thinking it more clearer ;) ) There's no problem if
A(1) and A(3) have the same value, NAMELIST won't use a repeat factor
for them.

I think the original problem was with floating point values and in that
case toggling the low order bit won't make any practical difference.
Toggling is tolerable for large integers, probably OK for character
strings and not very good at all for LOGICAL (at least on systems that
only use the low order bit for truth). For me, that's better than
learning C. ;) ;) ;)

Dick Hendrickson