f



Reduce Blanks challenge

Since its obvious there is NO PL/I solution to translate my 1-line 
Count_Items challenge via a single scan thru
the input line,  and as usual Vowels will not admit it the PL/I syntax is 
lacking compared to Fortran syntax,
then we can go on to a 2nd challenge thats been running concurrently over in 
comp.lang.fortran.
Posted only for PLI'er info,  there wont be a PL/I translation.

<<<<<<<
I keep screwing up posting links

  http://home.earthlink.net/~dave_gemini/reduce.f90      benchmark code

  http://home.earthlink.net/~dave_gemini/strings.f90       string_functions
module


Since its my challenge I am narrowing the acceptable solutions in reduce.f90
as follows:

1.  the output string must contain a blank last char (if input string has 1
or more trailing blanks)
     by output of  a null char after just 1 trailing blank char is output.
2.  the solution must use array syntax, no scalar processing with do loops
3.  Fast/Legible/Brief   is a goal.

If you want to submit or resubmit a solution that meets these revisions,  be
my guest,  sometime next week
I will kick out existing solutions that dont meet above specs, leaving room
for new entries.

My current solution that meets these revised specs, uses 3 statements:

pad = char(0)      ! allow pack to use null chars to pad its output
a = Copy(line)     ! copy line to char array
outline = line(1:1)  //  Copy( PACK(a(2:), a(2:)/=' '.or.a(1:)/=' ',pad) )

>>>>>>>>>.



0
dave_frank (2243)
8/20/2005 5:51:27 PM
comp.lang.pl1 1741 articles. 0 followers. Post Follow

124 Replies
783 Views

Similar Articles

[PageSpeed] 38

| David Frank wrote:
| Since its obvious there is NO PL/I solution to translate my 1-line
| Count_Items challenge via a single scan thru
| the input line,  and as usual Vowels will not admit it the PL/I syntax is
| lacking compared to Fortran syntax,
| then we can go on to a 2nd challenge thats been running concurrently over in
| comp.lang.fortran.
----snipped----

Frank, Frank, Frank.  I didn't see YOU post a 1-line solution.  What
you did post was a number of WRONG solutions, all of them at least
four or more lines, and obsure code at that.

Also, it should be noted that your solution scanned the source line
twice, one as a character string, another in a boolean version (for
the COUNT function).   You really should learn how to count Fortran
statements.   I also noted that when your challenge was met (and
bested), you add the silly restriction that it had to be scanned only
once, a restriction that even your code doesn't do.   The goal in
programming is to find solutions to problems, if you don't like the
(better) solution, then don't come back and say, "well, I bet ya
can't do that with one hand behind your back !!". _________Gerard S. 


0
gerard46 (68)
8/20/2005 7:29:55 PM
"gerard46" <gerard46@rtt.net> wrote in message 
news:IMadnZ2dnZ1fBYDdnZ2dnQAZmt6dnZ2dRVn-yZ2dnZ0@onvoy.com...
>| David Frank wrote:
> | Since its obvious there is NO PL/I solution to translate my 1-line
> | Count_Items challenge via a single scan thru
> | the input line,  and as usual Vowels will not admit it the PL/I syntax 
> is
> | lacking compared to Fortran syntax,
> | then we can go on to a 2nd challenge thats been running concurrently 
> over in
> | comp.lang.fortran.
> ----snipped----
>
> Frank, Frank, Frank.  I didn't see YOU post a 1-line solution.  What
> you did post was a number of WRONG solutions, all of them at least
> four or more lines, and obsure code at that.
>
> Also, it should be noted that your solution scanned the source line
> twice, one as a character string, another in a boolean version (for
> the COUNT function).   You really should learn how to count Fortran
> statements.   I also noted that when your challenge was met (and
> bested), you add the silly restriction that it had to be scanned only
> once, a restriction that even your code doesn't do.   The goal in
> programming is to find solutions to problems, if you don't like the
> (better) solution, then don't come back and say, "well, I bet ya
> can't do that with one hand behind your back !!". _________Gerard S.
>
>

Gerard, Gerard, Gerard.
You didnt come up with a Count_Items PL/I solution whereas:
my 1 line solution that scans line ONCE can be viewed at:

    http://earthlink.net/~dave_gemini/strings.f90


0
dave_frank (2243)
8/20/2005 8:45:07 PM
AMAZING what 6-16 oz miller lite drafts will do to one's cognizant powers on 
a saturday afternoon.

The CORRECT  link is:   http://home.earthlink.net/~dave_gemini/strings.f90 


0
dave_frank (2243)
8/20/2005 8:49:38 PM
"David Frank" <dave_frank@hotmail.com> wrote in message 
news:z4KNe.483$I93.279@newsread2.news.atl.earthlink.net...
<snip>
> 2.  the solution must use array syntax, no scalar processing with do loops

And the business
                "more powerful"
                         or
                   ANY other valid reason for including this in a programming 
spec is

         WHAT ????

-- 
Bill Klein
 wmklein <at> ix.netcom.com


0
wmklein (2605)
8/20/2005 9:12:33 PM
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message 
news:41NNe.45591$uo4.38754@fe01.news.easynews.com...
> "David Frank" <dave_frank@hotmail.com> wrote in message 
> news:z4KNe.483$I93.279@newsread2.news.atl.earthlink.net...
> <snip>
>> 2.  the solution must use array syntax, no scalar processing with do 
>> loops
>
> And the business
>                "more powerful"
>                         or
>                   ANY other valid reason for including this in a 
> programming spec is
>
>         WHAT ????
>
> -- 
> Bill Klein
> wmklein <at> ix.netcom.com
>
>

Stop asking the same old question,  the challenge put forward by the 
PL/I -FAQ is that PL/I is more powerful than Fortran,
my example brief/powerful  demo of  Fortran syntax shows that is NOT the 
case. 


0
dave_frank (2243)
8/20/2005 9:20:12 PM
There is not now, nor has there ever been a statement that PL/I is more powerful 
than Fortran.  (Stop making the same erroneous statement.)  There *is* a 
statement that Pl/I is more powerful than Fortan 90 (a very SPECIFIC "dialect" 
of Fortran).

There is, however, no definition of what is meant by "more powerful". 
Therefore, when you (and you alone) continue to pollute the PL/I newsgroup with 
challenges that make ABSOLUTELY no difference to those actually trying to use 
PL/I (or Fortran in general or Fortran 90 as mentioned in the PL/I FAQ) I will 
continue to point out the fact that you are incapable of creating a "programming 
spec" for which ANY real-world solution would be required - much less one which 
would require a programmer to decide which of two programming languages is more 
powerful.

To me, the definition of a "more powerful" programming language is one that can 
do all the "application requirements" of the other language - plus some that 
cannot be done by that other language.  This does NOT mean that the "number of 
lines" needs to be less or equal; nor does it mean that the two programming 
languages need to use the same "algorithms".  What it does mean that using the 
"native facilities" of one programming language provides capabilities not in the 
other.

For example,
  PL/I *can* handle complex numbers which COBOL cannot do (in a native fashion. 
COBOL can via callable routines).
    Similarly
  COBOL has a "native" (non-Font sensitive) Report Writer and "native" MERGE 
statement - neither of which are "native" in PL/I - but can be accomplished by 
coding, callable routines, or 3rd party products.

In general (with some exceptions as noted above), I would agree that PL/I *may* 
be viewed as more powerful than COBOL as *both* languages are "good" at (native) 
"business/data applications" while Pl/I is better at scientific and 
number-crunching applications.

Similarly, I would probably say that the "native" string handling/manipulation 
facilities of REXX, Spitbol, and even AWK *may* be viewed as more powerful 
(better tool for specific jobs) than those in either COBOL or PL/I - although 
both of those language CAN do what these languages can do .... just with a 
little more work.

Bottom-Line:
   Please stop posting non real-world "challenges" with incomplete or incorrect 
specifications in this newsgroup.
     Better yet,
          Simply stop posting to this newsgroup.

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"David Frank" <dave_frank@hotmail.com> wrote in message 
news:g8NNe.7165$RZ2.6440@newsread3.news.atl.earthlink.net...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message 
> news:41NNe.45591$uo4.38754@fe01.news.easynews.com...
>> "David Frank" <dave_frank@hotmail.com> wrote in message 
>> news:z4KNe.483$I93.279@newsread2.news.atl.earthlink.net...
>> <snip>
>>> 2.  the solution must use array syntax, no scalar processing with do loops
>>
>> And the business
>>                "more powerful"
>>                         or
>>                   ANY other valid reason for including this in a programming 
>> spec is
>>
>>         WHAT ????
>>
>> -- 
>> Bill Klein
>> wmklein <at> ix.netcom.com
>>
>>
>
> Stop asking the same old question,  the challenge put forward by the PL/I -FAQ 
> is that PL/I is more powerful than Fortran,
> my example brief/powerful  demo of  Fortran syntax shows that is NOT the case.
> 


0
wmklein (2605)
8/20/2005 9:42:23 PM
| David Frank
|> gerard46wrote:
|>| David Frank wrote:
|>| Since its obvious there is NO PL/I solution to translate my 1-line
|>| Count_Items challenge via a single scan thru
|>| the input line,  and as usual Vowels will not admit it the PL/I
|>| syntax is lacking compared to Fortran syntax,
|>| then we can go on to a 2nd challenge thats been running concurrently
|>| over in comp.lang.fortran.
|>----snipped----

|> Frank, Frank, Frank.  I didn't see YOU post a 1-line solution.  What
|> you did post was a number of WRONG solutions, all of them at least
|> four or more lines, and obsure code at that.
|>
|> Also, it should be noted that your solution scanned the source line
|> twice, one as a character string, another in a boolean version (for
|> the COUNT function).   You really should learn how to count Fortran
|> statements.   I also noted that when your challenge was met (and
|> bested), you add the silly restriction that it had to be scanned only
|> once, a restriction that even your code doesn't do.   The goal in
|> programming is to find solutions to problems, if you don't like the
|> (better) solution, then don't come back and say, "well, I bet ya
|> can't do that with one hand behind your back !!". _________Gerard S.

| Gerard, Gerard, Gerard.
| You didnt come up with a Count_Items PL/I solution whereas:
| my 1 line solution that scans line ONCE can be viewed at:
|
|    http://earthlink.net/~dave_gemini/strings.f90

Frank, Frank, Frank.  This is getting rather tedious.  The reason I
didn't come up with a 1-liner solution was that it was already
solved by Robin (I believe).  No sense in duplicating efforts.  Note
that you seem to have a real difficult time with counting (Fortran)
lines.  Your 1-line solution needs six lines (counting the
invocation as 1 line, plus five more lines for the "1-line"
Fortran subroutine).   Hells bells, if everybody would count like
that, COUNT (in Fortran) would bring on a whole new meaning.  I'd
rather stick to the idea that 1-line means 1-line, not 5. ___Gerard S.

 


0
gerard46 (68)
8/20/2005 9:47:19 PM
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message 
news:3tNNe.51944$gP1.37086@fe12.news.easynews.com...

> <snip>
> Bottom-Line:
>          Simply stop posting to this newsgroup.
>

I'll log you into the camp that NO messages posted in comp.lang.pl1  is 
preferable to messages that
show its weaknesses, even tho occasionally there is some useful PL/I syntax 
posted for the edification of the readers as a results of my "cage-rattling" 
topics.

Oh I know whats up,  you want to be the last one here so that you can turn 
out the lights in this newsgroup,
sorry,  THATS MY PLAN !!


0
dave_frank (2243)
8/20/2005 9:52:21 PM
"gerard46" <gerard46@rtt.net> wrote in message 
news:HbKdnW5vMelMOZreRVn-gQ@onvoy.com...
>| David Frank
>
> |> Frank, Frank, Frank.  I didn't see YOU post a 1-line solution.  What
> |> you did post was a number of WRONG solutions, all of them at least
> |> four or more lines, and obsure code at that.
> |>
> |> Also, it should be noted that your solution scanned the source line
> |> twice, one as a character string, another in a boolean version (for
> |> the COUNT function).   You really should learn how to count Fortran
> |> statements.   I also noted that when your challenge was met (and
> |> bested), you add the silly restriction that it had to be scanned only
> |> once, a restriction that even your code doesn't do.   The goal in
> |> programming is to find solutions to problems, if you don't like the
> |> (better) solution, then don't come back and say, "well, I bet ya
> |> can't do that with one hand behind your back !!". _________Gerard S.
>
> | Gerard, Gerard, Gerard.
> | You didnt come up with a Count_Items PL/I solution whereas:
> | my 1 line solution that scans line ONCE can be viewed at:
> |
> |    http://earthlink.net/~dave_gemini/strings.f90
>
> Frank, Frank, Frank.  This is getting rather tedious.  The reason I
> didn't come up with a 1-liner solution was that it was already
> solved by Robin (I believe).

2 TALLY calls  = 2 scans   <GEESH>

 No sense in duplicating efforts.  Note
> that you seem to have a real difficult time with counting (Fortran)
> lines.  Your 1-line solution needs six lines (counting the
> invocation as 1 line, plus five more lines for the "1-line"
> Fortran subroutine).   Hells bells, if everybody would count like
> that, COUNT (in Fortran) would bring on a whole new meaning.  I'd
> rather stick to the idea that 1-line means 1-line, not 5. ___Gerard S.
>

We are talking count of # executable statements.
If you place your tally statement into a PL/I function called 
Count_items(line)
you have as many or more support statements as I do..


>
>
> 


0
dave_frank (2243)
8/20/2005 9:56:46 PM
| David Frank wrote:
|> gerard46 wrote:
|>| David Frank
|>|> Frank, Frank, Frank.  I didn't see YOU post a 1-line solution.  What
|>|> you did post was a number of WRONG solutions, all of them at least
|>|> four or more lines, and obsure code at that.
|>|>
|>|> Also, it should be noted that your solution scanned the source line
|>|> twice, one as a character string, another in a boolean version (for
|>|> the COUNT function).   You really should learn how to count Fortran
|>|> statements.   I also noted that when your challenge was met (and
|>|> bested), you add the silly restriction that it had to be scanned only
|>|> once, a restriction that even your code doesn't do.   The goal in
|>|> programming is to find solutions to problems, if you don't like the
|>|> (better) solution, then don't come back and say, "well, I bet ya
|>|> can't do that with one hand behind your back !!". _________Gerard S.
|>| Gerard, Gerard, Gerard.
|>| You didnt come up with a Count_Items PL/I solution whereas:
|>| my 1 line solution that scans line ONCE can be viewed at:
|>|
|>|    http://earthlink.net/~dave_gemini/strings.f90
|> Frank, Frank, Frank.  This is getting rather tedious.  The reason I
|> didn't come up with a 1-liner solution was that it was already
|> solved by Robin (I believe).
| 2 TALLY calls  = 2 scans   <GEESH>

Frank, Frank, Frank.  You tilting against windmills here.  Robin gave
you a good 1-liner solution, sucint and very easy to code.  Beating
your head against the wall because she didn't do it the way YOU want
is just silly.  Get over it.   In the real world, you code the
similiest solution for a problem, Robin did, you didn't, get over it.


|> No sense in duplicating efforts.  Note
|> that you seem to have a real difficult time with counting (Fortran)
|> lines.  Your 1-line solution needs six lines (counting the
|> invocation as 1 line, plus five more lines for the "1-line"
|> Fortran subroutine).   Hells bells, if everybody would count like
|> that, COUNT (in Fortran) would bring on a whole new meaning.  I'd
|> rather stick to the idea that 1-line means 1-line, not 5. ___Gerard S.
| We are talking count of # executable statements.

No, you're talking about executable statements.  I'm talking about
1-liners, the term that you orginally used.  Since you lost the war,
you're now changing the counting to something else.  Face reality, five
lines > 1 line.    One line is one line, not five.


| If you place your tally statement into a PL/I function called
| Count_items(line)

If, if, if ... There was no reason Robin had to put her 1-line
solution into a subroutine (like you HAD to for Fortran).


| you have as many or more support statements as I do..

I can't see how there'd be MORE, but you dream all you want.
Robin's TALLY solution is still more sucint and yours.  No matter
how you count five statements as one. ________________________Gerard S.




0
gerard46 (68)
8/20/2005 10:54:39 PM
| David Frank wrote:
|> gerard46 wrote:
|>| David Frank
|>|> Frank, Frank, Frank.  I didn't see YOU post a 1-line solution.  What
|>|> you did post was a number of WRONG solutions, all of them at least
|>|> four or more lines, and obsure code at that.
|>|>
|>|> Also, it should be noted that your solution scanned the source line
|>|> twice, one as a character string, another in a boolean version (for
|>|> the COUNT function).   You really should learn how to count Fortran
|>|> statements.   I also noted that when your challenge was met (and
|>|> bested), you add the silly restriction that it had to be scanned only
|>|> once, a restriction that even your code doesn't do.   The goal in
|>|> programming is to find solutions to problems, if you don't like the
|>|> (better) solution, then don't come back and say, "well, I bet ya
|>|> can't do that with one hand behind your back !!". _________Gerard S.
|>| Gerard, Gerard, Gerard.
|>| You didnt come up with a Count_Items PL/I solution whereas:
|>| my 1 line solution that scans line ONCE can be viewed at:
|>|
|>|    http://earthlink.net/~dave_gemini/strings.f90
|> Frank, Frank, Frank.  This is getting rather tedious.  The reason I
|> didn't come up with a 1-liner solution was that it was already
|> solved by Robin (I believe).
| 2 TALLY calls  = 2 scans   <GEESH>

 Frank, Frank, Frank.  You tilting against windmills here.  Robin gave
you a good 1-liner solution, succinct and very easy to code.  Beating
your head against the wall because she didn't do it the way YOU want
is just silly.  Get over it.   In the real world, you code the
similiest solution for a problem, Robin did, you didn't, get over it.


|> No sense in duplicating efforts.  Note
|> that you seem to have a real difficult time with counting (Fortran)
|> lines.  Your 1-line solution needs six lines (counting the
|> invocation as 1 line, plus five more lines for the "1-line"
|> Fortran subroutine).   Hells bells, if everybody would count like
|> that, COUNT (in Fortran) would bring on a whole new meaning.  I'd
|> rather stick to the idea that 1-line means 1-line, not 5. ___Gerard S.
| We are talking count of # executable statements.

 No, you're talking about executable statements.  I'm talking about
1-liners, the term that you orginally used.  Since you lost the war,
you're now changing the counting to something else.  Face reality, five
lines > 1 line.    One line is one line, not five.


| If you place your tally statement into a PL/I function called
| Count_items(line)

 If, if, if ... There was no reason Robin had to put her 1-line
solution into a subroutine (like you HAD to for Fortran).


| you have as many or more support statements as I do..

 I can't see how there'd be MORE, but you dream all you want.
Robin's TALLY solution is still more succinct and yours.  No matter
how you count five statements as one. ________________________Gerard S.


0
gerard46 (68)
8/20/2005 10:58:11 PM
If talking about "executable statements" - please provide the machine code of 
both the Fortran and PL/I compiled code (same platform, of course). Then we can 
count "executable statements".

I don't (personally) know of any machine that "executes" either PL/I or Fortran 
statements.  (There may be one or more, but I don't know of any).

Performance of "real-world" code is based on the "machine instructions" (or 
interrelated in the case of "virtual machines") statements.  As indicated 
elsewhere, there certainly ARE cases where performance is a real-world issue. 
Therefore, a VALID comparison showing such code (or execution times) *MIGHT* 
actually show an advantage of one programming language over another (for a 
SPECIFIC coding requirement)

-- 
Bill Klein
 wmklein <at> ix.netcom.com
"David Frank" <dave_frank@hotmail.com> wrote in message 
news:yGNNe.7174$RZ2.1898@newsread3.news.atl.earthlink.net...
>
> "gerard46" <gerard46@rtt.net> wrote in message 
> news:HbKdnW5vMelMOZreRVn-gQ@onvoy.com...
>>| David Frank
>>
>> |> Frank, Frank, Frank.  I didn't see YOU post a 1-line solution.  What
>> |> you did post was a number of WRONG solutions, all of them at least
>> |> four or more lines, and obsure code at that.
>> |>
>> |> Also, it should be noted that your solution scanned the source line
>> |> twice, one as a character string, another in a boolean version (for
>> |> the COUNT function).   You really should learn how to count Fortran
>> |> statements.   I also noted that when your challenge was met (and
>> |> bested), you add the silly restriction that it had to be scanned only
>> |> once, a restriction that even your code doesn't do.   The goal in
>> |> programming is to find solutions to problems, if you don't like the
>> |> (better) solution, then don't come back and say, "well, I bet ya
>> |> can't do that with one hand behind your back !!". _________Gerard S.
>>
>> | Gerard, Gerard, Gerard.
>> | You didnt come up with a Count_Items PL/I solution whereas:
>> | my 1 line solution that scans line ONCE can be viewed at:
>> |
>> |    http://earthlink.net/~dave_gemini/strings.f90
>>
>> Frank, Frank, Frank.  This is getting rather tedious.  The reason I
>> didn't come up with a 1-liner solution was that it was already
>> solved by Robin (I believe).
>
> 2 TALLY calls  = 2 scans   <GEESH>
>
> No sense in duplicating efforts.  Note
>> that you seem to have a real difficult time with counting (Fortran)
>> lines.  Your 1-line solution needs six lines (counting the
>> invocation as 1 line, plus five more lines for the "1-line"
>> Fortran subroutine).   Hells bells, if everybody would count like
>> that, COUNT (in Fortran) would bring on a whole new meaning.  I'd
>> rather stick to the idea that 1-line means 1-line, not 5. ___Gerard S.
>>
>
> We are talking count of # executable statements.
> If you place your tally statement into a PL/I function called 
> Count_items(line)
> you have as many or more support statements as I do..
>
>
>>
>>
>>
>
> 


0
wmklein (2605)
8/20/2005 11:05:35 PM
William M. Klein wrote:
> I don't (personally) know of any machine that "executes" either PL/I or Fortran 
> statements.  (There may be one or more, but I don't know of any).

Back in the 60's, Allan-Babcock's RUSH time-sharing service used a 
modified 360/50 with a microcode PL/I interpreter. However, it must have 
used a preprocessor or significantly non-standard PL/I, as it is 
impossible to determine the semantics of a PL/I program in a single pass.

-- 
John W. Kennedy
"The pathetic hope that the White House will turn a Caligula into a 
Marcus Aurelius is as naïve as the fear that ultimate power inevitably 
corrupts."
   -- James D. Barber (1930-2004)
0
jwkenne (1442)
8/21/2005 12:10:51 AM
John W. Kennedy wrote in message ...
>William M. Klein wrote:
>> I don't (personally) know of any machine that "executes" either PL/I or
Fortran
>> statements.  (There may be one or more, but I don't know of any).
>
>Back in the 60's, Allan-Babcock's RUSH time-sharing service used a
>modified 360/50 with a microcode PL/I interpreter. However, it must have
>used a preprocessor or significantly non-standard PL/I, as it is
>impossible to determine the semantics of a PL/I program in a single pass.

The whole language, perhaps, but a single pass compiler was
done for a subset on the CDC Cyber.


0
robin_v (2737)
8/21/2005 2:17:35 AM
David Frank wrote in message ...
>Since its obvious there is NO PL/I solution to translate my 1-line
>Count_Items challenge via a single scan thru
>the input line,

get string(trim(line)) list ((v do COUNT = 1 to length(line));

>then we can go on to a 2nd challenge thats been running concurrently over in
>comp.lang.fortran.
>Posted only for PLI'er info,  there wont be a PL/I translation.
>
>Since its my challenge I am narrowing the acceptable solutions in reduce.f90
>as follows:
>
>3.  Fast/Legible/Brief   is a goal.

Yours does not meet your own "criterion".  Giles says that your
code is "ugly".


=======
From: James Giles <jamesgiles@worldnet.att.net>
Subject: Re: Reduce Blanks continued
Date: Friday, 19 August 2005 14:07

David Frank wrote:

>    2. set which chars are to be preserved in a logical mask (note
> the  NEW 1-liner)
>
>       out = [ .true., (a(i)/=' '.or.a(i-1)/=' ',i=2,len(line)) ]

This is ugly and less legible than my code



0
robin_v (2737)
8/21/2005 2:17:36 AM
David Frank wrote in message ...
>we can go on to a 2nd challenge thats been running concurrently over in
>comp.lang.fortran.
>Posted only for PLI'er info,  there wont be a PL/I translation.

>Since its my challenge I am narrowing the acceptable solutions in reduce.f90
>as follows:
>
>1.  the output string must contain a blank last char (if input string has 1
>or more trailing blanks)
>     by output of  a null char after just 1 trailing blank char is output.
>2.  the solution must use array syntax, no scalar processing with do loops
>3.  Fast/Legible/Brief   is a goal.
>
>If you want to submit or resubmit a solution that meets these revisions,  be
>my guest,  sometime next week
>I will kick out existing solutions that dont meet above specs, leaving room
>for new entries.
>
>My current solution that meets these revised specs, uses 3 statements:


No it doesn't.  It uses 22 statements, made up of three plus the 19 statements
in COPY :-

INTERFACE Copy
   MODULE PROCEDURE copy_a2s, copy_s2a
END INTERFACE CopyCONTAINS
! ------------------------
FUNCTION Copy_a2s(a)  RESULT (s)    ! copy char array to string
CHARACTER :: a(:)
CHARACTER(SIZE(a)) :: s
INTEGER :: i
DO i = 1,SIZE(a)
   s(i:i) = a(i)
END DO
END FUNCTION Copy_a2s
! ------------------------
FUNCTION Copy_s2a(s)  RESULT (a)   ! copy string to char array
CHARACTER(*) :: s
CHARACTER :: a(LEN(s))
INTEGER :: i
DO i = 1,LEN(s)
   a(i) = s(i:i)
END DO
END FUNCTION Copy_s2a

>pad = char(0)      ! allow pack to use null chars to pad its output
>a = Copy(line)     ! copy line to char array
>outline = line(1:1)  //  Copy( PACK(a(2:), a(2:)/=' '.or.a(1:)/=' ',pad) )


0
robin_v (2737)
8/21/2005 2:33:21 AM
robin wrote:
> John W. Kennedy wrote in message ...
> 
>>William M. Klein wrote:
>>
>>>I don't (personally) know of any machine that "executes" either PL/I or
> 
> Fortran
> 
>>>statements.  (There may be one or more, but I don't know of any).
>>
>>Back in the 60's, Allan-Babcock's RUSH time-sharing service used a
>>modified 360/50 with a microcode PL/I interpreter. However, it must have
>>used a preprocessor or significantly non-standard PL/I, as it is
>>impossible to determine the semantics of a PL/I program in a single pass.
> 
> 
> The whole language, perhaps, but a single pass compiler was
> done for a subset on the CDC Cyber.

The whole language /definitely/, because PL/I (and this is one of 
several mistakes in the language) allows something to be declared after 
it is first used. At an absolute minimum, a PL/I interpreter requires a 
pre-pass to hoist all DECLARE statements (and DEFAULT and DEFINE, in 
more recent dialects) to the top of their containing blocks, and to 
insert pseudo-declares of internal LABEL and ENTRY constants.

(Of course, no-one sane does an interpreter without a pre-pass nowadays, 
anyway; if only for the sake of translating expressions to RPN or 
something of the sort.)

-- 
John W. Kennedy
"...if you had to fall in love with someone who was evil, I can see why 
it was her."
   -- "Alias"
0
jwkenne (1442)
8/21/2005 2:45:51 AM
David Frank wrote:

> AMAZING what 6-16 oz miller lite drafts will do to one's cognizant powers on 
> a saturday afternoon.
> 
That explains SO much.  :-)


Bob Lidral
lidral at alum dot mit dot edu
0
8/21/2005 4:45:37 AM
robin wrote:

> John W. Kennedy wrote in message ...
> 
>>William M. Klein wrote:
>>
>>>I don't (personally) know of any machine that "executes" either PL/I or
> 
> Fortran
> 
>>>statements.  (There may be one or more, but I don't know of any).
>>
>>Back in the 60's, Allan-Babcock's RUSH time-sharing service used a
>>modified 360/50 with a microcode PL/I interpreter. However, it must have
>>used a preprocessor or significantly non-standard PL/I, as it is
>>impossible to determine the semantics of a PL/I program in a single pass.
> 
> 
> The whole language, perhaps, but a single pass compiler was
> done for a subset on the CDC Cyber.
> 
> 
Well, yes, but it was never very useful.  In the 1970s, the University
of Illinois decided to replace their IBM 360 with a more powerful
machine that would support their existing collection of code.  Several
departments had whole piles of PL/I, FORTRAN IV, and COBOL code they
needed to continue to use, and that limited the potential bidders.  As I
recall, in the end the three remaining bidders were IBM (the U of I was
willing to consider replacing the 360 with a more powerful 360 -- it
wasn't that they didn't like the 360, they just needed one with more
power), Amdahl, and Control Data Corporation.

I heard rumors that the proposed IBM and Amdahl solutions were pretty
competitive with each other but the CDC solution had a much better
performance-to-cost ratio.  This is not surprising since the benchmark
was batch-oriented.

The only problem with the CDC solution was that CDC had no PL/I compiler
so the U of I wrote that into the contract as a requirement.
Supposedly, CDC got the contract with the proviso that they deliver a
working PL/I compiler within some time frame following the delivery of
the machine.  As I recall, I was there for 2 more years after the CYBER
was placed into service and never saw the PL/I compiler -- presumably 
CDC never implemented enough of the language to meet the contract
specifications.  I'm not absolutely certain, since I was never privy to
any of the financial information, but I suspect the U of I contract may
have been the only reason CDC agreed to produce a PL/I compiler.

Since I went to work for CDC immediately after leaving the University of
Illinois, I had occasion to check their product lists a few years later.
PL/I had been moved to the list of products one could only order if one
already knew they existed (or worked for CDC and had access to internal
documents) and which were no longer supported.  I had heard almost
nothing about the status of the compiler in the interim except that
friends of mine who knew I worked for CDC kept asking me about it and I
could tell them almost nothing.  It was removed from all product 
listings a short time later (about 4 years after I left the U of I).

Part of the problem was that most of the people (at least most of those
I met) from the CDC compiler group absolutely loathed IBM and any
product even remotely associated with it with an intensity difficult to
imagine even in today's political climate.  It's probably unfair to
accuse them of dragging their feet, but I suspect they placed a lower
priority on PL/I than did their customers.  In any case, I don't recall
ever hearing of anybody or any shop that used it very much.  Most of the
complaints I heard was that the subset was way too limited to be of much
use in supporting existing code.


Bob Lidral
lidral at alum dot mit dot edu
0
8/21/2005 4:49:38 AM
Count_Items = COUNT([LEN_TRIM(s) > 0,(s(i:i)/=' '.AND.s(i+1:i+1)==' ', 
i=1,LEN_TRIM(s)-1)])

is my 1-liner that scans the string "s" just once as per challenge to show 
Fortran has more powerful syntax than PL/I.

Otoh,   Count_Items = 1 + Tally(s,' ') - Tally(s,'  ')  scans "s"  twice.

As I have stated more than once, if the readership wants me to cease and 
desist rubbing their noses in their archaic language's short comings, INSIST 
Vowels change the claim in the PL/I FAQ..

Otherwise its apparent you guys dont want me to go away all that bad!! 


0
dave_frank (2243)
8/21/2005 7:25:39 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:4vRNe.5947$FA3.5307@news-server.bigpond.net.au...
>
> David Frank wrote in message ...
>>Since its obvious there is NO PL/I solution to translate my 1-line
>>Count_Items challenge via a single scan thru
>>the input line,
>
> get string(trim(line)) list ((v do COUNT = 1 to length(line));
>
>>then we can go on to a 2nd challenge thats been running concurrently over 
>>in
>>comp.lang.fortran.
>>Posted only for PLI'er info,  there wont be a PL/I translation.
>>
>>Since its my challenge I am narrowing the acceptable solutions in 
>>reduce.f90
>>as follows:
>>
>>3.  Fast/Legible/Brief   is a goal.
>
> Yours does not meet your own "criterion".  Giles says that your
> code is "ugly".
>
>
> =======
> From: James Giles <jamesgiles@worldnet.att.net>
> Subject: Re: Reduce Blanks continued
> Date: Friday, 19 August 2005 14:07
>
> David Frank wrote:
>
>>    2. set which chars are to be preserved in a logical mask (note
>> the  NEW 1-liner)
>>
>>       out = [ .true., (a(i)/=' '.or.a(i-1)/=' ',i=2,len(line)) ]
>
> This is ugly and less legible than my code
>
>
>

Giles thinks his own code is more legible which opinion I think starts and 
ends with him ..
His statements to set his flag mask are opaque to reader on first encounter.
What do you think about my 1 statement vs. below, do you agree with him?

flag = c == ' '
flag(2:) = .not.(flag(:len(line)-1) .and. flag(2:))
flag(1) = .true.


In any case, your next message (also cross-posted BY YOU  from 
comp.lang.pl1)  shows my insightful 2char test (that Giles and everyone 
overlooked and is source of his pique)  adapts to array syntax and is 
imbedded into

    outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR. a(1:) /= ' 
',  pad) )


0
dave_frank (2243)
8/21/2005 8:14:54 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:RJRNe.5955$FA3.3343@news-server.bigpond.net.au...
>

>
> No it doesn't.  It uses 22 statements, made up of three plus the 19 
> statements
> in COPY :-
>

Future users write 1 line...

   a = Copy(line)   or    s = Copy(a)

they could care less that Copy source has 3 executable statements that have 
been pre-compiled into a module
that can be linked to other user programs, or added to a user library.  But 
you know this, you are just blathering as usual covering up the 
short-comings in your fav language's syntax.

You have stated that PL/I supports generic routines, but when asked to show 
code, refuse to do so.
Here's  another chance,  show Fortran'ers and your DEVOTED PL/I readership 
YOUR generic Copy function.



0
dave_frank (2243)
8/21/2005 8:25:19 AM
David Frank wrote:
> "robin" <robin_v@bigpond.com> wrote in message 
> news:RJRNe.5955$FA3.3343@news-server.bigpond.net.au...
> 
> 
>>No it doesn't.  It uses 22 statements, made up of three plus the 19 
>>statements
>>in COPY :-
>>
> 
> 
> Future users write 1 line...
> 
>    a = Copy(line)   or    s = Copy(a)
> 
> they could care less that Copy source has 3 executable statements that have 
> been pre-compiled into a module
> that can be linked to other user programs, or added to a user library.  But 
> you know this, you are just blathering as usual covering up the 
> short-comings in your fav language's syntax.

So you are now claiming that it is permissible, in your language 
challenges, to use user-defined language functions that *don't* count 
against the number of lines in a solution.

Fair enough.

Here is my winning 1-liner for blank reduction:

outline = REDUCE_BLANKS(line)

The function REDUCE_BLANKS() is a module routine -- it can be linked to 
other user programs, or added to a user library. Before I provide the 
source code for this incredibly fast routine, YOU must show me your routine.

cheers,

Rich
0
rhdt (1081)
8/21/2005 2:07:15 PM
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message 
news:dea1pa$p1j$1@scrotar.nss.udel.edu...
 short-comings in your fav language's syntax.
>
> So you are now claiming that it is permissible, in your language 
> challenges, to use user-defined language functions that *don't* count 
> against the number of lines in a solution.
>
> Fair enough.
>
> Here is my winning 1-liner for blank reduction:
>
> outline = REDUCE_BLANKS(line)
>
> The function REDUCE_BLANKS() is a module routine -- it can be linked to 
> other user programs, or added to a user library. Before I provide the 
> source code for this incredibly fast routine, YOU must show me your 
> routine.
>
> cheers,
>
> Rich

My OFFICIAL ENTRY in the challenge is already in a module by that name where 
you can view the source.

 http://home.earthlink.net/~dave_gemini/strings.f90

and has been there for about 2 weeks now getting occasional updates but it 
looks like its now finalized.

The benchmark code at:
http://home.earthlink.net/~dave_gemini/reduce.f90     USEs string_functions 
in strings.f90 file including my reduce_blanks function,   Where have you 
been?

If you want to submit your REDUCE_BLANKS_TOWNSEND function to be entered in 
the reduce.f90 benchmark,
be my guest,  but there are new rules, (use array syntax, return 1 trailing 
blank)
AND yes, you can use ANY aids you see in string_functions  including just a 
duplication of my function IF you have a modification that allows it to run 
a little faster,  so have a go, say what!  (that applies to anyone)..


0
dave_frank (2243)
8/21/2005 2:34:00 PM
David Frank wrote in message ...
>AMAZING what 6-16 oz miller lite drafts will do to one's cognizant powers on
>a saturday afternoon.

Seems that Frank has a heavy drinking problem --
accounts for his irrational postings.

>The CORRECT  link is: [...]


0
robin_v (2737)
8/21/2005 3:54:59 PM
David Frank wrote in message ...
>we can go on to a 2nd challenge thats been running concurrently over in
>comp.lang.fortran.
>Posted only for PLI'er info,  there wont be a PL/I translation.
>
><<<<<<<
>Since its my challenge I am narrowing the acceptable solutions in reduce.f90
>as follows:
>
>1.  the output string must contain a blank last char (if input string has 1
>or more trailing blanks)
>     by output of  a null char after just 1 trailing blank char is output.
>2.  the solution must use array syntax, no scalar processing with do loops
>3.  Fast/Legible/Brief   is a goal.
>
>My current solution that meets these revised specs, uses 3 statements:


This does not meet your specification:
    Line 2 uses a user function of 19 statements (fails spec #3).

>pad = char(0)      ! allow pack to use null chars to pad its output
>a = Copy(line)     ! copy line to char array
>outline = line(1:1)  //  Copy( PACK(a(2:), a(2:)/=' '.or.a(1:)/=' ',pad) )


0
robin_v (2737)
8/21/2005 3:55:00 PM
David Frank wrote in message ...
>we can go on to a 2nd challenge thats been running concurrently over in
>comp.lang.fortran.
>Posted only for PLI'er info,  there wont be a PL/I translation.

>Since its my challenge I am narrowing the acceptable solutions in reduce.f90
>as follows:
>
>1.  the output string must contain a blank last char (if input string has 1
>or more trailing blanks)
>     by output of  a null char after just 1 trailing blank char is output.
>2.  the solution must use array syntax, no scalar processing with do loops
>3.  Fast/Legible/Brief   is a goal.
>
>My current solution that meets these revised specs, uses 3 statements:
>
>pad = char(0)      ! allow pack to use null chars to pad its output
>a = Copy(line)     ! copy line to char array
>outline = line(1:1)  //  Copy( PACK(a(2:), a(2:)/=' '.or.a(1:)/=' ',pad) )


I think that this will do it in PL/I :-

line = pack (a, (a^=' ') | (b ^= ' '), rank(0) );


0
robin_v (2737)
8/21/2005 3:55:01 PM
"robin" <robin_v@bigpond.com> wrote in message 
news:pt1Oe.6470$FA3.4172@news-server.bigpond.net.au...
>
>>
>>My current solution that meets these revised specs, uses 3 statements:
>>
>>pad = char(0)      ! allow pack to use null chars to pad its output
>>a = Copy(line)     ! copy line to char array
>>outline = line(1:1)  //  Copy( PACK(a(2:), a(2:)/=' '.or.a(1:)/=' ',pad) )
>
>
> I think that this will do it in PL/I :-
>
> line = pack (a, (a^=' ') | (b ^= ' '), rank(0) );
>

I think NOT
Did you forget you cross-posted and are being read by REAL programmers here 
in comp.lang.fortran?

Arent you embarrassed to post fictitious PL/I syntax?
1. There is no PL/I pack function

2. you cant write a COPY string into an array function as PL/I doesnt 
support dynamic function output determined
    by input size or length, so much for any possibility you can write a 
generic Copy function.

3. You dont have a magical TRANSFER function to substitute,  you gots lotsa 
problems besides no pack.

4. what is "b" supposed to be?

As usual you never show your statements actually work in a test program



0
dave_frank (2243)
8/21/2005 4:41:43 PM
robin wrote:
> David Frank wrote in message ...
> 
>>Since its obvious there is NO PL/I solution to translate my 1-line
>>Count_Items challenge via a single scan thru
>>the input line,
> 
> 
> get string(trim(line)) list ((v do COUNT = 1 to length(line));
> 
This won't work as you intend.  Even after you fix the missing parenthesis 
error, the statement will raise the ERROR condition and the value of COUNT at 
that point will be one too large.
0
jjw (608)
8/21/2005 7:56:59 PM
David Frank wrote:
....
> In any case, your next message (also cross-posted BY YOU  from
> comp.lang.pl1)  shows my insightful 2char test (that Giles and
> everyone overlooked and is source of his pique)  adapts to array
> syntax and is imbedded into
>
>     outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR.
> a(1:) /= ' ',  pad) )

This is a broken code.  A(2:) is not conformable to A(1:)
and the results of the two compares cannot be .OR.ed to
each other.  You would have to do something like the
following to fix it:

   outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR.
> a(1:len(line)-1) /= ' ',  pad) )

If you fix that, it still calls for each value of the array
(except the first) to be compared to blank *twice*.  That's
a pessimization my code doesn't require.  Sure a good
optimizer *might* find it and reconstruct *my* original
code.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare


0
jamesgiles (2210)
8/21/2005 8:43:26 PM
"James Giles" <jamesgiles@worldnet.att.net> wrote in message 
news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
> David Frank wrote:
> ...
>> In any case, your next message (also cross-posted BY YOU  from
>> comp.lang.pl1)  shows my insightful 2char test (that Giles and
>> everyone overlooked and is source of his pique)  adapts to array
>> syntax and is imbedded into
>>
>>     outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR.
>> a(1:) /= ' ',  pad) )
>
> This is a broken code.  A(2:) is not conformable to A(1:)

CVF sees  Pack (  A(2:) ,  A(2:) /= ' '   are same size arrays and A(1:)  is 
at least larger,
 thus it has no reason to complain, CVF is smart!!!

> and the results of the two compares cannot be .OR.ed to
> each other.  You would have to do something like the
> following to fix it:
>
>   outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR.
>> a(1:len(line)-1) /= ' ',  pad) )
>
> If you fix that,

CVF says there is NOTHING TO FIX...

 it still calls for each value of the array
> (except the first) to be compared to blank *twice*.  That's
> a pessimization my code doesn't require.  Sure a good
> optimizer *might* find it and reconstruct *my* original
> code.

Ha ha what a bitter pill for you  to swallow seeing how simple the 2 char OR 
logic is,
only one of which WILL EXECUTE.




0
dave_frank (2243)
8/21/2005 10:18:11 PM
David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message 
> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
> 
>>David Frank wrote:
>>...
>>
>>>In any case, your next message (also cross-posted BY YOU  from
>>>comp.lang.pl1)  shows my insightful 2char test (that Giles and
>>>everyone overlooked and is source of his pique)  adapts to array
>>>syntax and is imbedded into
>>>
>>>    outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR.
>>>a(1:) /= ' ',  pad) )
>>
>>This is a broken code.  A(2:) is not conformable to A(1:)
> 
> 
> CVF sees  Pack (  A(2:) ,  A(2:) /= ' '   are same size arrays and A(1:)  is 
> at least larger,
>  thus it has no reason to complain, CVF is smart!!!
> 

No, A(1:) and A(2:) are not conformable, therefore your code violates 
the standard - exactly as Giles pointed out.

That CVF does not pick up on this is probably because you are running 
without array bounds checking. Could you re-run with checking enabled, 
and post the results to this forum? I'm curious as to whether CVF is 
broken in this respect, or whether the problem is just with your 
comprehension of the standard.

cheers,

Rich
0
rhdt (1081)
8/21/2005 11:09:43 PM
David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
>> David Frank wrote:
>> ...
>>> In any case, your next message (also cross-posted BY YOU  from
>>> comp.lang.pl1)  shows my insightful 2char test (that Giles and
>>> everyone overlooked and is source of his pique)  adapts to array
>>> syntax and is imbedded into
>>>
>>>     outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR.
>>> a(1:) /= ' ',  pad) )
>>
>> This is a broken code.  A(2:) is not conformable to A(1:)
>
> CVF sees  Pack (  A(2:) ,  A(2:) /= ' '   are same size arrays and
> A(1:)  is at least larger,
>  thus it has no reason to complain, CVF is smart!!!

You mean CVF is stupid in this instance.  There is no
reson for confomability tests to be removed in this kind
of case.

You delusional and getting worse.  The rest of your
diatribe is beneath contempt and not even worthy of
response.  Say something with technical merit and
people will take you more seriously.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare


0
jamesgiles (2210)
8/21/2005 11:44:00 PM
Bob Lidral wrote in message ...
>robin wrote:
>
>> John W. Kennedy wrote in message ...
>>
>>>William M. Klein wrote:
>>>
>>>>I don't (personally) know of any machine that "executes" either PL/I or
>>
>> Fortran
>>
>>>>statements.  (There may be one or more, but I don't know of any).
>>>
>>>Back in the 60's, Allan-Babcock's RUSH time-sharing service used a
>>>modified 360/50 with a microcode PL/I interpreter. However, it must have
>>>used a preprocessor or significantly non-standard PL/I, as it is
>>>impossible to determine the semantics of a PL/I program in a single pass.
>>
>>
>> The whole language, perhaps, but a single pass compiler was
>> done for a subset on the CDC Cyber.
>>
>>
>Well, yes, but it was never very useful.

I wasn't referring to the CDC compiler.


0
robin_v (2737)
8/22/2005 12:06:37 AM
David Frank wrote:
(snip)

> My current solution that meets these revised specs, uses 3 statements:
> 
> pad = char(0)      ! allow pack to use null chars to pad its output
> a = Copy(line)     ! copy line to char array
> outline = line(1:1)  //  Copy( PACK(a(2:), a(2:)/=' '.or.a(1:)/=' ',pad) )

There was, somewhere in this discussion the question about how
many passes through the array different solutions make.

Would someone like to tell me how many passes through the
array this one makes?

The array operators are nice, and PL/I has them, too, but sometimes
they can result in much more work being done than without array
operators.

-- glen

0
gah (12851)
8/22/2005 6:01:41 AM
On Sun, 21 Aug 2005 16:41:43 GMT, David Frank wrote:

>> I think that this will do it in PL/I :-
>>
>> line = pack (a, (a^=' ') | (b ^= ' '), rank(0) );
>>
> 
> I think NOT
> Did you forget you cross-posted and are being read by REAL programmers here 
> in comp.lang.fortran?
> 
> Arent you embarrassed to post fictitious PL/I syntax?

The syntax is valid PLI.

> 1. There is no PL/I pack function

But PACK could be a user-function. Which you yourself said is allowed.

-- 
Tim C.
0
8/22/2005 8:38:15 AM
"Tim Challenger" <tim.challenger@aon.at> wrote in message 
news:1124699765.17b90c8dbed03e32764504cabd3dc93d@teranews...
> On Sun, 21 Aug 2005 16:41:43 GMT, David Frank wrote:
>
>>> I think that this will do it in PL/I :-
>>>
>>> line = pack (a, (a^=' ') | (b ^= ' '), rank(0) );
>>>
>>
>> I think NOT
>> Did you forget you cross-posted and are being read by REAL programmers 
>> here
>> in comp.lang.fortran?
>>
>> Arent you embarrassed to post fictitious PL/I syntax?
>
> The syntax is valid PLI.
>
>> 1. There is no PL/I pack function
>
> But PACK could be a user-function. Which you yourself said is allowed.
>

Thats absolutely true and I considered whether there was ANY possibility 
that PL/I syntax supported writing a user PACK function and it boggled my 
imagination so much I broke out laffing.

Otoh,  my generic Copy function WAS written and can be viewed:
       http://home.earthlink.net/~dave_gemini/strings.f90

and its use demo'ed in the reduce_blanks benchmark

     http://home.earthlink.net/~dave_gemini/reduce.f90

Do you agree that PL/I cannot duplicate my generic Copy function?



0
dave_frank (2243)
8/22/2005 9:16:00 AM
"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...

> and the results of the two compares cannot be .OR.ed to
> each other.  You would have to do something like the
> following to fix it:
>

The "results of the two compares cannot be .OR.ed to each other"  ?????

Thats not happening,  when pack sees the first test for a char existing 
which happens 5x more frequently than the
OPTIONAL 2nd test involving the previous char,  it immediately packs the 
char and MOVES ON,
BECAUSE its a  OR    not  a   AND 


0
dave_frank (2243)
8/22/2005 9:24:53 AM
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message 
news:deb1ie$4qc$1@scrotar.nss.udel.edu...
> David Frank wrote:

> No, A(1:) and A(2:) are not conformable, therefore your code violates the 
> standard - exactly as Giles pointed out.
>
> That CVF does not pick up on this is probably because you are running 
> without array bounds checking. Could you re-run with checking enabled, and 
> post the results to this forum? I'm curious as to whether CVF is broken in 
> this respect, or whether the problem is just with your comprehension of 
> the standard.
>

And I'm curious if ANYONE's compiler rejects my statement..

Explain how could there be ANY possibility of exceeding array bounds?

The DRIVING index is being conducted by PACK's  array  a(2:)   and its size 
AND bounds are CONTAINED
within  a(1:)   which makes CVF happy.


0
dave_frank (2243)
8/22/2005 9:33:43 AM
OK, when I was experimenting using my PACK syntax in a test program
suddenly CVF got unhappy with the identical PACK syntax that was acceptable 
in my strings.f90 file..
So I am WRONG,  acceptance is NOT assured and I have  updated my 
REDUCE_BLANKS function in

     http://home.earthlink.net/~dave_gemini/strings.f90

accordingly to use    PACK (  a(2:),  a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /= 
'  '),  pad )

This is a CVF bug,
also noted is removing the -1  from the LEN(LINE) also made it accept the 
statement in my test program. 


0
dave_frank (2243)
8/22/2005 10:44:40 AM
On Mon, 22 Aug 2005 09:16:00 GMT, David Frank wrote:

> "Tim Challenger" <tim.challenger@aon.at> wrote in message 
> news:1124699765.17b90c8dbed03e32764504cabd3dc93d@teranews...
>> On Sun, 21 Aug 2005 16:41:43 GMT, David Frank wrote:
>>
>>>> I think that this will do it in PL/I :-
>>>>
>>>> line = pack (a, (a^=' ') | (b ^= ' '), rank(0) );
>>>>
>>>
>>> I think NOT
>>> Did you forget you cross-posted and are being read by REAL programmers 
>>> here
>>> in comp.lang.fortran?
>>>
>>> Arent you embarrassed to post fictitious PL/I syntax?
>>
>> The syntax is valid PLI.
>>
>>> 1. There is no PL/I pack function
>>
>> But PACK could be a user-function. Which you yourself said is allowed.
>>
> 
> Thats absolutely true and I considered whether there was ANY possibility 
> that PL/I syntax supported writing a user PACK function and it boggled my 
> imagination so much I broke out laffing.

You really are a twit aren't you?

-- 
Tim C.
0
8/22/2005 11:13:19 AM
"Tim Challenger" <tim.challenger@aon.at> wrote in message 
news:1124709069.7d47947a0368832b424783e50fa2110e@teranews...
> On Mon, 22 Aug 2005 09:16:00 GMT, David Frank wrote:
>
>>
>> Thats absolutely true and I considered whether there was ANY possibility
>> that PL/I syntax supported writing a user PACK function and it boggled my
>> imagination so much I broke out laffing.
>
> You really are a twit aren't you?
>

Why for truthfully answering your question?
Otoh, my question to you

>> "Do you agree that PL/I cannot duplicate my generic Copy function? "

was ignored.
I will add a 2nd question to you,  do you think PL/I syntax supports a 
user-written PACK function?






0
dave_frank (2243)
8/22/2005 11:23:53 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:57CdnaTewo2W95TeRVn-gg@comcast.com...
> David Frank wrote:
> (snip)
>
>> My current solution that meets these revised specs, uses 3 statements:
>>
>> pad = char(0)      ! allow pack to use null chars to pad its output
>> a = Copy(line)     ! copy line to char array
>> outline = line(1:1)  //  Copy( PACK(a(2:), a(2:)/=' '.or.a(1:)/=' 
>> ',pad) )
>
> There was, somewhere in this discussion the question about how
> many passes through the array different solutions make.
>
> Would someone like to tell me how many passes through the
> array this one makes?
>

you sure you are not talking about Count_Items(line) challenge to make 1 
pass thru line?

> The array operators are nice, and PL/I has them, too,

Can it array-slice as used above   a(2:)   ?


> they can result in much more work being done than without array
> operators.
>

I wouldnt say CVF does much more..

OK, Glen  since I have found you to be one of the more rational folks 
posting in comp.lang.pl1

I put it to you to arbitrate Giles and myself position.
He thinks his flag setting results:

1.  in a faster solution than my 3 statements above, it doesnt, both run in 
0.81 +-0.01 sec
2. he thinks his flag setting is more legible, but I violently disagree, 
what do you think?

Sooo, have a look at below


include "strings.f90"
! --------------------
program test
use string_functions
character(40) :: line = '  the  quick brown    fox'
character(40) :: newline
real :: t1,t2

do
   call cpu_time(t1)
   do n = 1,1000000
      newline = reduce_blanks(line)   ! see: string_functions
   end do
   call cpu_time(t2)
   write (*,91) 'frank  ',t2-t1,' |',ctrim(newline),'|'

   call cpu_time(t1)
   do n = 1,1000000
      newline = reduce_blanks_flag(line)
   end do
   call cpu_time(t2)
   write (*,91) 'giles  ',t2-t1,' |',ctrim(newline),'|'

   read (*,*)    ! <cr> repeat 2 tests above
end do
stop
91 format (a,f0.2,3a)
contains
! --------------------
function reduce_blanks_flag (line)  result (outline)
character(*)         :: line
character(LEN(line)) :: outline
character            :: a(len(line)), pad(len(line))
logical              :: flag(len(line))

pad = char(0)  ;   a = Copy(line)
flag = a == ' '
flag(2:) = .not.(flag(:len(line)-1) .and. flag(2:))      !   H O R R I F I C
flag(1) = .true.
outline = copy( pack(a, flag, pad) )

end function reduce_blanks_flag
end program


0
dave_frank (2243)
8/22/2005 11:59:29 AM
David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message 
> news:deb1ie$4qc$1@scrotar.nss.udel.edu...
> 
>>David Frank wrote:
> 
> 
>>No, A(1:) and A(2:) are not conformable, therefore your code violates the 
>>standard - exactly as Giles pointed out.
>>
>>That CVF does not pick up on this is probably because you are running 
>>without array bounds checking. Could you re-run with checking enabled, and 
>>post the results to this forum? I'm curious as to whether CVF is broken in 
>>this respect, or whether the problem is just with your comprehension of 
>>the standard.
>>
> 
> 
> And I'm curious if ANYONE's compiler rejects my statement..
> 
> Explain how could there be ANY possibility of exceeding array bounds?
> 
> The DRIVING index is being conducted by PACK's  array  a(2:)   and its size 
> AND bounds are CONTAINED
> within  a(1:)   which makes CVF happy.

CVF may be happy, but it is wrong. By your absurd argument, the 
following code should work without problem:

---
program test_conf

character(1), dimension(30), allocatable :: a

a = TRANSFER(' The  quick  brown  fox ', ' ')

print *, a(2:) /= ' ' .OR.  a(1:) /= ' '

end program test_conf
----

However, upon compiling, ifort gives the following message:

===
fortcom: Error: test_conf.f90, line 7: The shapes of the array 
expressions do not conform.
print *, a(2:) /= ' ' .OR.  a(1:) /= ' '
----------------------^
compilation aborted for test_conf.f90 (code 1)
===

g95 gives:

===
In file test_conf.f90:7

print *, a(2:) /= ' ' .OR.  a(1:) /= ' '
                          1
Error: .OR. operation at (1) has different shape on dimension 1 (29/30)
===

lf95 (Lahey) gives:

===
   2105-S: "test_conf.f90", line 7, column 23: In elemental binary 
operations two operands must conform in shape.
Encountered 1 error, 0 warnings in file test_conf.f90.
===

Please compile test_conf with CVF, post the result (if you will not, I'm 
sure others will), and then explain why CVF is 'not happy'. Hint: you 
should be able to figure out what the problem is by reading the error 
messages. If you contend that this example code is not using the same 
non-standard construct that I criticize in your code above, please 
explain why in full detail.

As an interesting aside, I compiled the same test program with a as an 
allocatable(:) array. No compiler complained at compile time, and *only* 
Lahey lf95 threw a runtime error, *if* I compiled with array expression 
shape checking. It looks like ifort and g95 would benefit from the same 
functionality.

Of course, whether the compilers were or were not able to catch the bug 
has essentially no bearing on whether the bug violates the standard or not.

cheers,

Rich
0
rhdt (1081)
8/22/2005 1:06:56 PM
David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
> 
> 
>>and the results of the two compares cannot be .OR.ed to
>>each other.  You would have to do something like the
>>following to fix it:
>>
> 
> 
> The "results of the two compares cannot be .OR.ed to each other"  ?????
> 
> Thats not happening,  when pack sees the first test for a char existing 
> which happens 5x more frequently than the
> OPTIONAL 2nd test involving the previous char,  it immediately packs the 
> char and MOVES ON,
> BECAUSE its a  OR    not  a   AND 

..OR. does not short circuit in Fortran; that is, in the expression "a 
..OR. b" there is no guarantee of order of evaluation, or that the 
evaluation of one operand will be bypassed if the other is .TRUE..

This is pretty elementary stuff. I really am amazed you didn't know this.

cheers,

Rich
0
rhdt (1081)
8/22/2005 1:10:39 PM
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message 
news:decir6$i2n$1@scrotar.nss.udel.edu...
> David Frank wrote:

>> Thats not happening,  when pack sees the first test for a char existing 
>> which happens 5x more frequently than the
>> OPTIONAL 2nd test involving the previous char,  it immediately packs the 
>> char and MOVES ON,
>> BECAUSE its a  OR    not  a   AND
>
> .OR. does not short circuit in Fortran; that is, in the expression "a .OR. 
> b" there is no guarantee of order of evaluation, or that the evaluation of 
> one operand will be bypassed if the other is .TRUE..
>
> This is pretty elementary stuff. I really am amazed you didn't know this.
>

As I am amazed you dont know a optimizing compiler would be left at the gate 
if it evaluated all of a
   multi-clause OR  before deciding that one of the OR conditions had been 
triggered back upstream.






0
dave_frank (2243)
8/22/2005 1:33:05 PM
Bob Lidral wrote in message ...
>robin wrote:
>
>> John W. Kennedy wrote in message ...
>>
>>>William M. Klein wrote:
>>>
>>>>I don't (personally) know of any machine that "executes" either PL/I or
>>
>> Fortran
>>
>>>>statements.  (There may be one or more, but I don't know of any).
>>>
>>>Back in the 60's, Allan-Babcock's RUSH time-sharing service used a
>>>modified 360/50 with a microcode PL/I interpreter. However, it must have
>>>used a preprocessor or significantly non-standard PL/I, as it is
>>>impossible to determine the semantics of a PL/I program in a single pass.
>>
>>
>> The whole language, perhaps, but a single pass compiler was
>> done for a subset on the CDC Cyber.
>>
>>
>Well, yes, but it was never very useful.  In the 1970s, the University
>of Illinois decided to replace their IBM 360 with a more powerful
>machine that would support their existing collection of code.  Several
>departments had whole piles of PL/I, FORTRAN IV, and COBOL code they
>needed to continue to use, and that limited the potential bidders.  As I
>recall, in the end the three remaining bidders were IBM (the U of I was
>willing to consider replacing the 360 with a more powerful 360 -- it
>wasn't that they didn't like the 360, they just needed one with more
>power), Amdahl, and Control Data Corporation.
>
>I heard rumors that the proposed IBM and Amdahl solutions were pretty
>competitive with each other but the CDC solution had a much better
>performance-to-cost ratio.  This is not surprising since the benchmark
>was batch-oriented.
>
>The only problem with the CDC solution was that CDC had no PL/I compiler
>so the U of I wrote that into the contract as a requirement.
>Supposedly, CDC got the contract with the proviso that they deliver a
>working PL/I compiler within some time frame following the delivery of
>the machine.  As I recall, I was there for 2 more years after the CYBER
>was placed into service and never saw the PL/I compiler -- presumably
>CDC never implemented enough of the language to meet the contract
>specifications.  I'm not absolutely certain, since I was never privy to
>any of the financial information, but I suspect the U of I contract may
>have been the only reason CDC agreed to produce a PL/I compiler.
>
>Since I went to work for CDC immediately after leaving the University of
>Illinois, I had occasion to check their product lists a few years later.
>PL/I had been moved to the list of products one could only order if one
>already knew they existed (or worked for CDC and had access to internal
>documents) and which were no longer supported.  I had heard almost
>nothing about the status of the compiler in the interim except that
>friends of mine who knew I worked for CDC kept asking me about it and I
>could tell them almost nothing.  It was removed from all product
>listings a short time later (about 4 years after I left the U of I).
>
>Part of the problem was that most of the people (at least most of those
>I met) from the CDC compiler group absolutely loathed IBM and any
>product even remotely associated with it with an intensity difficult to
>imagine even in today's political climate.  It's probably unfair to
>accuse them of dragging their feet, but I suspect they placed a lower
>priority on PL/I than did their customers.  In any case, I don't recall
>ever hearing of anybody or any shop that used it very much.  Most of the
>complaints I heard was that the subset was way too limited to be of much
>use in supporting existing code.


CDC was never hot on software.
Their COBOL compiler (70 series) produced only a dump
as the sole output when a keyword was used as the program
name.
Their "contract" - if you could call it that - stated that in the event that
the software did not do what the manual stated (i.e., contained
a bug) CDC agreed to change the manual.

However, CDC did produce a brilliant operating system
for their subsequent 8-bit machine.

>Bob Lidral
>lidral at alum dot mit dot edu


0
robin_v (2737)
8/22/2005 1:56:10 PM
On Mon, 22 Aug 2005 11:23:53 GMT, David Frank wrote:

> "Tim Challenger" <tim.challenger@aon.at> wrote in message 
> news:1124709069.7d47947a0368832b424783e50fa2110e@teranews...
>> On Mon, 22 Aug 2005 09:16:00 GMT, David Frank wrote:
>>
>>>
>>> Thats absolutely true and I considered whether there was ANY possibility
>>> that PL/I syntax supported writing a user PACK function and it boggled my
>>> imagination so much I broke out laffing.
>>
>> You really are a twit aren't you?
>>
> 
> Why for truthfully answering your question?

No, but for having such a minimal knowledge of PLI that it had to boggle
your mind.


> Otoh, my question to you
> 
>>> "Do you agree that PL/I cannot duplicate my generic Copy function? "
> 
> was ignored.
> I will add a 2nd question to you,  do you think PL/I syntax supports a 
> user-written PACK function?

Of course.

-- 
Tim C.
0
8/22/2005 1:58:45 PM
"Tim Challenger" <tim.challenger@aon.at> wrote in message 
news:1124718995.52a14545a3741492248e447b9a7f231f@teranews...
>> Otoh, my question to you
>>
>>>> "Do you agree that PL/I cannot duplicate my generic Copy function? "
>>
>> was ignored.
>> I will add a 2nd question to you,  do you think PL/I syntax supports a
>> user-written PACK function?
>
> Of course.
>

You are saying  PL/I supports writing a user function that has dynamic len 
or size output?

Show us a few statements illustrating this.. 


0
dave_frank (2243)
8/22/2005 2:17:04 PM
David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message 
> news:decir6$i2n$1@scrotar.nss.udel.edu...
> 
>>David Frank wrote:
> 
> 
>>>Thats not happening,  when pack sees the first test for a char existing 
>>>which happens 5x more frequently than the
>>>OPTIONAL 2nd test involving the previous char,  it immediately packs the 
>>>char and MOVES ON,
>>>BECAUSE its a  OR    not  a   AND
>>
>>.OR. does not short circuit in Fortran; that is, in the expression "a .OR. 
>>b" there is no guarantee of order of evaluation, or that the evaluation of 
>>one operand will be bypassed if the other is .TRUE..
>>
>>This is pretty elementary stuff. I really am amazed you didn't know this.
>>
> 
> 
> As I am amazed you dont know a optimizing compiler would be left at the gate 
> if it evaluated all of a
>    multi-clause OR  before deciding that one of the OR conditions had been 
> triggered back upstream.

And I'd be flabbergasted that you are so outrageously ignorant of 
Fortran, that you fail to understand that such short circuiting is not 
guaranteed by the standard, and is therefore wholly non-portable. Hell, 
this is one of the topics in Fortran Common Pitfalls; see

http://www.ibiblio.org/pub/languages/fortran/ch1-8.html#12

I see that you've dodged my challenge to compile test_conf using CVF?
Well, I have another challenge. I want your to recode your 3-line blank 
reduction code, but with the order of the operands in the .OR. 
expression reversed. I then want you to recompile with bounds checking 
enabled, and see what happens.

cheers,

Rich
0
rhdt (1081)
8/22/2005 2:28:23 PM
On Mon, 22 Aug 2005 14:17:04 GMT, David Frank wrote:

> "Tim Challenger" <tim.challenger@aon.at> wrote in message 
> news:1124718995.52a14545a3741492248e447b9a7f231f@teranews...
>>> Otoh, my question to you
>>>
>>>>> "Do you agree that PL/I cannot duplicate my generic Copy function? "
>>>
>>> was ignored.
>>> I will add a 2nd question to you,  do you think PL/I syntax supports a
>>> user-written PACK function?
>>
>> Of course.
>>
> 
> You are saying  PL/I supports writing a user function that has dynamic len 
> or size output?
> 
> Show us a few statements illustrating this..

We've been through all this before.
-- 
Tim C.
0
8/22/2005 4:08:31 PM
robin wrote:
> Bob Lidral wrote in message ...
> 
>>robin wrote:
>>> [...]
>>>The whole language, perhaps, but a single pass compiler was
>>>done for a subset on the CDC Cyber.
>>>
>>>
>>
>>Well, yes, but it was never very useful.  In the 1970s, the University
>> [...]
>>the machine.  As I recall, I was there for 2 more years after the CYBER
>>was placed into service and never saw the PL/I compiler -- presumably
>>CDC never implemented enough of the language to meet the contract
>>specifications.  I'm not absolutely certain, since I was never privy to
>>any of the financial information, but I suspect the U of I contract may
>>have been the only reason CDC agreed to produce a PL/I compiler.
>> [...]
> 
> 
> 
> CDC was never hot on software.

Too bad because they had some really fine software people working for
them.  I remember being amazed at some of the NOS internals.  And they
had a standard for writing assembly language that, when followed, made
it easy for programmers to read each other's code, even self-modifying
code (which was almost necessary for PP programming).  But you're right;
no matter how good their software people were -- and they had some
really good people, the company cared a whole lot more about hardware
than about software.

> Their COBOL compiler (70 series) produced only a dump
> as the sole output when a keyword was used as the program
> name.

I remember using that compiler (I don't usually admit even to knowing
how to spell COBOL so forget you saw this paragraph).  It was really
hard to port code between IBM COBOL and CDC COBOL because of the
difference in packed decimal internal representations and the difficulty
CDC's NOS had reading or writing ANSI-standard tapes, especially labeled.

> Their "contract" - if you could call it that - stated that in the event that
> the software did not do what the manual stated (i.e., contained
> a bug) CDC agreed to change the manual.

Wouldn't be surprised. Sounds like too many of the government contracts
I've seen.  :-)

> However, CDC did produce a brilliant operating system
> for their subsequent 8-bit machine.

Regrettably, too late to save them.  I never saw that operating system
because I got too frustrated in the mid-'80s working with late-'60s
technology and left CDC in 1985.  The OS for their 8-bit character,
64-bit word, 2's complement machine must have been good because it kept
them going for another 10 years before finally going bankrupt.

I remember thinking when I left there in 1985 that they finally seemed
to be heading in the right direction with several of their product
lines, having at last learned that incompatibilities with legacy
software that ran on competitors' platforms was not the path to economic
success.  But that was a battle I had fought internally for several
years and I believed they had learned that lesson too late.


Bob Lidral
lidral at alum dot mit dot edu
0
8/22/2005 4:17:38 PM
On Sat, 20 Aug 2005 22:45:51 -0400, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> robin wrote:
>> John W. Kennedy wrote in message ...
>>
>>> William M. Klein wrote:
>>>
>>>> I don't (personally) know of any machine that "executes" either PL/I  
>>>> or
>>  Fortran
>>
>>>> statements.  (There may be one or more, but I don't know of any).
>>>
>>> Back in the 60's, Allan-Babcock's RUSH time-sharing service used a
>>> modified 360/50 with a microcode PL/I interpreter. However, it must  
>>> have
>>> used a preprocessor or significantly non-standard PL/I, as it is
>>> impossible to determine the semantics of a PL/I program in a single  
>>> pass.
>>   The whole language, perhaps, but a single pass compiler was
>> done for a subset on the CDC Cyber.
We supplied the compiler to CDC and it was two pass
>
> The whole language /definitely/, because PL/I (and this is one of  
> several mistakes in the language) allows something to be declared after  
> it is first used. At an absolute minimum, a PL/I interpreter requires a  
> pre-pass to hoist all DECLARE statements (and DEFAULT and DEFINE, in  
> more recent dialects) to the top of their containing blocks, and to  
> insert pseudo-declares of internal LABEL and ENTRY constants.
It would only have been a mistake, had one attempted a single pass  
compiler,
but that is not what was envisioned, enshrined in the ANSI document
>
> (Of course, no-one sane does an interpreter without a pre-pass nowadays,  
> anyway; if only for the sake of translating expressions to RPN or  
> something of the sort.)
>

0
tom284 (1839)
8/22/2005 4:18:50 PM
On Sun, 21 Aug 2005 00:49:38 -0400, Bob Lidral  
<l1dralspamba1t@comcast.net> wrote:

> Since I went to work for CDC immediately after leaving the University of
> Illinois, I had occasion to check their product lists a few years later.
> PL/I had been moved to the list of products one could only order if one
> already knew they existed (or worked for CDC and had access to internal
> documents) and which were no longer supported.  I had heard almost
> nothing about the status of the compiler in the interim except that
> friends of mine who knew I worked for CDC kept asking me about it and I
> could tell them almost nothing.  It was removed from all product  
> listings a short time later (about 4 years after I left the U of I).

There may have been an earlier version of PL/I for the Cyber series, but
we licensed the ANSI compiler to them ca. 1978.  This was necessary for CDC
to get the contract with the Univ of California system,
0
tom284 (1839)
8/22/2005 4:24:45 PM

David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message 
> news:decir6$i2n$1@scrotar.nss.udel.edu...
> 
>>David Frank wrote:
> 
> 
>>>Thats not happening,  when pack sees the first test for a char existing 
>>>which happens 5x more frequently than the
>>>OPTIONAL 2nd test involving the previous char,  it immediately packs the 
>>>char and MOVES ON,
>>>BECAUSE its a  OR    not  a   AND
>>
>>.OR. does not short circuit in Fortran; that is, in the expression "a .OR. 
>>b" there is no guarantee of order of evaluation, or that the evaluation of 
>>one operand will be bypassed if the other is .TRUE..
>>
>>This is pretty elementary stuff. I really am amazed you didn't know this.
>>
> 
> 
> As I am amazed you dont know a optimizing compiler would be left at the gate 
> if it evaluated all of a
>    multi-clause OR  before deciding that one of the OR conditions had been 
> triggered back upstream.
> 
> 
That's really very hardware dependent.  On old Cray-like
machines, jumps are very expensive in clock cycles
(10 or so cycles for the not taken case, more if the jump
is taken and the target is far away) and logical compares
take a cycle or two and multiple compares can be made at the
same time.  If the AND and OR terms are relatively simple,
it's by far the winning strategy to do all of them and then
do one test.  On some machines, short-circuiting is a
DISoptimization, on others, it depends on the context.
Multiple branches that are forward or backward or out
of the loop will have different effects on pipelining.

Dick Hendrickson

0
8/22/2005 4:43:55 PM
In article 
<fhnOe.124084$5N3.116128@bgtnsc05-news.ops.worldnet.att.net>,
 Dick Hendrickson <dick.hendrickson@att.net> wrote:

> On some machines, short-circuiting is a
> DISoptimization, on others, it depends on the context.

And there have existed compilers that short circuited *BACKWARDS*, 
evaluating conditions on the right side first, skipping the left ones 
depending on the results from the right. I'd swear I recalled that in 
some predecessor of DF's current one and only compiler, but I couldn't 
cite particular versions without research.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain
0
nospam47 (9747)
8/22/2005 5:06:06 PM
Bob Lidral wrote:

(snip)

> I remember using that compiler (I don't usually admit even to knowing
> how to spell COBOL so forget you saw this paragraph).  It was really
> hard to port code between IBM COBOL and CDC COBOL because of the
> difference in packed decimal internal representations and the difficulty
> CDC's NOS had reading or writing ANSI-standard tapes, especially labeled.

I remember stories about the difficulty of porting between IBM and
CDC Fortran.  To start, many variables were single precision in CDC
(60 bit) and double for IBM (64 bit).  I believe it got worse from there.

Someday I will try COBOL, but not so far.  I pretty much
haven't used EXCEL yet, either, though I did help someone debug
an EXCEL problem.

-- glen

0
gah (12851)
8/22/2005 5:38:37 PM
"Tim Challenger" <tim.challenger@aon.at> wrote in message 
news:1124726782.6ca45d78f8395a070a441fe338825afa@teranews...
> On Mon, 22 Aug 2005 14:17:04 GMT, David Frank wrote:
>
>> "Tim Challenger" <tim.challenger@aon.at> wrote in message
>> news:1124718995.52a14545a3741492248e447b9a7f231f@teranews...
>>>> Otoh, my question to you
>>>>
>>>>>> "Do you agree that PL/I cannot duplicate my generic Copy function? "
>>>>
>>>> was ignored.
>>>> I will add a 2nd question to you,  do you think PL/I syntax supports a
>>>> user-written PACK function?
>>>
>>> Of course.
>>>
>>
>> You are saying  PL/I supports writing a user function that has dynamic 
>> len
>> or size output?
>>
>> Show us a few statements illustrating this..
>
> We've been through all this before.
> -- 
> Tim C.

Hmmm,  you have a copy of R.Vowels ELIZABOT message generator, RIGHT?

Sooo, refresh my memory, was the bottom line that PL/I syntax supports 
dynamic len, or size for function output?




0
dave_frank (2243)
8/22/2005 6:34:40 PM
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message 
news:decncu$jds$1@scrotar.nss.udel.edu...
> David Frank wrote:
>
> I see that you've dodged my challenge to compile test_conf using CVF?

No point, you ignore my admission that CVF has a bug and choose to browbeat 
me.
My reduce_blanks function has been modified for a(1:len(line)-1)  and 
strings.f90 has been updated with this mod.

> Well, I have another challenge. I want your to recode your 3-line blank 
> reduction code, but with the order of the operands in the .OR. expression 
> reversed.

OK,  I also expanded the line to contain   a b c d e   .....    x y z

My routine (see source posted for Glen Hermannsfeldt)  has identical timings 
swapping  the OR components,
of    1.03 sec vs.  1.06 sec for Giles  OPAQUE mask setting version.

>I then want you to recompile with bounds checking enabled, and see what 
>happens

NO, that requires using the IDE and I am strictly command line user these 
days.
You cant justify your request for bounds checking as THERE IS NO WAY there 
can be a fault.
as I have pointed out elsewhere MORE THAN ONCE.




0
dave_frank (2243)
8/22/2005 6:59:08 PM
David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message 
> news:decncu$jds$1@scrotar.nss.udel.edu...
> 
>>David Frank wrote:
>>
>>I see that you've dodged my challenge to compile test_conf using CVF?
> 
> 
> No point, you ignore my admission that CVF has a bug and choose to browbeat 
> me.

Where is your admission? I can't see it anywhere in these newsgroups.

> My reduce_blanks function has been modified for a(1:len(line)-1)  and 
> strings.f90 has been updated with this mod.
> 
> 
>>Well, I have another challenge. I want your to recode your 3-line blank 
>>reduction code, but with the order of the operands in the .OR. expression 
>>reversed.
> 
> 
> OK,  I also expanded the line to contain   a b c d e   .....    x y z
> 
> My routine (see source posted for Glen Hermannsfeldt)  has identical timings 
> swapping  the OR components,
> of    1.03 sec vs.  1.06 sec for Giles  OPAQUE mask setting version.
> 
> 
>>I then want you to recompile with bounds checking enabled, and see what 
>>happens
> 
> 
> NO, that requires using the IDE and I am strictly command line user these 
> days.

Funny, I have had no problem switching on bounds checking from the 
command line in the following compilers I have used:

Lahey lf95 Express for Linux
g77
g95
Intel ifort for Linux
Compaq f95 for Tru/64
NAG f95 for Linux
Sun f95 for Solaris

Can an independent third party confirm that CVF has no way of enabling 
bounds checking from the command line? Or is DF simply lying?

> You cant justify your request for bounds checking as THERE IS NO WAY there 
> can be a fault.
> as I have pointed out elsewhere MORE THAN ONCE.

Why, then, does the Intel compiler throw the following error:

--
forrtl: severe (408): fort: (2): Subscript #1 of the array A has value 
31 which is greater than the upper bound of 30
--

....when I compile the following code with bounds checking enabled:

--
program test_conf_alloc

character(1), dimension(:), allocatable :: a

allocate(a(30))

a = TRANSFER(' The  quick  brown  fox ', ' ')

print *, a(1:) /= ' ' .OR.  a(2:) /= ' '

end program test_conf_alloc
--

Looks like a bounds violation to me. Hell, I don't even need a compiler 
to tell me that; a(1:) and a(:2) are clearly not conformable. However, I 
would appreciate it if someone could perform the same test using CVF.

cheers,

Rich
0
rhdt (1081)
8/22/2005 7:21:29 PM
"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message 
news:fhnOe.124084$5N3.116128@bgtnsc05-news.ops.worldnet.att.net...
>
>
> That's really very hardware dependent.  On old Cray-like
> machines, jumps are very expensive in clock cycles
> (10 or so cycles for the not taken case, more if the jump
> is taken and the target is far away) and logical compares
> take a cycle or two and multiple compares can be made at the
> same time.  If the AND and OR terms are relatively simple,
> it's by far the winning strategy to do all of them and then
> do one test.  On some machines, short-circuiting is a
> DISoptimization, on others, it depends on the context.
> Multiple branches that are forward or backward or out
> of the loop will have different effects on pipelining.
>
> Dick Hendrickson
>

I usually agree with you, but above dont compute.

CVF (optimize or not) sez its going to make a multi-or  test and JUMP 
immediately after each test.

e.g.   below generated for  SIMPLE logic and the winning strategy is to JUMP
    if (x == 1.or.y ==2 .or. z == 3) stop

stop is the label $0010 in below assy.

 fld dword ptr .bss$+12              ; 000007
 fcomp dword ptr .literal$+12
 mov eax, 0
 fnstsw ax
 test ah, 68
 jpo lab$0010                       <  jump
 fld dword ptr .bss$+4
 fcomp dword ptr .literal$+8
 mov eax, 0
 fnstsw ax
 test ah, 68
 jpo lab$0010                       < jump
 fld dword ptr .bss$+8
 fcomp dword ptr .literal$+4
 mov eax, 0
 fnstsw ax
 test ah, 68
 jpo lab$0010                       < jump

I would bet something similar would happen with ANY compiler.
This supports my intuition a compiler is NOT going to  plow thru all code on 
a OR,
(at least CVF doesnt)..


0
dave_frank (2243)
8/22/2005 7:23:48 PM
David Frank wrote:
> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message 
> news:fhnOe.124084$5N3.116128@bgtnsc05-news.ops.worldnet.att.net...

>>That's really very hardware dependent.  On old Cray-like
>>machines, jumps are very expensive in clock cycles
>>(10 or so cycles for the not taken case, more if the jump
>>is taken and the target is far away) and logical compares
>>take a cycle or two and multiple compares can be made at the
>>same time.  

(snip)

> CVF (optimize or not) sez its going to make a multi-or  test and JUMP 
> immediately after each test.

Newer intel processors have the conditional load instruction
that can be used instead of a branch around a load.  That saves
any delay due to the branch.  Most compilers still don't
generate it to maintain compatibility with older processors.

Branch prediction helps, but isn't perfect.

-- glen

0
gah (12851)
8/22/2005 7:33:26 PM
Tom Linden wrote:
> On Sat, 20 Aug 2005 22:45:51 -0400, John W. Kennedy  
> <jwkenne@attglobal.net> wrote:
> 
>> robin wrote:
>>
>>> John W. Kennedy wrote in message ...
>>>
>>>> William M. Klein wrote:
>>>>
>>>>> I don't (personally) know of any machine that "executes" either 
>>>>> PL/I  or
>>>
>>>  Fortran
>>>
>>>>> statements.  (There may be one or more, but I don't know of any).
>>>>
>>>>
>>>> Back in the 60's, Allan-Babcock's RUSH time-sharing service used a
>>>> modified 360/50 with a microcode PL/I interpreter. However, it must  
>>>> have
>>>> used a preprocessor or significantly non-standard PL/I, as it is
>>>> impossible to determine the semantics of a PL/I program in a single  
>>>> pass.
>>>
>>>   The whole language, perhaps, but a single pass compiler was
>>> done for a subset on the CDC Cyber.
> 
> We supplied the compiler to CDC and it was two pass
> 
>>
>> The whole language /definitely/, because PL/I (and this is one of  
>> several mistakes in the language) allows something to be declared 
>> after  it is first used. At an absolute minimum, a PL/I interpreter 
>> requires a  pre-pass to hoist all DECLARE statements (and DEFAULT and 
>> DEFINE, in  more recent dialects) to the top of their containing 
>> blocks, and to  insert pseudo-declares of internal LABEL and ENTRY 
>> constants.
> 
> It would only have been a mistake, had one attempted a single pass  
> compiler,
> but that is not what was envisioned, enshrined in the ANSI document

ANSI PL/I is ex-post-facto, anyway, and allowing declaration after use 
is just plain bad design, not only from the viewpoint of compiler 
writers, but from the viewpoint of human users, and it's one of several 
faults in the design of PL/I occasioned by the notion that everything 
that wasn't a syntax error and that /might/ have an interpretation, 
/should/ have an interpretation. It is obvious how that attitude came 
about, considering the many arbitrary restrictions in FORTRAN and 
FORTRAN II -- I felt the same way myself in 1965 -- but it was a bad 
philosophy that led to a number of flaws in the language.


-- 
John W. Kennedy
"Information is light. Information, in itself, about anything, is light."
   -- Tom Stoppard. "Night and Day"
0
jwkenne (1442)
8/22/2005 7:45:40 PM
David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
>
>> and the results of the two compares cannot be .OR.ed to
>> each other.  You would have to do something like the
>> following to fix it:
>>
>
> The "results of the two compares cannot be .OR.ed to each other"
> ?????
>
> Thats not happening,  when pack sees the first test for a char
> existing which happens 5x more frequently than the
> OPTIONAL 2nd test involving the previous char

Bullshit.  .OR. in Fortran is commutative.  The compiler is
free to reference in either order.  And shortcutting is often
slower than just doing the operations straight through (jumps
cost too).  Unless you have direct evidence that a compiler
actually *does* shortcutting, you're talking through your ---.

And, that's still not relevant to the point I made: THE EXPRESSION
IS ILLEGAL!!!!!!!

(By the way, I looked at the assembly code generated by
DF's procedure.  Using CVF6.6c from the command line with
no options. It does *NOT* short-circuit the OR.  It unrolls
the loop five times and does some other creative stuff, but
no short-circuiting.  It definitely compares each element of
the input string to blank *twice* (except the first and last).)

> ,  it immediately
> packs the char and MOVES ON,
> BECAUSE its a  OR    not  a   AND

AND vs. OR is irrelevant since the compiler knows DeMorgan's
rules just as well as I do.  Though, apparently you don't.  If there's
anything to gain by short-circuiting the OR, then AND could also
be shortcircuited under the same conditions.  What would you now
be irrelevantly complaining about if I'd used OR?

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare


0
jamesgiles (2210)
8/22/2005 8:05:54 PM
"James Giles" <jamesgiles@worldnet.att.net> wrote in message 
news:CeqOe.654652$cg1.157674@bgtnsc04-news.ops.worldnet.att.net...
> David Frank wrote:
>> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
>> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
>>
> Unless you have direct evidence that a compiler
> actually *does* shortcutting, you're talking through your ---.

see: my reply to Dick Hendrickson


0
dave_frank (2243)
8/22/2005 9:35:45 PM
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:ded8jo$o9d$1@scrotar.nss.udel.edu...

> Can an independent third party confirm that CVF has no way of enabling
> bounds checking from the command line? Or is DF simply lying?

C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>type
bounds_1.f90
program test_conf_alloc

character(1), dimension(:), allocatable :: a

allocate(a(30))

a = TRANSFER(' The  quick  brown  fox ', ' ')

print *, a(1:) /= ' ' .OR.  a(2:) /= ' '

end program test_conf_alloc

C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>df /check:bounds
/tr
aceback bounds_1
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
Copyright 2003 Compaq Computer Corp. All rights reserved.

bounds_1
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/subsystem:console
/entry:mainCRTStartup
/debugtype:cv
/pdb:none
C:\DOCUME~1\James\LOCALS~1\Temp\obj1A.tmp
dfor.lib
libc.lib
dfconsol.lib
dfport.lib
kernel32.lib
/out:bounds_1.exe
/incremental:no

C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>bounds_1
forrtl: severe (161): Program Exception - array bounds exceeded
Image              PC        Routine            Line        Source
bounds_1.exe       00401454  TEST_CONF_ALLOC             9  bounds_1.F90
bounds_1.exe       00426A49  Unknown               Unknown  Unknown
bounds_1.exe       0041DD84  Unknown               Unknown  Unknown
KERNEL32.dll       7C59893D  Unknown               Unknown  Unknown

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


0
not_valid (1693)
8/22/2005 9:37:41 PM
"David Frank" <dave_frank@hotmail.com> wrote in message
news:8DpOe.271$_84.4@newsread1.news.atl.earthlink.net...

> CVF (optimize or not) sez its going to make a multi-or  test and JUMP
> immediately after each test.

A:\>type *.*

cmov_1.asm


        .set noat
        .set noreorder
        .data
        .align 0
        .lcomm  .T4_ 1
        .lcomm  fill$$1 7
        .lcomm  I 4
        .lcomm  .T2_ 4
        .rdata
        .align 0
$$1:
        .long   0x3F800000 # .float 1.000000
        .long   0x40A00000 # .float 5.000000
        .byte   0 : 8
        .section .drectve$1 ".drectve" LNK_INFO LNK_REMOVE
$$2:
        .ascii  "-defaultlib:dfor.lib "

        .ascii  "-defaultlib:libc.lib "

        .ascii  "-defaultlib:dfconsol.lib "

        .ascii  "-defaultlib:dfport.lib "

        .ascii  "-defaultlib:kernel32.lib "

        .byte   0 : 13
        .text
        .arch   ev56
        .align 4
        .file 1 "H:\program files\Microsoft Visual
Studio\James\cmov_1\cmov_1.f90"
        .loc 1 1
 #      1 function cmov_1(x,n)
        .globl  CMOV_1
        .ent    CMOV_1
        .eflag 1
        .loc 1 1
CMOV_1:
        .loc 1 11
 #      2    implicit none
 #      3    integer, intent(in) :: n
 #      4    real, intent(in) :: x(n)
 #      5    integer cmov_1
 #      6    integer i
 #      7    real y
 #      8    real next_y
 #      9
 #     10    y = 0
 #     11    do i = 1, n
        ldl     $17, ($17)
                                           # 000011
        .loc 1 1
        lda     $sp, -16($sp)
                                           # 000001
        .frame  $sp, 16, $26
        .prologue 0
        .loc 1 10
        fclr    $f0
                                           # 000010
        unop
        .loc 1 13
 #     12       next_y = y+1
 #     13       if(x(i) > 5) y = next_y
        ldah    $28, $$1($31)!refhi!1
                                           # 000013
        .loc 1 11
        clr     $1
                                           # 000011
        ble     $17, lab$0006
        cmovle  $17, 1, $17
        .loc 1 13
        lds     $f1, $$1+4($28)!reflo!1
                                           # 000013
        .loc 1 12
        ldah    $28, $$1($31)!refhi!2
                                           # 000012
        lds     $f10, $$1($28)!reflo!2
        .loc 1 11
        mov     $17, $2
                                           # 000011
        cmple   $17, 3, $3
        bne     $3, L$11
        .loc 1 13
        ldl     $31, 140($16)
                                           # 000013
        .loc 1 11
        lda     $2, -4($17)
                                           # 000011
        cmple   $2, 3, $5
        .loc 1 14
 #     14    end do
        bne     $5, L$6
                                           # 000014
        .loc 1 11
L$8:
                                           # 000011
        unop
        unop
        unop
        unop
        .loc 1 13
        lds     $f11, ($16)
                                           # 000013
        cmptle  $f11, $f1, $f11
        .loc 1 12
        adds    $f0, $f10, $f12
                                           # 000012
        .loc 1 13
        lds     $f13, 4($16)
                                           # 000013
        cmptle  $f13, $f1, $f13
        unop
        fcmoveq $f11, $f12, $f0
        lds     $f15, 8($16)
        cmptle  $f15, $f1, $f15
        .loc 1 12
        adds    $f0, $f10, $f14
                                           # 000012
        .loc 1 13
        lds     $f17, 12($16)
                                           # 000013
        cmptle  $f17, $f1, $f17
        fcmoveq $f13, $f14, $f0
        .loc 1 12
        adds    $f0, $f10, $f16
                                           # 000012
        .loc 1 13
        ldl     $31, 156($16)
                                           # 000013
        .loc 1 11
        lda     $2, -4($2)
                                           # 000011
        lda     $1, 4($1)
        .loc 1 13
        lda     $16, 16($16)
                                           # 000013
        .loc 1 11
        cmple   $2, 3, $20
                                           # 000011
        .loc 1 13
        fcmoveq $f15, $f16, $f0
                                           # 000013
        .loc 1 12
        adds    $f0, $f10, $f18
                                           # 000012
        unop
        .loc 1 13
        fcmoveq $f17, $f18, $f0
                                           # 000013
        .loc 1 14
        beq     $20, L$8
                                           # 000014
        .loc 1 11
L$6:
                                           # 000011
        .loc 1 13
        lds     $f19, ($16)
                                           # 000013
        unop
        lds     $f21, 4($16)
        lds     $f23, 8($16)
        unop
        unop
        cmptle  $f19, $f1, $f19
        lds     $f25, 12($16)
        .loc 1 11
        lda     $1, 4($1)
                                           # 000011
        unop
        .loc 1 13
        cmptle  $f21, $f1, $f21
                                           # 000013
        .loc 1 11
        lda     $16, 16($16)
                                           # 000011
        .loc 1 12
        adds    $f0, $f10, $f20
                                           # 000012
        .loc 1 13
        cmptle  $f23, $f1, $f23
                                           # 000013
        cmptle  $f25, $f1, $f25
        fcmoveq $f19, $f20, $f0
        .loc 1 12
        adds    $f0, $f10, $f22
                                           # 000012
        .loc 1 13
        fcmoveq $f21, $f22, $f0
                                           # 000013
        .loc 1 12
        adds    $f0, $f10, $f24
                                           # 000012
        .loc 1 13
        fcmoveq $f23, $f24, $f0
                                           # 000013
        .loc 1 12
        adds    $f0, $f10, $f26
                                           # 000012
        unop
        .loc 1 13
        fcmoveq $f25, $f26, $f0
                                           # 000013
        .loc 1 11
        ble     $2, lab$0006
                                           # 000011
        unop
        unop
L$11:
        .loc 1 13
        unop
        unop
        unop
        unop
        lds     $f27, ($16)
        .loc 1 12
        adds    $f0, $f10, $f28
                                           # 000012
        .loc 1 11
        lda     $2, -1($2)
                                           # 000011
        unop
        lda     $1, 1($1)
        lda     $16, 4($16)
        .loc 1 13
        cmptle  $f27, $f1, $f27
                                           # 000013
        unop
        fcmoveq $f27, $f28, $f0
        .loc 1 11
        bgt     $2, L$11
                                           # 000011
        .loc 1 14
lab$0006:
                                           # 000014
        .loc 1 15
 #     15    cmov_1 = y
        cvttqc  $f0, $f0
                                           # 000015
        stt     $f0, ($sp)
        xor     $sp, $31, $sp
        ldl     $0, ($sp)
        .loc 1 1
        .loc 1 16
 #     16 end function cmov_1
        lda     $sp, 16($sp)
                                           # 000016
        ret     ($26)
        .loc 1 1
        .end    CMOV_1

cmov_1.f90


function cmov_1(x,n)
   implicit none
   integer, intent(in) :: n
   real, intent(in) :: x(n)
   integer cmov_1
   integer i
   real y
   real next_y

   y = 0
   do i = 1, n
      next_y = y+1
      if(x(i) > 5) y = next_y
   end do
   cmov_1 = y
end function cmov_1

I call the reader's attention to the cmptle/fcmoveq combinations
that CVF6.5A assembles to handle the IF statement in the loop.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


0
not_valid (1693)
8/22/2005 10:02:40 PM
James Van Buskirk wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:ded8jo$o9d$1@scrotar.nss.udel.edu...
> 
> 
>>Can an independent third party confirm that CVF has no way of enabling
>>bounds checking from the command line? Or is DF simply lying?
> 
> 
> C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>type
> bounds_1.f90
> program test_conf_alloc
> 
> character(1), dimension(:), allocatable :: a
> 
> allocate(a(30))
> 
> a = TRANSFER(' The  quick  brown  fox ', ' ')
> 
> print *, a(1:) /= ' ' .OR.  a(2:) /= ' '
> 
> end program test_conf_alloc
> 
> C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>df /check:bounds
> /tr
> aceback bounds_1
> Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
> Copyright 2003 Compaq Computer Corp. All rights reserved.
> 
> bounds_1
> Microsoft (R) Incremental Linker Version 6.00.8447
> Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
> 
> /subsystem:console
> /entry:mainCRTStartup
> /debugtype:cv
> /pdb:none
> C:\DOCUME~1\James\LOCALS~1\Temp\obj1A.tmp
> dfor.lib
> libc.lib
> dfconsol.lib
> dfport.lib
> kernel32.lib
> /out:bounds_1.exe
> /incremental:no
> 
> C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>bounds_1
> forrtl: severe (161): Program Exception - array bounds exceeded
> Image              PC        Routine            Line        Source
> bounds_1.exe       00401454  TEST_CONF_ALLOC             9  bounds_1.F90
> bounds_1.exe       00426A49  Unknown               Unknown  Unknown
> bounds_1.exe       0041DD84  Unknown               Unknown  Unknown
> KERNEL32.dll       7C59893D  Unknown               Unknown  Unknown
> 

Thanks, James.

So it appears that DF was just bullshitting. Since he can't conduct an 
argument without resorting to falsehood, I see little point in debating 
him further.

cheers

Rich
0
rhdt (1081)
8/22/2005 10:19:52 PM
David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:CeqOe.654652$cg1.157674@bgtnsc04-news.ops.worldnet.att.net...
>> David Frank wrote:
>>> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
>>> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
>>>
>> Unless you have direct evidence that a compiler
>> actually *does* shortcutting, you're talking through your ---.
>
> see: my reply to Dick Hendrickson

I saw that.  It's in *direct* contradiction to the actual
documentation distributed with CVF:

   You should not write logical expressions whose results
   might depend on the evaluation order of subexpressions.
   The compiler is free to evaluate subexpressions in any
   order.

and

   Some subexpressions might not be evaluated if the compiler
   can determine the result by testing other subexpressions in
   the logical expression. Consider the following expression:

        A .AND. (F(X,Y) .GT. 2.0) .AND. B

   If the compiler evaluates A first, and A is false, the compiler
   might determine that the expression is false and might not call
   the subprogram F(X,Y).

Note the ifs and mights in the later.  There is no guarantee
that operands will be evaluated left to right or that short-circuiting
will occur.  In you code, as specifically and directly examined,
the compiler does not.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare


0
jamesgiles (2210)
8/22/2005 10:37:54 PM

David Frank wrote:
> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message 
> news:fhnOe.124084$5N3.116128@bgtnsc05-news.ops.worldnet.att.net...
> 
>>
>>That's really very hardware dependent.  On old Cray-like
>>machines, jumps are very expensive in clock cycles
>>(10 or so cycles for the not taken case, more if the jump
>>is taken and the target is far away) and logical compares
>>take a cycle or two and multiple compares can be made at the
>>same time.  If the AND and OR terms are relatively simple,
>>it's by far the winning strategy to do all of them and then
>>do one test.  On some machines, short-circuiting is a
>>DISoptimization, on others, it depends on the context.
>>Multiple branches that are forward or backward or out
>>of the loop will have different effects on pipelining.
>>
>>Dick Hendrickson
>>
> 
> 
> I usually agree with you, but above dont compute.
> 
Usually?????

> CVF (optimize or not) sez its going to make a multi-or  test and JUMP 
> immediately after each test.
> 
> e.g.   below generated for  SIMPLE logic and the winning strategy is to JUMP
>     if (x == 1.or.y ==2 .or. z == 3) stop
> 

That's fine, I said it's hardware dependent and you've
shown one hardware's way to do it.  The fact is that
on the Crays in the 70s and 80s the absolute best way to
do that case was
1     load,s1    x
2     load,s2    y
3     load,s3    z
4     set,s4     1
5     set,s5     2
6     set,s6     3
7     s1   =     s1?s4       I forget the syntax, test x==1
8     s2   =     s2?s5       y==2
9     s2   =     s2?s1       y==2 .or. x==1
10    s3   =     s3?46       z==3
11    s0   =     s2?s3       z==3 .or. y==2 .or. x==1
12    jsz        whatever

The three load instructions execute in parallel, the 3 set
of registers to constants happen in parallel with the loads
and in effect take 0 clock cycles.
variable x is in s1 at about clock period 16 (depends on
the model of the Cray in question) so instruction labeled
7 issues at clock period 16, instruction 8 issues at clock
period 18 (because the load instructions take 2 cp to issue)
instruction 9 issues at clock period 19 (logical
instructions on all Cray's were da*m fast).  Instruction 10
issues at clock period 20, instruction 11 issues at cp 21.
the jump makes it's decision at about cp 25 (takes a while
for the logical result to get to the jump decision box).

If instead you do it as
1     load,s1    x
2     set,s2     1
3     s0     =   s1?s2
4     jsz        whatever

instruction 3 issues at clock period 16, instruction 3
at cp 17 and instruction 4 makes it's decision at cp 21.
In other words, NOT short-circuiting 3 decisions takes
4 more cp's that a simple one expression test and is about
50 clock periods shorter than three serial test-jump
sequences.

If you want to tell me the INTEL whatever is different
from the Cray's, I'll believe you.  But, that is exactly my
point.  It's hardware dependent.  Each time Intel makes a
new chip, Steve orders someone to read the hardware manual
and then they bugger up the code generator.  It's hardware
dependent.

Try replacing your simple line with
      if(x(i) == 1 .or. y(i) ==2 .or. z(i)==3) stop
and put the line in a DO loop.  Then, put it in a loop
where x, y, and z are calculated by some non-trivial
calculation (so that the compiler can't decide if x(i) == 1
at compile time).  And then try them at different
optimizaion levels, including "brain-dead" and "turbo".
At least one of us will be surprised at the results ;).

Dick Hendrickson

0
8/23/2005 12:11:37 AM
Dick Hendrickson wrote:
> 
> 
> David Frank wrote:
> 
>> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message 
>> news:fhnOe.124084$5N3.116128@bgtnsc05-news.ops.worldnet.att.net...
>>
>>>
>>> That's really very hardware dependent.  On old Cray-like
>>> machines, jumps are very expensive in clock cycles
>>> (10 or so cycles for the not taken case, more if the jump
>>> is taken and the target is far away) and logical compares
>>> take a cycle or two and multiple compares can be made at the
>>> same time.  If the AND and OR terms are relatively simple,
>>> it's by far the winning strategy to do all of them and then
>>> do one test.  On some machines, short-circuiting is a
>>> DISoptimization, on others, it depends on the context.
>>> Multiple branches that are forward or backward or out
>>> of the loop will have different effects on pipelining.
>>>
>>> Dick Hendrickson
>>>
>>
>>
>> I usually agree with you, but above dont compute.
>>
> Usually?????
> 
>> CVF (optimize or not) sez its going to make a multi-or  test and JUMP 
>> immediately after each test.
>>
>> e.g.   below generated for  SIMPLE logic and the winning strategy is 
>> to JUMP
>>     if (x == 1.or.y ==2 .or. z == 3) stop
>>
> 
> That's fine, I said it's hardware dependent and you've
> shown one hardware's way to do it.  The fact is that
> on the Crays in the 70s and 80s the absolute best way to
> do that case was
> 1     load,s1    x
> 2     load,s2    y
> 3     load,s3    z
> 4     set,s4     1
> 5     set,s5     2
> 6     set,s6     3
> 7     s1   =     s1?s4       I forget the syntax, test x==1
> 8     s2   =     s2?s5       y==2
> 9     s2   =     s2?s1       y==2 .or. x==1
> 10    s3   =     s3?46       z==3
> 11    s0   =     s2?s3       z==3 .or. y==2 .or. x==1
> 12    jsz        whatever
> 
> The three load instructions execute in parallel, the 3 set
> of registers to constants happen in parallel with the loads
> and in effect take 0 clock cycles.
> variable x is in s1 at about clock period 16 (depends on
> the model of the Cray in question) so instruction labeled
> 7 issues at clock period 16, instruction 8 issues at clock
> period 18 (because the load instructions take 2 cp to issue)
> instruction 9 issues at clock period 19 (logical
> instructions on all Cray's were da*m fast).  Instruction 10
> issues at clock period 20, instruction 11 issues at cp 21.
> the jump makes it's decision at about cp 25 (takes a while
> for the logical result to get to the jump decision box).
> 
> If instead you do it as
> 1     load,s1    x
> 2     set,s2     1
> 3     s0     =   s1?s2
> 4     jsz        whatever
> 
> instruction 3 issues at clock period 16, instruction 3
> at cp 17 and instruction 4 makes it's decision at cp 21.
> In other words, NOT short-circuiting 3 decisions takes
> 4 more cp's that a simple one expression test and is about
> 50 clock periods shorter than three serial test-jump
> sequences.
> 
> If you want to tell me the INTEL whatever is different
> from the Cray's, I'll believe you.  But, that is exactly my
> point.  It's hardware dependent.  Each time Intel makes a
> new chip, Steve orders someone to read the hardware manual
> and then they bugger up the code generator.  It's hardware
> dependent.
> 
> Try replacing your simple line with
>      if(x(i) == 1 .or. y(i) ==2 .or. z(i)==3) stop
> and put the line in a DO loop.  

To be faithful to the original example, you would have to make sure that 
x, y and z don't have the same declared dimensions.

Then, put it in a loop
> where x, y, and z are calculated by some non-trivial
> calculation (so that the compiler can't decide if x(i) == 1
> at compile time).  And then try them at different
> optimizaion levels, including "brain-dead" and "turbo".
> At least one of us will be surprised at the results ;).
> 
> Dick Hendrickson
> 
0
rhdt (1081)
8/23/2005 12:32:18 AM
David Frank wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:pt1Oe.6470$FA3.4172@news-server.bigpond.net.au...
>>
>>>
>>>My current solution that meets these revised specs, uses 3 statements:
>>>
>>>pad = char(0)      ! allow pack to use null chars to pad its output
>>>a = Copy(line)     ! copy line to char array
>>>outline = line(1:1)  //  Copy( PACK(a(2:), a(2:)/=' '.or.a(1:)/=' ',pad) )
>>
>> I think that this will do it in PL/I :-
>>
>> line = pack (a, (a^=' ') | (b ^= ' '), rank(0) );
>
>I think NOT
>Did you forget you cross-posted and are being read by REAL programmers here
>in comp.lang.fortran?

>Arent you embarrassed to post fictitious PL/I syntax?

It is not "ficticious".  It is real PL/I code, but we have seen
that yours isn't, being buggy.

>1. There is no PL/I pack function


Since your code uses your  own COPY function,
you will admit user-written PACK function.

>2. you cant write a COPY string into an array function as PL/I doesnt
>support dynamic function output determined
>    by input size or length, so much for any possibility you can write a
>generic Copy function.



>3. You dont have a magical TRANSFER function to substitute,  you gots lotsa
problems


Don't need one.  In PL/I, the DEFINED attribute handles that.

> besides no pack

I wrote one a long while back.

>4. what is "b" supposed to be?


"b" is referred to the array "a" (see below).

>As usual you never show your statements actually work in a test program

dcl line char (*);
dcl outline char(length(line)) varz;
dcl a(length(s)) char(1) def line pos(1), b(length(s)) char(1) def a(min(1sub+1,
length(s)));



0
robin_v (2737)
8/23/2005 2:07:14 AM
David Frank wrote in message ...
>
>"Tim Challenger" <tim.challenger@aon.at> wrote in message
>news:1124699765.17b90c8dbed03e32764504cabd3dc93d@teranews...
>> On Sun, 21 Aug 2005 16:41:43 GMT, David Frank wrote:
>>
>>>> I think that this will do it in PL/I :-
>>>>
>>>> line = pack (a, (a^=' ') | (b ^= ' '), rank(0) );
>>>>
>>>
>>> I think NOT
>>> Did you forget you cross-posted and are being read by REAL programmers
>>> here
>>> in comp.lang.fortran?
>>>
>>> Arent you embarrassed to post fictitious PL/I syntax?
>>
>> The syntax is valid PLI.
>>
>>> 1. There is no PL/I pack function
>>
>> But PACK could be a user-function. Which you yourself said is allowed.
>
>Thats absolutely true and I considered whether there was ANY possibility
>that PL/I syntax supported writing a user PACK function and it boggled my
>imagination so much I broke out laffing.



>Otoh,  my generic Copy function WAS written and can be viewed:
>       http://home.earthlink.net/~dave_gemini/strings.f90


Your Copy function is NOT generic.

-INTERFACE Copy
-   MODULE PROCEDURE copy_a2s, copy_s2a
-END INTERFACE Copy
-CONTAINS
-! ------------------------
-FUNCTION Copy_a2s(a)  RESULT (s)    ! copy char array to string
-CHARACTER :: a(:)
-CHARACTER(SIZE(a)) :: s
-INTEGER :: i
-DO i = 1,SIZE(a)
-   s(i:i) = a(i)
-END DO
-END FUNCTION Copy_a2s
-! ------------------------
-FUNCTION Copy_s2a(s)  RESULT (a)   ! copy string to char array
-CHARACTER(*) :: s
-CHARACTER :: a(LEN(s))
-INTEGER :: i
-DO i = 1,LEN(s)
-   a(i) = s(i:i)
-END DO
-END FUNCTION Copy_s2a


>and its use demo'ed in the reduce_blanks benchmark
>
>     http://home.earthlink.net/~dave_gemini/reduce.f90
>
>Do you agree that PL/I cannot duplicate my generic Copy function?

PL/I does not need one.

As well as the DEFINED attribute for this type of thing,
PL/I supports the STRING function (should an assignment be
appropriate).




0
robin_v (2737)
8/23/2005 2:07:15 AM
Tom Linden wrote in message ...
>On Sat, 20 Aug 2005 22:45:51 -0400, John W. Kennedy
><jwkenne@attglobal.net> wrote:
>
>> robin wrote:
>>> John W. Kennedy wrote in message ...
>>>
>>>> William M. Klein wrote:
>>>>
>>>>> I don't (personally) know of any machine that "executes" either PL/I
>>>>> or
>>>  Fortran
>>>
>>>>> statements.  (There may be one or more, but I don't know of any).
>>>>
>>>> Back in the 60's, Allan-Babcock's RUSH time-sharing service used a
>>>> modified 360/50 with a microcode PL/I interpreter. However, it must
>>>> have
>>>> used a preprocessor or significantly non-standard PL/I, as it is
>>>> impossible to determine the semantics of a PL/I program in a single
>>>> pass.
>>>   The whole language, perhaps, but a single pass compiler was
>>> done for a subset on the CDC Cyber.
>We supplied the compiler to CDC and it was two pass


I wasn't referrihg to the CDC compiler.


0
robin_v (2737)
8/23/2005 2:07:16 AM
Bob Lidral wrote in message ...
>The OS for their 8-bit character,
>64-bit word, 2's complement machine must have been good

NOS/VE ?  Brilliant.

>Bob Lidral


0
robin_v (2737)
8/23/2005 2:07:16 AM
David Frank wrote in message
<2KWNe.9300$ns.4466@newsread1.news.atl.earthlink.net>...

>In any case, your next message (also cross-posted BY YOU  from
>comp.lang.pl1)  shows my insightful 2char test

"insightful" ?   You do mean your illegal Fortran code below?

> (that Giles and everyone
>overlooked and is source of his pique)  adapts to array syntax and is
>imbedded into
>
>    outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR. a(1:) /= ' ',
pad) )


0
robin_v (2737)
8/23/2005 2:07:17 AM
James J. Weinkam wrote in message ...
>robin wrote:
>> David Frank wrote in message ...
>>
>>>Since its obvious there is NO PL/I solution to translate my 1-line
>>>Count_Items challenge via a single scan thru
>>>the input line,
>>
>>
>> get string(trim(line)) list ((v do COUNT = 1 to length(line));
>>
>This won't work as you intend.  Even after you fix the missing parenthesis
>error, the statement will raise the ERROR condition and the value of COUNT at
>that point will be one too large.

ON ERROR PUT (COUNT);

is required to display the result.


0
robin_v (2737)
8/23/2005 2:07:18 AM
David Frank wrote in message
<0gpOe.134$9i4.16@newsread2.news.atl.earthlink.net>...
>
>"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
>news:decncu$jds$1@scrotar.nss.udel.edu...
>> David Frank wrote:
>>
>> I see that you've dodged my challenge to compile test_conf using CVF?
>
>No point, you ignore my admission that CVF has a bug

First you said that you couldn't enable subscript checking;
now you say the coompiler has a bug.
Whjat are we to believe?

The reality  is that you code is in error.

>You cant justify your request for bounds checking as THERE IS NO WAY there
>can be a fault.
>as I have pointed out elsewhere MORE THAN ONCE.


Your code is FAULTY.


0
robin_v (2737)
8/23/2005 2:07:18 AM
David Frank wrote in message ...
>
>"Tim Challenger" <tim.challenger@aon.at> wrote in message
>news:1124709069.7d47947a0368832b424783e50fa2110e@teranews...
>> On Mon, 22 Aug 2005 09:16:00 GMT, David Frank wrote:
>>
>>> Thats absolutely true and I considered whether there was ANY possibility
>>> that PL/I syntax supported writing a user PACK function and it boggled my
>>> imagination so much I broke out laffing.
>>
>> You really are a twit aren't you?

>Why for truthfully answering your question?
>Otoh, my question to you
>
>>> "Do you agree that PL/I cannot duplicate my generic Copy function? "

You have NOT written a generic COPY function,
as your  own code PROVES.

>was ignored.
>I will add a 2nd question to you,  do you think PL/I syntax supports a
>user-written PACK function?


Not only does PL/I support a user-written PACK function,
it supports a user-written GENERIC PACK function.

AND a generic COPY function.


0
robin_v (2737)
8/23/2005 2:07:19 AM
Tim Challenger wrote in message
<1124718995.52a14545a3741492248e447b9a7f231f@teranews>...
>On Mon, 22 Aug 2005 11:23:53 GMT, David Frank wrote:
>
>> "Tim Challenger" <tim.challenger@aon.at> wrote in message
>> news:1124709069.7d47947a0368832b424783e50fa2110e@teranews...
>>> On Mon, 22 Aug 2005 09:16:00 GMT, David Frank wrote:
>>>
>>>>
>>>> Thats absolutely true and I considered whether there was ANY possibility
>>>> that PL/I syntax supported writing a user PACK function and it boggled my
>>>> imagination so much I broke out laffing.
>>>
>>> You really are a twit aren't you?
>
>> Why for truthfully answering your question?
>
>No, but for having such a minimal knowledge of PLI

And also of Fortran that it boggles the mind.
He has a current long-running argument that his patently faulty Fortran
array code was not buggy.


0
robin_v (2737)
8/23/2005 2:07:20 AM
glen herrmannsfeldt wrote in message <57CdnaTewo2W95TeRVn-gg@comcast.com>...
>David Frank wrote:
>(snip)
>
>> My current solution that meets these revised specs, uses 3 statements:
>>
>> pad = char(0)      ! allow pack to use null chars to pad its output
>> a = Copy(line)     ! copy line to char array
>> outline = line(1:1)  //  Copy( PACK(a(2:), a(2:)/=' '.or.a(1:)/=' ',pad) )
>
>There was, somewhere in this discussion the question about how
>many passes through the array different solutions make.
>
>Would someone like to tell me how many passes through the
>array this one makes?

Absolutely NONE, because this code has an array bounds error
(incompatible arrays).


0
robin_v (2737)
8/23/2005 2:07:20 AM
David Frank wrote in message ...
>
>"James Giles" <jamesgiles@worldnet.att.net> wrote in message
>news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...


>>>     outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR. a(1:) /= '
', pad) )

>> and the results of the two compares cannot be .OR.ed to
>> each other.  You would have to do something like the
>> following to fix it:
>>
>The "results of the two compares cannot be .OR.ed to each other"  ?????
>
>Thats not happening,

But it IS happening.
What happens when the two intermediate arrays are ORed?
With what is the last element of the intermediate array    a(1:) /= ' '
to be ORed?

> when pack sees the first test for a char existing
>which happens 5x more frequently than the
>OPTIONAL 2nd test involving the previous char,  it immediately packs the
>char and MOVES ON,
>BECAUSE its a  OR    not  a   AND

And with what is the last result of the intermediate array
a(1:) /= ' ',
to be used?

You also have a strange idea of the order in which the
intermediate results are performed.

In all probabability the PACK operation does not commence
until AFTER the intermediate arrays have been computed
and those results ORed.


0
robin_v (2737)
8/23/2005 5:35:42 AM
"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message 
news:ZQtOe.655702$cg1.334601@bgtnsc04-news.ops.worldnet.att.net...
>
> >

< snip >  Nice  example from the parallel processing world
I guess the logic doing it that way is "we gotta keep these parallel 
processing units busy"

> Try replacing your simple line with
>      if(x(i) == 1 .or. y(i) ==2 .or. z(i)==3) stop
> and put the line in a DO loop.  Then, put it in a loop
> where x, y, and z are calculated by some non-trivial
> calculation (so that the compiler can't decide if x(i) == 1
> at compile time).  And then try them at different
> optimizaion levels, including "brain-dead" and "turbo".
> At least one of us will be surprised at the results ;).
>

I am not surprised at results below...

program or_jump
real ::  x(3,2)
do n = 1,2
   call random_number(x)
   if (x(1,n) == 1 .or. x(2,n) == 2 .or. x(3,n) == 3) stop
end do
end program

pertinent excerpts with blank line(s) inserted for identification

fld dword ptr [ecx]               ; 000008
fcomp dword ptr .literal$+12
fnstsw ax
test ah, 68
jpo lab$0017

mov eax, 0
fld dword ptr -8[ebx]
fcomp dword ptr .literal$+8
fnstsw ax
test ah, 68
jpo lab$0017

mov esi, dword ptr -8[ebp]
mov eax, 0
fld dword ptr -4[esi]
fcomp dword ptr .literal$+4
fnstsw ax
test ah, 68
jpo lab$0017


0
dave_frank (2243)
8/23/2005 5:44:46 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:OAyOe.7795$FA3.2986@news-server.bigpond.net.au...
> David Frank wrote in message ...
>>
>>"James Giles" <jamesgiles@worldnet.att.net> wrote in message
>>news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
>
>
>>>>     outline = line(1:1) // Copy( PACK(a(2:),  a(2:) /= ' ' .OR. a(1:) 
>>>> /= '
> ', pad) )
>
>>> and the results of the two compares cannot be .OR.ed to
>>> each other.  You would have to do something like the
>>> following to fix it:
>>>
>>The "results of the two compares cannot be .OR.ed to each other"  ?????
>>
>>Thats not happening,
>
> But it IS happening.
> What happens when the two intermediate arrays are ORed?
> With what is the last element of the intermediate array    a(1:) /= ' '
> to be ORed?
>
>> when pack sees the first test for a char existing
>>which happens 5x more frequently than the
>>OPTIONAL 2nd test involving the previous char,  it immediately packs the
>>char and MOVES ON,
>>BECAUSE its a  OR    not  a   AND
>
> And with what is the last result of the intermediate array
> a(1:) /= ' ',
> to be used?
>
> You also have a strange idea of the order in which the
> intermediate results are performed.
>
> In all probabability the PACK operation does not commence
> until AFTER the intermediate arrays have been computed
> and those results ORed.
>
>

Giles and yourself are in agreement that my 3-line solution CANT be faster 
than his..
Review below and then tell us you LIKE his version because its: 
fast/legible/brief

In fact its:

1. 3% slower than Frank version
2. uses flag setting thats opaque to reader
3. twice the #executable statements  (6 vs 3)

Btw, I am making future controversial code of mine available via the SAME 
TEST.F90  file
which will be dynamic..  While current reduce blanks controversy continues 
below is my solution file

Otoh, you show a few PL/I declarations in response to my request for actual 
input/output results

http://home.earthlink.net/~dave_gemini/test.f90






0
dave_frank (2243)
8/23/2005 5:58:10 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:sxvOe.7683$FA3.6187@news-server.bigpond.net.au...
..
> He has a current long-running argument that his patently faulty Fortran
> array code was not buggy.
>

I posted the fact that I have discovered a BUG in CVF,  which led me astray. 
My code is now correct and has been for 1 day, but Vowels is determined to 
find a message FROM ANYONE referring to the previous code and then make a 
reply.
Its despicable behaviour but what else does he have to say here?  NOTHING 
NADA  and there NEVER will be code for:
1. generic PL/I Copy
2. user PL/I PACK



0
dave_frank (2243)
8/23/2005 6:24:57 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:57CdnaTewo2W95TeRVn-gg@comcast.com...
> David Frank wrote:
> (snip)
>
> The array operators are nice, and PL/I has them, too, but sometimes
> they can result in much more work being done than without array
> operators.
>
> -- glen
>

And the reason you wont respond to my pointing out PL/I doesnt support array 
sub-scripting IS ?
e.g.    a(2:)

Folks, this is typical PLI'er clamming-up anytime I expose another Fortran 
superiority fact that contradicts:
"PL/I has more power than Fortran-90"  -- R. VOWELS  PL/I -FAQ






0
dave_frank (2243)
8/23/2005 12:39:31 PM
On Mon, 22 Aug 2005 15:45:40 -0400, John W. Kennedy  
<jwkenne@attglobal.net> wrote:

> ANSI PL/I is ex-post-facto, anyway, and allowing declaration after use  
> is just plain bad design, not only from the viewpoint of compiler  
> writers, but from the viewpoint of human users, and it's one of several  
> faults in the design of PL/I occasioned by the notion that everything  
> that wasn't a syntax error and that /might/ have an interpretation,  
> /should/ have an interpretation. It is obvious how that attitude came  
> about, considering the many arbitrary restrictions in FORTRAN and  
> FORTRAN II -- I felt the same way myself in 1965 -- but it was a bad  
> philosophy that led to a number of flaws in the language.

Well, I am a compiler writer, and I don't share that view.  The ANSI  
specification
is probably the most rigorous, least ambiguous language definition.  I  
think your
experience relates perhaps to IBM's version of PL/I, which was somewhat  
looser.

If a language locution conforms to the syntax, then it must have an  
interpretation,
which is why the semantic pass of PL/I is the largest phase in the  
compiler.  To
me, that is the correct way to analyse the source.

Tom
0
tom284 (1839)
8/23/2005 2:35:30 PM
Tom Linden wrote:
> On Mon, 22 Aug 2005 15:45:40 -0400, John W. Kennedy  
> <jwkenne@attglobal.net> wrote:
> 
>> ANSI PL/I is ex-post-facto, anyway, and allowing declaration after 
>> use  is just plain bad design, not only from the viewpoint of 
>> compiler  writers, but from the viewpoint of human users, and it's one 
>> of several  faults in the design of PL/I occasioned by the notion that 
>> everything  that wasn't a syntax error and that /might/ have an 
>> interpretation,  /should/ have an interpretation. It is obvious how 
>> that attitude came  about, considering the many arbitrary restrictions 
>> in FORTRAN and  FORTRAN II -- I felt the same way myself in 1965 -- 
>> but it was a bad  philosophy that led to a number of flaws in the 
>> language.
> 
> 
> Well, I am a compiler writer, and I don't share that view.  The ANSI  
> specification
> is probably the most rigorous, least ambiguous language definition.  I  
> think your
> experience relates perhaps to IBM's version of PL/I, which was somewhat  
> looser.

You've obviously never seen the Vienna Definition. But in any case, the 
ANSI definition is simply irrelevant to the genesis of the language. 
SHARE and IBM were there first.

> If a language locution conforms to the syntax, then it must have an  
> interpretation,
> which is why the semantic pass of PL/I is the largest phase in the  
> compiler.  To
> me, that is the correct way to analyse the source.

As a result of which, we got CHARACTER participation in arithmetic, 
declaration after use, the famous "10 + 1/10" crash, and half a dozen 
other "features" in the language that do nothing but create traps for 
newbies.


-- 
John W. Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
   -- Charles Williams.  "Judgement at Chelmsford"
0
jwkenne (1442)
8/23/2005 3:22:29 PM
D.F. posted earlier,

"David Frank" <dave_frank@hotmail.com> wrote in message 
news:s0iOe.27$_84.19@newsread1.news.atl.earthlink.net...
> OK, when I was experimenting using my PACK syntax in a test program
> suddenly CVF got unhappy with the identical PACK syntax that was acceptable in 
> my strings.f90 file..
> So I am WRONG,  acceptance is NOT assured and I have  updated my REDUCE_BLANKS 
> function in
>
>     http://home.earthlink.net/~dave_gemini/strings.f90
>
> accordingly to use    PACK (  a(2:),  a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /= ' 
> '),  pad )
>
> This is a CVF bug,
> also noted is removing the -1  from the LEN(LINE) also made it accept the 
> statement in my test program.

   ***

I freely admit that I do not know Fortran, but when he states

    " acceptance is NOT assured"

and then goes on to call this a CVF bug, it seems to me (and I certainly could 
be wrong about this) that what he is stating is "not assured" is something that 
others quoted from the current (possibly even past) Fortran standards as being 
something for which there was NO requirement to be "assured".

Can someone who knows Fortran (and the standard) confirm or deny this?  If it is 
true, then what he is calling a "bug" in the CVF compiler is actually (if 
anything) a "bug" in the CVF *documentation* - if and only if - it does not 
currently (clearly) document that "results are unpredictable" for such code.

If I am mistaken about whether or not the Fortran Standard *does* "assure 
results" for such code, does anyone know the procedure for "reporting" compiler 
bugs in CVF and would they let us know what the vendor's response is to this 
"bug".

Obviously, if as I suspect (but could be in error) the only "bug" is in the 
documentation not making it clear that the source code is "unpredictable" 
(and/or invalid) Fortran, then hopefully (but I doubt it) D.F.  will stop 
posting that he had to "change his code BECAUSE of a bug in the CVF compiler".


-- 
Bill Klein
 wmklein <at> ix.netcom.com 


0
wmklein (2605)
8/23/2005 6:56:56 PM
In article <XjKOe.114623$j83.56785@fe05.news.easynews.com>,
 "William M. Klein" <wmklein@nospam.netcom.com> wrote:

> it seems to me ... that what he is stating is "not assured" is something that 
> others quoted from the current (possibly even past) Fortran standards as 
> being something for which there was NO requirement to be "assured".
> 
> Can someone who knows Fortran (and the standard) confirm or deny this?

1. You are basically correct. The code in question was nonstandard, but 
in a way that the standard does not require diagnosis of. It is widely 
considered to be highly desirable/useful (even though not required by 
the standard) for compilers to have the capability of diagnosing such 
things, and indeed most compilers (including CVF, as we have seen) do 
have such capability, but it often requires explicit enabling because of 
its run-time cost.

2. I do claim to have some small knowledge of the standard (I was the 
editor for both f95 and f2003). I typically don't mention that 
explicitly because I prefer arguments based on technical merit and 
citation rather than based on people and their titles. But I'll make an 
exception here to note that I recommend taking *ANYTHING* that DF says 
about the Fortran standard with a rather substantial grain of salt. 
(Even better, I'd recommend not reading his posts at all because I think 
you'll get more bad information that good from them). In the past, he 
has been known to explicitly state that he has his own definition of the 
term "standard" and that he considers the ISO document to be irrelevant. 
In his recent statements I've seen a different line, but I have trouble 
keeping track of his current line and mostly I don't care.

Anyway, my message here is that I do not feel it worthwhile to 
continually point out the various relationships between DF's statements 
and the standard, whether the statements arise from ignorance, 
intentional misdirection, matters of possible debate, or even happen to 
be completely correct. My usual silence (broken only momentarily) is not 
to be considered as agreement.

I will not even guarantee to answer direct questions on the subject. If 
you honestly want to know the answer to some question about the Fortran 
standard (the ISO one) for reasons other than to debate with DF, your 
odds of getting me to respond are *FAR* better if you write it as a 
completely independent question, with no reference to DF or to any of 
the flamewars that regularly rage around him.

-- 
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain
0
nospam47 (9747)
8/23/2005 7:40:38 PM
John W. Kennedy wrote in message ...
>Tom Linden wrote:
>> On Mon, 22 Aug 2005 15:45:40 -0400, John W. Kennedy
>> <jwkenne@attglobal.net> wrote:
>>
>>> ANSI PL/I is ex-post-facto, anyway, and allowing declaration after
>>> use  is just plain bad design, not only from the viewpoint of
>>> compiler  writers, but from the viewpoint of human users, and it's one
>>> of several  faults in the design of PL/I occasioned by the notion that
>>> everything  that wasn't a syntax error and that /might/ have an
>>> interpretation,  /should/ have an interpretation. It is obvious how
>>> that attitude came  about, considering the many arbitrary restrictions
>>> in FORTRAN and  FORTRAN II -- I felt the same way myself in 1965 --
>>> but it was a bad  philosophy that led to a number of flaws in the
>>> language.
>>
>>
>> Well, I am a compiler writer, and I don't share that view.  The ANSI
>> specification
>> is probably the most rigorous, least ambiguous language definition.  I
>> think your
>> experience relates perhaps to IBM's version of PL/I, which was somewhat
>> looser.
>
>You've obviously never seen the Vienna Definition. But in any case, the
>ANSI definition is simply irrelevant to the genesis of the language.
>SHARE and IBM were there first.
>
>> If a language locution conforms to the syntax, then it must have an
>> interpretation,
>> which is why the semantic pass of PL/I is the largest phase in the
>> compiler.  To
>> me, that is the correct way to analyse the source.
>
>As a result of which, we got CHARACTER participation in arithmetic,
>declaration after use, the famous "10 + 1/10" crash,

You obviousy don't understand decimal arithmetic; in particular division.

>and half a dozen
>other "features" in the language that do nothing but create traps for
>newbies.


There will always be traps for newbies in any language.
PL/I has fewer of them than other languages.

1/2 and 1/3 are beautiful ones in Fortran.
C is a rich source.

>--
>John W. Kennedy


0
robin_v (2737)
8/24/2005 12:21:05 AM
David Frank wrote in message
<7OEOe.627$_84.612@newsread1.news.atl.earthlink.net>...
>
>"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
>news:57CdnaTewo2W95TeRVn-gg@comcast.com...
>> David Frank wrote:
>> (snip)
>>
>> The array operators are nice, and PL/I has them, too, but sometimes
>> they can result in much more work being done than without array
>> operators.
>>
>> -- glen
>>
>
>And the reason you wont respond to my pointing out PL/I doesnt support array
>sub-scripting IS ?
>e.g.    a(2:)
>
>Folks, this is typical PLI'er clamming-up anytime I expose another Fortran
>superiority fact that contradicts:
>"PL/I has more power than Fortran-90"  -- R. VOWELS  PL/I -FAQ


Some time back, I demonstrated to you in this forum that
you can do this style - a(2:)  - in PL/I.


0
robin_v (2737)
8/24/2005 12:21:06 AM
robin wrote:
> John W. Kennedy wrote in message ...
> 
>>Tom Linden wrote:
>>
>>>On Mon, 22 Aug 2005 15:45:40 -0400, John W. Kennedy
>>><jwkenne@attglobal.net> wrote:
>>>
>>>
>>>>ANSI PL/I is ex-post-facto, anyway, and allowing declaration after
>>>>use  is just plain bad design, not only from the viewpoint of
>>>>compiler  writers, but from the viewpoint of human users, and it's one
>>>>of several  faults in the design of PL/I occasioned by the notion that
>>>>everything  that wasn't a syntax error and that /might/ have an
>>>>interpretation,  /should/ have an interpretation. It is obvious how
>>>>that attitude came  about, considering the many arbitrary restrictions
>>>>in FORTRAN and  FORTRAN II -- I felt the same way myself in 1965 --
>>>>but it was a bad  philosophy that led to a number of flaws in the
>>>>language.
>>>
>>>
>>>Well, I am a compiler writer, and I don't share that view.  The ANSI
>>>specification
>>>is probably the most rigorous, least ambiguous language definition.  I
>>>think your
>>>experience relates perhaps to IBM's version of PL/I, which was somewhat
>>>looser.
>>
>>You've obviously never seen the Vienna Definition. But in any case, the
>>ANSI definition is simply irrelevant to the genesis of the language.
>>SHARE and IBM were there first.
>>
>>
>>>If a language locution conforms to the syntax, then it must have an
>>>interpretation,
>>>which is why the semantic pass of PL/I is the largest phase in the
>>>compiler.  To
>>>me, that is the correct way to analyse the source.
>>
>>As a result of which, we got CHARACTER participation in arithmetic,
>>declaration after use, the famous "10 + 1/10" crash,
> 
> 
> You obviousy don't understand decimal arithmetic; in particular division.

No, I /do/ understand it, and that's why I know that PL/I's design was 
botched. Not botched as obscenely as COBOL's had been, God knows, but 
botched all the same.

That's why Ada, the only other language to take fixed-point non-integer 
types seriously, requires outright that the exact precision of every 
multiplication and division be given explicitly in the source (as though 
PL/I were to mandate use of the MULTIPLY and DIVIDE built-ins instead of 
"*" and "/" for fixed-point non-integer types).

>>and half a dozen
>>other "features" in the language that do nothing but create traps for
>>newbies.
> 
> 
> 
> There will always be traps for newbies in any language.
> PL/I has fewer of them than other languages.
> 
> 1/2 and 1/3 are beautiful ones in Fortran.

No, that's simple. Integers are different from non-integers. Anyone who 
can't learn that in five minutes needs to stay away from programming. 
PL/I's situation, on the other hand, requires memorizing complex and 
non-portable formulae. (The situation in PL/I is made the worse by the 
fact that PL/I has no integer types, except for the bastard situation in 
ANSI PL/I of FIXED BINARY being integer and FIXED DECIMAL not.)

> C is a rich source.

C's faults generally arise from too much simplicity. PL/I's faults 
generally arise from attempting to implement things that, in 1965, were 
not yet adequately understood.

At least C didn't wait until the 90's to have type definition.

-- 
John W. Kennedy
"...if you had to fall in love with someone who was evil, I can see why 
it was her."
   -- "Alias"
0
jwkenne (1442)
8/24/2005 12:55:25 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:S3POe.8483$FA3.4889@news-server.bigpond.net.au...
>
> David Frank wrote in message
> <7OEOe.627$_84.612@newsread1.news.atl.earthlink.net>...
>>
>>"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
>>news:57CdnaTewo2W95TeRVn-gg@comcast.com...
>>> David Frank wrote:
>>> (snip)
>>>
>>> The array operators are nice, and PL/I has them, too, but sometimes
>>> they can result in much more work being done than without array
>>> operators.
>>>
>>> -- glen
>>>
>>
>>And the reason you wont respond to my pointing out PL/I doesnt support 
>>array
>>sub-scripting IS ?
>>e.g.    a(2:)
>>
>>Folks, this is typical PLI'er clamming-up anytime I expose another Fortran
>>superiority fact that contradicts:
>>"PL/I has more power than Fortran-90"  -- R. VOWELS  PL/I -FAQ
>
>
> Some time back, I demonstrated to you in this forum that
> you can do this style - a(2:)  - in PL/I.
>
>

Instead of saying you can do it and blathering on and on,  just show us a 
translation of below,  how hard is that?

integer :: dog(10), cat(3)

dog(5:7) = cat

Show a array declaration and then array sub-scripting 


0
dave_frank (2243)
8/24/2005 1:02:21 AM
William M. Klein wrote in message ...
>D.F. posted earlier,
>
>"David Frank" <dave_frank@hotmail.com> wrote in message
>news:s0iOe.27$_84.19@newsread1.news.atl.earthlink.net...
>> OK, when I was experimenting using my PACK syntax in a test program
>> suddenly CVF got unhappy with the identical PACK syntax that was acceptable
in
>> my strings.f90 file..
>> So I am WRONG,  acceptance is NOT assured and I have  updated my
REDUCE_BLANKS
>> function in
>>
>>     http://home.earthlink.net/~dave_gemini/strings.f90
>>
>> accordingly to use    PACK (  a(2:),  a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /= '
>> '),  pad )
>>
>> This is a CVF bug,
>> also noted is removing the -1  from the LEN(LINE) also made it accept the
>> statement in my test program.
>
>   ***
>
>I freely admit that I do not know Fortran, but when he states
>
>    " acceptance is NOT assured"
>
>and then goes on to call this a CVF bug, it seems to me (and I certainly could
>be wrong about this) that what he is stating is "not assured" is something that
>others quoted from the current (possibly even past) Fortran standards as being
>something for which there was NO requirement to be "assured".
>
>Can someone who knows Fortran (and the standard) confirm or deny this?  If it
is
>true, then what he is calling a "bug" in the CVF compiler is actually (if
>anything) a "bug" in the CVF *documentation* - if and only if - it does not
>currently (clearly) document that "results are unpredictable" for such code.
>
>If I am mistaken about whether or not the Fortran Standard *does* "assure
>results" for such code, does anyone know the procedure for "reporting" compiler
>bugs in CVF and would they let us know what the vendor's response is to this
>"bug".
>
>Obviously, if as I suspect (but could be in error) the only "bug" is in the
>documentation not making it clear that the source code is "unpredictable"
>(and/or invalid) Fortran, then hopefully (but I doubt it) D.F.  will stop
>posting that he had to "change his code BECAUSE of a bug in the CVF compiler".

Frank had to change his code because of a bug in his
program (incompatible arrays).
    He did not have array bounds checking enabled (he claims
that there is no switch to enable that to be done,
but another Fortran user posted that he doubted that that
claim was correct).


0
robin_v (2737)
8/24/2005 4:24:47 AM
David Frank wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:RJRNe.5955$FA3.3343@news-server.bigpond.net.au...
>>

>You have stated that PL/I supports generic routines, but when asked to show
>code, refuse to do so.

That's a falsehood, and you know it.

>Here's  another chance,  show Fortran'ers and your DEVOTED PL/I readership
>YOUR generic Copy function.


In PL/I it's the standard built-in function and pseudo-variable called STRING.


0
robin_v (2737)
8/24/2005 4:24:49 AM
David Frank wrote in message ...
>
>Count_Items = COUNT([LEN_TRIM(s) > 0,(s(i:i)/=' '.AND.s(i+1:i+1)==' ',
>i=1,LEN_TRIM(s)-1)])
>
>is my 1-liner that scans the string "s" just once as per challenge to show
>Fortran has more powerful syntax than PL/I.
>
>Otoh,   Count_Items = 1 + Tally(s,' ') - Tally(s,'  ')  scans "s"  twice.


You're in fairyland if you think that your Fortran statement
is simple, straightforward, and easy to follow, compared to
my simple PL/I statement.


0
robin_v (2737)
8/24/2005 4:24:50 AM
David Frank wrote in message ...
>OK, when I was experimenting using my PACK syntax in a test program
>suddenly CVF got unhappy with the identical PACK syntax that was acceptable
>in my strings.f90 file..
>So I am WRONG,  acceptance is NOT assured and I have  updated my
>REDUCE_BLANKS function in
>
>     http://home.earthlink.net/~dave_gemini/strings.f90
>
>accordingly to use    PACK (  a(2:),  a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /=
>'  '),  pad )
>
>This is a CVF bug,

Whether or not is irrelevant.
What's relevant is that there's a bug in your code.

>also noted is removing the -1  from the LEN(LINE) also made it accept the
>statement in my test program.


That would introduce another bug into your program.


0
robin_v (2737)
8/24/2005 4:24:50 AM
David Frank wrote in message ...

>...  the challenge put forward by the
>PL/I -FAQ is that PL/I is more powerful than Fortran,
>my example brief/powerful  demo of  Fortran syntax shows that is NOT the
>case.


The only thing that you have demonstrated is that you are
incapable of writing correct code in Fortran.

And the code that you demonstrated for Count Items
was plagiarized from comp.lang.pl1


0
robin_v (2737)
8/24/2005 4:24:51 AM
David Frank wrote in message ...
>
>"gerard46" <gerard46@rtt.net> wrote in message
>news:HbKdnW5vMelMOZreRVn-gQ@onvoy.com...
>>| David Frank
>>
>> |> Frank, Frank, Frank.  I didn't see YOU post a 1-line solution.  What
>> |> you did post was a number of WRONG solutions, all of them at least
>> |> four or more lines, and obsure code at that.
>> |>
>> |> Also, it should be noted that your solution scanned the source line
>> |> twice, one as a character string, another in a boolean version (for
>> |> the COUNT function).   You really should learn how to count Fortran
>> |> statements.   I also noted that when your challenge was met (and
>> |> bested), you add the silly restriction that it had to be scanned only
>> |> once, a restriction that even your code doesn't do.   The goal in
>> |> programming is to find solutions to problems, if you don't like the
>> |> (better) solution, then don't come back and say, "well, I bet ya
>> |> can't do that with one hand behind your back !!". _________Gerard S.
>>
>> | Gerard, Gerard, Gerard.
>> | You didnt come up with a Count_Items PL/I solution whereas:
>> | my 1 line solution that scans line ONCE can be viewed at:
>> |
>> |    http://earthlink.net/~dave_gemini/strings.f90
>>
>> Frank, Frank, Frank.  This is getting rather tedious.  The reason I
>> didn't come up with a 1-liner solution was that it was already
>> solved by Robin (I believe).
>
>2 TALLY calls  = 2 scans   <GEESH>
>
> No sense in duplicating efforts.  Note
>> that you seem to have a real difficult time with counting (Fortran)
>> lines.  Your 1-line solution needs six lines (counting the
>> invocation as 1 line, plus five more lines for the "1-line"
>> Fortran subroutine).   Hells bells, if everybody would count like
>> that, COUNT (in Fortran) would bring on a whole new meaning.  I'd
>> rather stick to the idea that 1-line means 1-line, not 5. ___Gerard S.
>>
>
>We are talking count of # executable statements.
>If you place your tally statement into a PL/I function called
>Count_items(line)
>you have as many or more support statements as I do..

No need to because the PL/I stament is simple.

And even if it *were* to be used so often that it might
be desirable to encapsulate it, it could be set up
as a macro call.
And that produices just ONE executable statement.


0
robin_v (2737)
8/24/2005 4:24:52 AM
David Frank wrote in message ...
> the challenge put forward by the
>PL/I -FAQ is that PL/I is more powerful than Fortran,
>my example brief/powerful  demo of  Fortran syntax shows that is NOT the
>case.

Your "brief/powerful" [sic] demo did nothing of the sort.
1.    It used 22 statements.
2.    It contained major bugs.
All you did was demonstrate that you are incapable of writing
a correct program

    Reducing blanks can be done faster and shorter in PL/I
in 12 statements.






0
robin_v (2737)
8/24/2005 4:24:54 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:mESOe.8630$FA3.2891@news-server.bigpond.net.au...
>
> David Frank wrote in message ...
>>
>>Count_Items = COUNT([LEN_TRIM(s) > 0,(s(i:i)/=' '.AND.s(i+1:i+1)==' ',
>>i=1,LEN_TRIM(s)-1)])
>>
>>is my 1-liner that scans the string "s" just once as per challenge to show
>>Fortran has more powerful syntax than PL/I.
>>
>>Otoh,   Count_Items = 1 + Tally(s,' ') - Tally(s,'  ')  scans "s"  twice.
>
>
> You're in fairyland if you think that your Fortran statement
> is simple, straightforward, and easy to follow, compared to
> my simple PL/I statement.
>
>

Thats certainly true.
You wont find a statement from me that my 1-liner is any of those things 
(simple, etc.)
it took quite a while to come up with it  and its the ONLY Fortran 1-liner 
Count_Items
(which was all part of the fun, too bad PLI'ers dont have the syntax sugar 
that allows them to participate on a equal basis with Fortran-90 users)
.. 


0
dave_frank (2243)
8/24/2005 7:24:56 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:mESOe.8631$FA3.7614@news-server.bigpond.net.au...
>
> David Frank wrote in message ...
>>OK, when I was experimenting using my PACK syntax in a test program
>>suddenly CVF got unhappy with the identical PACK syntax that was 
>>acceptable
>>in my strings.f90 file..
>>So I am WRONG,  acceptance is NOT assured and I have  updated my
>>REDUCE_BLANKS function in
>>
>>     http://home.earthlink.net/~dave_gemini/strings.f90
>>
>>accordingly to use    PACK (  a(2:),  a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) 
>>/=
>>'  '),  pad )
>>
>>This is a CVF bug,
>
> Whether or not is irrelevant.
> What's relevant is that there's a bug in your code.
>
>>also noted is removing the -1  from the LEN(LINE) also made it accept the
>>statement in my test program.
>
>
> That would introduce another bug into your program.
>
>


Read what RM has to say (I'm not going to quote him)..
I already stated the driver index is PACK's array arg not the arrays 
associated with the logical mask.
As long as the logical arrays are >= PACK array size,
THERE WILL BE NO PROBLEM,  NO BOUNDS FAULT,  NADA..

The problem is CVF sporatically wants to diagnose the logical array sizes 
for being unequal with each other and the array being packed.
I never encountered wrong answers because I never supplied logical arrays 
that were less than the size of the array being PACKED.

However I dont expect you or  Rich Townsend will ever grasp how PACK works.

And your claim today posted in comp.lang.pl1 that you have written a PL/I 
PACK is ridiculous, you have no regard for the truth..


0
dave_frank (2243)
8/24/2005 7:44:54 AM
"robin" <robin_v@bigpond.com> wrote in message 
news:lESOe.8629$FA3.5976@news-server.bigpond.net.au...
> David Frank wrote in message ...
>>
>>"robin" <robin_v@bigpond.com> wrote in message
>>news:RJRNe.5955$FA3.3343@news-server.bigpond.net.au...
>>>
>
>>You have stated that PL/I supports generic routines, but when asked to 
>>show
>>code, refuse to do so.
>
> That's a falsehood, and you know it.
>
>>Here's  another chance,  show Fortran'ers and your DEVOTED PL/I readership
>>YOUR generic Copy function.
>
>
> In PL/I it's the standard built-in function and pseudo-variable called 
> STRING.
>
>

Are you forgetting that comp.lang.pl1  is archived and is a great  DE-LIAR, 
there are no hits for "GENERIC"
that lead to code examples from pli'ers,  just from myself showing Fortran 
examples.



0
dave_frank (2243)
8/24/2005 7:50:33 AM
John W. Kennedy wrote in message <1APOe.997$9X.165@fe09.lga>...
>The situation in PL/I is made the worse by the
>fact that PL/I has no integer types, except for the bastard situation in
>ANSI PL/I of FIXED BINARY being integer and FIXED DECIMAL not.)


PL/I has always had integer types:

dcl x fixed binary; dcl y fixed decimal;


0
robin_v (2737)
8/24/2005 10:31:30 AM
David Frank wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:mESOe.8630$FA3.2891@news-server.bigpond.net.au...
>>
>> David Frank wrote in message ...
>>>
>>>Count_Items = COUNT([LEN_TRIM(s) > 0,(s(i:i)/=' '.AND.s(i+1:i+1)==' ',
>>>i=1,LEN_TRIM(s)-1)])
>>>
>>>is my 1-liner that scans the string "s" just once as per challenge to show
>>>Fortran has more powerful syntax than PL/I.
>>>
>>>Otoh,   Count_Items = 1 + Tally(s,' ') - Tally(s,'  ')  scans "s"  twice.

>> You're in fairyland if you think that your Fortran statement
>> is simple, straightforward, and easy to follow, compared to
>> my simple PL/I statement.
>>
>Thats certainly true.
>You wont find a statement from me that my 1-liner is any of those things
>(simple, etc.)
>it took quite a while to come up with it  and its the ONLY Fortran 1-liner
>Count_Items

But does it count items correctly ?

Count_Items =
   COUNT([LEN_TRIM(s) > 0,(s(i:i)/=' '.AND.s(i+1:i+1)==' ', i=1,LEN_TRIM(s)-1)])

When s is 'ABC', COUNT returns 1, but when s is 'ABC   ', COUNT returns 2,
whereas it should return 1.


0
robin_v (2737)
8/24/2005 10:31:31 AM
David Frank wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:mESOe.8631$FA3.7614@news-server.bigpond.net.au...
>>
>> David Frank wrote in message ...
>>>OK, when I was experimenting using my PACK syntax in a test program
>>>suddenly CVF got unhappy with the identical PACK syntax that was
>>>acceptable
>>>in my strings.f90 file..
>>>So I am WRONG,  acceptance is NOT assured and I have  updated my
>>>REDUCE_BLANKS function in
>>>
>>>     http://home.earthlink.net/~dave_gemini/strings.f90
>>>
>>>accordingly to use    PACK (  a(2:),  a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /='
'),  pad )
>>>
>>>This is a CVF bug,
>>
>> Whether or not is irrelevant.
>> What's relevant is that there's a bug in your code.
>>
>>>also noted is removing the -1  from the LEN(LINE) also made it accept the
>>>statement in my test program.
>>
>> That would introduce another bug into your program.

>
>Read what RM has to say (I'm not going to quote him)..
>I already stated the driver index is PACK's array arg not the arrays
>associated with the logical mask.
>As long as the logical arrays are >= PACK array size,
>THERE WILL BE NO PROBLEM,  NO BOUNDS FAULT,  NADA..


You would have incompatible array expressions, one having bounds 2 thru
len(line)
and the other having bounds 1 thru len(line), and that's a programming error.

>The problem is CVF sporatically wants to diagnose the logical array sizes
>for being unequal with each other and the array being packed.

Then it is correctly diagnosing that the arrays have
an unequal number of elements.

>I never encountered wrong answers because I never supplied logical arrays
>that were less than the size of the array being PACKED.


That's  irrelevant.  The array sub-espressions have to be ORed first,
and to do that, the arrays are required to have EXACTLY the same number of
elements.

>However I dont expect you or  Rich Townsend will ever grasp how PACK works.
>
>And your claim today posted in comp.lang.pl1 that you have written a PL/I
>PACK is ridiculous, you have no regard for the truth..


The truth is that they have been written.


0
robin_v (2737)
8/24/2005 10:31:32 AM
David Frank wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:lESOe.8629$FA3.5976@news-server.bigpond.net.au...
>> David Frank wrote in message ...
>>>
>>>"robin" <robin_v@bigpond.com> wrote in message
>>>news:RJRNe.5955$FA3.3343@news-server.bigpond.net.au...
>>>>
>>
>>>You have stated that PL/I supports generic routines, but when asked to
>>>show
>>>code, refuse to do so.
>>
>> That's a falsehood, and you know it.
>>
>>>Here's  another chance,  show Fortran'ers and your DEVOTED PL/I readership
>>>YOUR generic Copy function.
>>
>>
>> In PL/I it's the standard built-in function and pseudo-variable called
>> STRING.
>
>Are you forgetting that comp.lang.pl1  is archived and is a great  DE-LIAR,
>there are no hits for "GENERIC"
>that lead to code examples from pli'ers,

You wouldn't recognize one even if it sat on you.

> just from myself showing Fortran examples.


The search is only as reliable as your search engine,
and depend on whether all postings have, in fact, been archived.


0
robin_v (2737)
8/24/2005 10:31:33 AM
David Frank wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:S3POe.8483$FA3.4889@news-server.bigpond.net.au...
>>
>> David Frank wrote in message
>> <7OEOe.627$_84.612@newsread1.news.atl.earthlink.net>...
>>>
>>>"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
>>>news:57CdnaTewo2W95TeRVn-gg@comcast.com...
>>>> David Frank wrote:
>>>> (snip)
>>>>
>>>> The array operators are nice, and PL/I has them, too, but sometimes
>>>> they can result in much more work being done than without array
>>>> operators.
>>>>
>>>> -- glen
>>>>
>>>
>>>And the reason you wont respond to my pointing out PL/I doesnt support
>>>array
>>>sub-scripting IS ?
>>>e.g.    a(2:)
>>>
>>>Folks, this is typical PLI'er clamming-up anytime I expose another Fortran
>>>superiority fact that contradicts:
>>>"PL/I has more power than Fortran-90"  -- R. VOWELS  PL/I -FAQ
>>
>>
>> Some time back, I demonstrated to you in this forum that
>> you can do this style - a(2:)  - in PL/I.

>Instead of saying you can do it and blathering on and on,  just show us a
>translation of below,  how hard is that?
>
>integer :: dog(10), cat(3)
>
>dog(5:7) = cat
>
>Show a array declaration and then array sub-scripting


I did this for you some time back, and see no need to repeat it.


0
robin_v (2737)
8/24/2005 10:31:33 AM
David Frank wrote:
....
> Read what RM has to say (I'm not going to quote him)..
> I already stated the driver index is PACK's array arg not the arrays
> associated with the logical mask.

There is no such thing as a "driver index" in PACK.
It requires properly formed arrays as its arguments.
It then (using whatever method an implementation
chooses - even complete parallel operation, if
the hardware supports it) achieves the requires
semantics.

In your code, there was no properly formed array
mask argument passed.  The expression was non
standard.

-- 
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies."   --  C. A. R. Hoare


0
jamesgiles (2210)
8/24/2005 7:35:43 PM
robin wrote:
> John W. Kennedy wrote in message <1APOe.997$9X.165@fe09.lga>...
> 
>>The situation in PL/I is made the worse by the
>>fact that PL/I has no integer types, except for the bastard situation in
>>ANSI PL/I of FIXED BINARY being integer and FIXED DECIMAL not.)
> 
> 
> 
> PL/I has always had integer types:
> 
> dcl x fixed binary; dcl y fixed decimal;
> 
> 
No, Robin, these are fixed point values with no fractional places which are not 
the same as integers. Integer division produces an integer quotient.  Fixed 
point division, even when the dividend and divisor have no fractional places, 
can produce a quotient with fractional places which will participate in further 
operations and give a different result than true integer arithmetic would give. 
  There are, of course, easy ways around the "problem", but it still isn't a 
true integer type.
0
jjw (608)
8/24/2005 9:17:22 PM
robin wrote:

> John W. Kennedy wrote in message <1APOe.997$9X.165@fe09.lga>...
> 
>>The situation in PL/I is made the worse by the
>>fact that PL/I has no integer types, except for the bastard situation in
>>ANSI PL/I of FIXED BINARY being integer and FIXED DECIMAL not.)

> PL/I has always had integer types:

> dcl x fixed binary; dcl y fixed decimal;

I don't believe that there is any good answer.

Computer architects and Fortran have specified integer division has
an integer quotient.  That is not the only possibility, though.

The PL/I rules tend to make more sense for variables than for
constants, though the rules is that constants have the scale and
precision that they are written in.

Some have suggested no / operator for fixed point, that only the DIVIDE 
built in function be used.   I don't think I agree, though I don't know
that I have any better suggestion.

-- glen

0
gah (12851)
8/24/2005 11:15:47 PM
James J. Weinkam wrote:

(snip)

> No, Robin, these are fixed point values with no fractional places which 
> are not the same as integers. Integer division produces an integer 
> quotient.  Fixed point division, even when the dividend and divisor have 
> no fractional places, can produce a quotient with fractional places 
> which will participate in further operations and give a different result 
> than true integer arithmetic would give.  There are, of course, easy 
> ways around the "problem", but it still isn't a true integer type.

Integer division produces an integer quotient to processor designers
and, most likely from there, to Fortran's designers.

It doesn't in Pascal, though.

It seems obvious because it has been done so many times, but
that doesn't mean it is the only way.

-- glen

0
gah (12851)
8/25/2005 2:29:49 AM
glen herrmannsfeldt wrote:
> James J. Weinkam wrote:
> 
> (snip)
> 
>> No, Robin, these are fixed point values with no fractional places 
>> which are not the same as integers. Integer division produces an 
>> integer quotient.  Fixed point division, even when the dividend and 
>> divisor have no fractional places, can produce a quotient with 
>> fractional places which will participate in further operations and 
>> give a different result than true integer arithmetic would give.  
>> There are, of course, easy ways around the "problem", but it still 
>> isn't a true integer type.
> 
> 
> Integer division produces an integer quotient to processor designers
> and, most likely from there, to Fortran's designers.
> 
> It doesn't in Pascal, though.
> 
> It seems obvious because it has been done so many times, but
> that doesn't mean it is the only way.
> 
> -- glen
> 
Well, if you want to get technical about it, integer division is defined by the 
equation

a=b*q+r

where a is the dividend, b is the divisor, q is the quotient and r is the 
remainder, together with a rule for choosing a unique solution from the infinite 
number of solutions available.

Several common rules are:

|r|<|b|, r=0 or sign(r)=sign(a)

|r|<|b|, r=0 or sign(r)=sign(b)

0<=r<|b|


Using the first rule, q is the value usually given as the quotient in integer 
division.

Using the second rule, r is a mod b in APL (written b|a)

Using the third rule r is mod(a,b) in PL/I.

There are other possibilities.
0
jjw (608)
8/25/2005 8:22:46 AM
I've got references at work for a couple of u-coded implementations. 
I'll see if I canm find them.

robin wrote:
> John W. Kennedy wrote in message ...
> 
>>William M. Klein wrote:
>>
>>>I don't (personally) know of any machine that "executes" either PL/I or
> 
> Fortran
> 
>>>statements.  (There may be one or more, but I don't know of any).
>>
>>Back in the 60's, Allan-Babcock's RUSH time-sharing service used a
>>modified 360/50 with a microcode PL/I interpreter. However, it must have
>>used a preprocessor or significantly non-standard PL/I, as it is
>>impossible to determine the semantics of a PL/I program in a single pass.
> 
> 
> The whole language, perhaps, but a single pass compiler was
> done for a subset on the CDC Cyber.
> 
> 

0
Peter_Flass (956)
8/25/2005 12:19:50 PM
John W. Kennedy wrote:
> 
> The whole language /definitely/, because PL/I (and this is one of 
> several mistakes in the language) allows something to be declared after 
> it is first used. 

I have to disagree.  This is one of the many useful features of the 
language that I'm always surprised isn't implemented in others.  At the 
cost of a little compile time it frees programmers from the tyrrany if, 
e.g. having to have C headers arranged in the "proper" order in order to 
get something to compile.


0
Peter_Flass (956)
8/25/2005 12:22:51 PM
Peter Flass wrote:

> John W. Kennedy wrote:
> 
>>
>> The whole language /definitely/, because PL/I (and this is one of 
>> several mistakes in the language) allows something to be declared 
>> after it is first used. 
> 
> 
> I have to disagree.  This is one of the many useful features of the 
> language that I'm always surprised isn't implemented in others.  At the 
> cost of a little compile time it frees programmers from the tyrrany if, 
> e.g. having to have C headers arranged in the "proper" order in order to 
> get something to compile.
> 
> 

What use do you make of this feature?  An example please.

What do you do about seperate compilation?  Parameter checking?

I never thought of the headers as being tyranny, but rather a nice final 
check to see if I was calling what I thought I was calling.  I think C++ 
  is even nicer that way, but I'm curious to see why you think differently.

TIA.

LR

0
lruss (582)
8/25/2005 12:38:24 PM
robin wrote:
> John W. Kennedy wrote in message <1APOe.997$9X.165@fe09.lga>...
> 
>>The situation in PL/I is made the worse by the
>>fact that PL/I has no integer types, except for the bastard situation in
>>ANSI PL/I of FIXED BINARY being integer and FIXED DECIMAL not.)
> 
> 
> 
> PL/I has always had integer types:
> 
> dcl x fixed binary; dcl y fixed decimal;

No, in IBM PL/I, neither is an integer type. In ANSI PL/I, only the 
first is.

-- 
John W. Kennedy
"The bright critics assembled in this volume will doubtless show, in 
their sophisticated and ingenious new ways, that, just as /Pooh/ is 
suffused with humanism, our humanism itself, at this late date, has 
become full of /Pooh./"
   -- Frederick Crews.  "Postmodern Pooh", Preface
0
jwkenne (1442)
8/25/2005 7:13:42 PM
John W. Kennedy wrote:

(snip)

>> PL/I has always had integer types:

>> dcl x fixed binary; dcl y fixed decimal;

> No, in IBM PL/I, neither is an integer type. In ANSI PL/I, only the 
> first is.

There is no rule that says that integer division must produce
and integer quotient.

I would even claim that it isn't true for the hardware for most machine.

Since most hardware divides a 2N bit number by an N bit number one must
choose which of the 2N bits to use for the N bit dividend.  That choice 
determines the position of the binary point in the quotient.

Fortran chose an integer quotient, so did C.  Pascal didn't.

Some languages (most BASICs and AWK to name two) only have floating 
point so one must explicitly truncate the quotient.

If you don't like PL/I's rules, don't use it.

-- glen

0
gah (12851)
8/25/2005 11:40:35 PM
glen herrmannsfeldt wrote:
> There is no rule that says that integer division must produce
> and integer quotient.

Actually, in normal parlance, "integer division" /does/ mean that. 
Division of two integers to give a non-integer is not normally called 
"integer division".

> I would even claim that it isn't true for the hardware for most machine.

> Since most hardware divides a 2N bit number by an N bit number one must
> choose which of the 2N bits to use for the N bit dividend.  That choice 
> determines the position of the binary point in the quotient.

I don't know of any architecture that does not produce an integer 
quotient and a remainder. Fractional results are achieved only by bit 
shifting.

> Fortran chose an integer quotient, so did C.  Pascal didn't.

Actually, Pascal gives a choice between "/" and "div".

> Some languages (most BASICs and AWK to name two) only have floating 
> point so one must explicitly truncate the quotient.

....which is why such language are not used for serious programming.

> If you don't like PL/I's rules, don't use it.

Thank you Mr. Archie Bunker.

-- 
John W. Kennedy
"I want everybody to be smart. As smart as they can be. A world of 
ignorant people is too dangerous to live in."
   -- Garson Kanin. "Born Yesterday"
0
jwkenne (1442)
8/25/2005 11:50:57 PM
Long ago, before I understood what PL/I was doing with division, I 
simply didn't use the result of a division in an expression, but 
assigned it to a variable, which eliminated all the problems.  Now, of 
course, I (think I) understand it, but it's still simple to write, e.g.:
   DCL (A,M) FIXED BINARY;
   M = A/10;
   M = A - M*10;
rather than:
   M = A - (A/10)*10;
If you want an integer result from division, divide and assign the 
result to an integer, if you don't want to use the DIVIDE BIF.


John W. Kennedy wrote:

> glen herrmannsfeldt wrote:
> 
>> There is no rule that says that integer division must produce
>> and integer quotient.
> 
> 
> Actually, in normal parlance, "integer division" /does/ mean that. 
> Division of two integers to give a non-integer is not normally called 
> "integer division".
> 
>> I would even claim that it isn't true for the hardware for most machine.
> 
> 
>> Since most hardware divides a 2N bit number by an N bit number one must
>> choose which of the 2N bits to use for the N bit dividend.  That 
>> choice determines the position of the binary point in the quotient.
> 
> 
> I don't know of any architecture that does not produce an integer 
> quotient and a remainder. Fractional results are achieved only by bit 
> shifting.
> 
>> Fortran chose an integer quotient, so did C.  Pascal didn't.
> 
> 
> Actually, Pascal gives a choice between "/" and "div".
> 
>> Some languages (most BASICs and AWK to name two) only have floating 
>> point so one must explicitly truncate the quotient.
> 
> 
> ...which is why such language are not used for serious programming.
> 
>> If you don't like PL/I's rules, don't use it.
> 
> 
> Thank you Mr. Archie Bunker.
> 

0
Peter_Flass (956)
8/26/2005 1:05:02 AM
John W. Kennedy wrote:

(I wrote)

>> Since most hardware divides a 2N bit number by an N bit number one must
>> choose which of the 2N bits to use for the N bit dividend.  That 
>> choice determines the position of the binary point in the quotient.

> I don't know of any architecture that does not produce an integer 
> quotient and a remainder. Fractional results are achieved only by bit 
> shifting.

For S/360, and I think similarly for many others, you need a
sign padded dividend.  This is done by loading the 32 bit dividend
into the even register of an even-odd pair and doing a double
arithmetic right shift of 32 bits.  If you clear the odd register
and right shift less than 32 bits the quotient will have the binary
point in a different place.

So, since you have to do the shift anyway, the only difference is
that it isn't 32 bits.  If you don't shift at all and clear the odd
register, the quotient has 32 bits after the binary point, though
it is easy to overflow in that case.

-- glen

0
gah (12851)
8/26/2005 3:53:11 AM
glen herrmannsfeldt wrote in message ...
>For S/360, and I think similarly for many others, you need a
>sign padded dividend.  This is done by loading the 32 bit dividend
>into the even register of an even-odd pair and doing a double
>arithmetic right shift of 32 bits.  If you clear the odd register
>and right shift less than 32 bits the quotient will have the binary
>point in a different place.

>So, since you have to do the shift anyway, the only difference is
>that it isn't 32 bits.  If you don't shift at all and clear the odd
>register, the quotient has 32 bits after the binary point, though
>it is easy to overflow in that case.

These days there are sign extension instructions on some systems,
so the shift may not be required at all.


0
robin_v (2737)
8/27/2005 1:40:16 AM
David Frank wrote in message <7OEOe.627$_84.612@newsread1.news.atl.earthlink.net>...
>
>"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
>news:57CdnaTewo2W95TeRVn-gg@comcast.com...
>> David Frank wrote:
>> (snip)
>>
>> The array operators are nice, and PL/I has them, too, but sometimes
>> they can result in much more work being done than without array
>> operators.
>>
>> -- glen
>>
>
>And the reason you wont respond to my pointing out PL/I doesnt support array
>sub-scripting IS ?
>e.g.    a(2:)

I have demonstrated for you in this forum PL/I codes using this notation.

>Folks, this is typical PLI'er clamming-up anytime I expose another Fortran
>superiority fact that contradicts:
>"PL/I has more power than Fortran-90"  -- R. VOWELS  PL/I -FAQ

On the contrary, because PL/I can do this, and much more including
accepting Fortran source statements
intermixed with PL/I source (also demonstrated in this forum)
demonstrates the superiority of PL/I.




0
robin_v (2737)
9/16/2005 12:23:42 AM
Reply:

Similar Artilces:

Nvidia and Reduced Blanking
Hello: I'm trying to get an HP 2335 flat panel display to work with an Nvidia Geforce 5500 FX. If I use an analog cable all works very well and I can run X with 1920x1200 using the default mode selected by Xorg. With the DVI-D cable things get more complicated, though. Up to 1600x1200 resolution everything works perfectly with the default settings. For 1920x1200, however, I need reduced blanking which doesn't seem to be an Xorg default mode. That's where the trouble starts. The monitor manual says that 1920x1200 should be run at 154.0 MHz, 74.04 kHz, 60.0 Hz. From thes...

re: Reduce blanks
>David Frank wrote in message ... > >"Tim Challenger" <tim.challenger@aon.at> wrote in message >news:1124699765.17b90c8dbed03e32764504cabd3dc93d@teranews... >> On Sun, 21 Aug 2005 16:41:43 GMT, David Frank wrote: >> >>>> I think that this will do it in PL/I :- >>>> >>>> line = pack (a, (a^=' ') | (b ^= ' '), rank(0) ); >>>> >>> >>> I think NOT >>> Did you forget you cross-posted and are being read by REAL programmers >>> here >>> in comp.lang.fortran? >>> >>> Arent you embarrassed to post fictitious PL/I syntax? >> >> The syntax is valid PLI. >> >>> 1. There is no PL/I pack function >> >> But PACK could be a user-function. Which you yourself said is allowed. > >Thats absolutely true and I considered whether there was ANY possibility >that PL/I syntax supported writing a user PACK function and it boggled my >imagination so much I broke out laffing. >Otoh, my generic Copy function WAS written and can be viewed: > http://home.earthlink.net/~dave_gemini/strings.f90 Your Copy function is NOT generic. Yes it is, but not in the usual sense. It barely meets the requirements of a generic procedure, namely of accepting different forms of argument (e.g., KIND, scalar, array(s)) for the same purpose [e.g., of converting an array to a string]. DF's f...

Blank is not blank but some other character?
Hi All, I have a data which seems to be blank space but on trying length(compress(Variable)) its not coming to be 1 but is more than one indicating that the value which seems to be blank but is some other character which seems in SAS as blank. Please help its urgent! Thanks. As this is urgent I did is as fast as could. You can use COMPRESS and (K)eep the (W)ritable characters this way you don't necessarily need to figure out what the offending character is. data _null_; length x $8; x = cat('A ','19'x,'B');; l = length(x); c1 = compress(x); l2 = length(c1); c2 = compress(x,,'KW'); l2 = length(c2); put 'NOTE: The results' @; put (_all_)(= / 'NOTE- '); run; On 10/8/08, nichas <sachin.gadkar@gmail.com> wrote: > Hi All, > > I have a data which seems to be blank space but on trying > length(compress(Variable)) its not coming to be 1 but is more than one > indicating that the value which seems to be blank but is some other > character which seems in SAS as blank. > > Please help its urgent! > > Thanks. > On 8 Oct, 17:09, nichas <sachin.gad...@gmail.com> wrote: > Hi All, > > I have a data which seems to be blank space but on trying > length(compress(Variable)) its not coming to be 1 but is more than one > indicating that the value which seems to be blank but is some other > character which seems in SAS as blank. > > Please hel...

reduce/reduce conflict
Hi, I'm currently writing a grammar for a C/Pascal-like language using btyacc (bactracking yacc). The grammar is free from conflicts except for 1 shift/reduce conflict. When I tried using inherited attributes I got 1 reduce/reduce conflict. Is there any way I can get rid of it without having to rewrite the grammar ? [No. -John] TJB wrote: > > Hi, > > I'm currently writing a grammar for a C/Pascal-like language using > btyacc (bactracking yacc). The grammar is free from conflicts except > for 1 shift/reduce conflict. When I tried using inherited attributes I > got...

how to reduce the blank space under subfigures ?
Dear all, I am trying to reduce the blakn space under subfigures. For example, I am having the following figures: \begin{figure}[hb]\center\vspace{-0.36cm} \mbox{ \subfigure[]{\epsfig{file=curve1.eps, scale=0.22}} \quad \subfigure[]{\epsfig{file=curve2.eps, scale=0.22}} }\vspace{-0.16cm} \caption{\footnotesize text text text text text} \label{fig_curves} \end{figure} The figure layout is like the following: ___________________ | | | Figures | |__________________| (a) (b) (c) Fig. 1 Caption text text text. Other text text text text. Now I can reduce the vertical space before figures, after (a)(b)(c), after caption, but I tried my best but I cannot reduce white space between "figures" and "(a)(b)(c)"... Anybody know how to do it? Thanks a lot -Jeonyim On Thu, 29 Jan 2004 17:22:35 -0500, Joenyim Kim wrote: > Dear all, > > I am trying to reduce the blakn space under subfigures. For example, I am > having the following figures: > > \begin{figure}[hb]\center\vspace{-0.36cm} > \mbox{ > \subfigure[]{\epsfig{file=curve1.eps, scale=0.22}} \quad > \subfigure[]{\epsfig{file=curve2.eps, scale=0.22}} > }\vspace{-0.16cm} > \caption{\footn...

reg debugging shift/reduce and reduce/reduce conflicts
Hi Everyone, I'm trying to develop a parser for a vCard decoder, i'm using lex and yacc. And to satisfy few type pf vCards i modifed a grammar and it resulted in shift/reduce and reduce/reduce conflicts. I used -v option of yacc to generate a y.output file and I was able to understand only a bit of the file... 141: shift/reduce conflict (shift 221, red'n 239) on 10 I understand that the conflict is in 141 state and yacc is in a confusion on token 10 as to whether shift to 221 state or reduce using a rule 239... this is followed by some grammar rules from Yacc and the...

Re: challenge: remove blanks subroutine
"David Frank" <dave_frank@hotmail.com> wrote in message news:<uhpXa.14512> > > > I was curious to try a comparison (for this string compression) > > between SUBSTR and arrays, so I wrote some code: > > > > DCL 1 String UNION, > > 2 S CHARACTER (32767), > > 2 T (32767) CHARACTER (1); > > > > =====================SUBSTR version======================== > > > > /* Compress in place. */ > > J = 0; > > DO K = 1 TO LENGTH (S); > > IF SUBSTR (S, K, 1) ^= ' ' THEN > > DO; > > J = J + 1; > > SUBSTR(S, J, 1) = SUBSTR (S, K, 1); > > END; > > END; > > > > ===============Array version=============================== > > > > /* Compress in place. */ > > J = 0; > > DO K = 1 TO LENGTH (S); > > IF T(K) ^= ' ' THEN > > DO; > > J = J + 1; > > T(J) = T(K); > > END; > > END; > > > > > > The SUBSTR was a tad faster with no optimization, > > and the array method was a tad faster with full optimization. > > > > Above isnt ready for prime-time, since it isnt a complete program > showing problems PL/I may have with string as an arg to un-shown &g...

Re: challenge: remove blanks subroutine
"David Frank" <dave_frank@hotmail.com> writes: > > Sooo, can anyone write a remove blanks subroutine that uses inplace > moves in/out to its string argument? > I'll show you mine, if you show me yours.. Two solutions were posted days ago in July. Date: Thu, 31 Jul 2003 14:12:06 GMT "Glen Herrmannsfeldt" <gah@ugcs.caltech.edu> writes: > > Yes, but if the megabytes are being moved inside a loop, it can really add > up. I think I already wrote this somewhere in the discussion, but I once > debugged a C program that removed blanks...

page layout reducing blank space between figures
Pals, I would like to know if it is possible to solve the following situation: 2 figures are floated to the next page of my text. The figures are rather large but not large enough to use the whole page. So there is still room for more text. But whatever I try the add text to the page, LaTeX does not allow that and keeps only the figures with a lot of blank space in the top of the page, between them and at the bottom of the page. _________________ | | | | | | | figure | | | | | | figure | | | | | __________________ Is there any way to overcome this nuisance? Oscar "Oscar Rotava" <rotava@petrobras.com.br> writes: > 2 figures are floated to the next page of my text. The figures are > rather large but not large enough to use the whole page. LaTeX's default judgement on this matter is contrary to yours. Set LaTeX straight by setting \textfraction, \floatpagegraction, and \topfraction. See the FAQ (or google for those three). -- Donald Arseneau asnd@triumf.ca ...

Re: challenge: remove blanks subroutine #4
"David Frank" <dave_frank@hotmail.com> writes: > > "Paul van Delst" <paul.vandelst@noaa.gov> wrote in message > news:3F3017BE.A3344923@noaa.gov... > > David Frank wrote: > > > > > > Heres my latest/greatest/smallest S2P function (6 statements complete, > > > what you see is what you get).. > > > > Umm.... your function: > > > > > function S2P(s,n) result(p) > > > integer :: n > > > character :: s(n) > > > character,pointer :: p(:) > > > > is different fr...

Reduce blank in subplot when using axis square
Hi all, I need help. I would like to plot 6 subplot (3,2,i) where y-axis has the same length as x-axis. To do so, I used the axis square option like this: for i=1:6 a{i}=randn(1,20) b{i}=randn(1,20) subplot(3,2,i) plot(a{i},b{i}) axis square end The problem is that gaps between neighbouring (horizontal) axes are too big (too many blank). How could I solve this problem ? Thank you D. ...

Re: challenge: remove blanks subroutine #3
> From: "David Frank" <dave_frank@hotmail.com>, RoadRunner - Central Florida > Date: Tue, 05 Aug 2003 20:05:09 GMT > Heres my latest/greatest/smallest S2P function (6 statements complete, > what you see is what you get).. The whole caboose is entirely worthless for 2 reasons: 1. As James Giles has told you, the function S2P relies for its apparent "working" on a bug in your version of your Fortran compiler. Function S2P fails to compile, yielding the message: *** S is neither a POINTER nor a TARGET 2. There is a conflict between the procedure S...

[sed/awk] reduce multiple blank lines to one
Some emails I receive have multiple blank lines. I'd like to add a procmail filter that removes multiple blank lines to just one. Was thinking a sed or awk command would be best, but I just am such a novice at both of them. Any ideas from you experts? -- Troy Piggins On 2010-01-04, Troy Piggins <usenet-1001@piggo.com> wrote: > Some emails I receive have multiple blank lines. I'd like to add > a procmail filter that removes multiple blank lines to just one. > Was thinking a sed or awk command would be best, but I just am > such a novice at both of th...

double blanks, triple blanks.....
are there other languages (not mathematica) which implement double blanks, triple blanks, .. , ... , for searching patterns? Which is more similar in this aspect? thanks. You could try (the language) ML. at: http://www.smlnj.org/ Nerver liked it much myself, but you may. There is a lisp library that implements something along the manner you suggest. It is called screamer and is part of the clocc library. I found it at: http://cvs.sourceforge.net/viewcvs.py/clocc/clocc/src/screamer On 13 May 2004 01:01:21 -0700, giorgio borghi <gimbo20032003@libero.it> wrote: > are there othe...

Re: Blank is not blank but some other character?
try $hex. format to see what's the underline value. On Wed, 8 Oct 2008 09:09:09 -0700, nichas <sachin.gadkar@GMAIL.COM> wrote: >Hi All, > >I have a data which seems to be blank space but on trying >length(compress(Variable)) its not coming to be 1 but is more than one >indicating that the value which seems to be blank but is some other >character which seems in SAS as blank. > >Please help its urgent! > >Thanks. ...

Why xml:lang instead of lang?
What was the reason to introduce a new attribute "xml:lang" instead of "lang"? This bothers both authors and browsers in different language versions: HTML 4, XHTML 1.0, XHTML 1.1. HTML has only "lang"; XHTML 1.1 has only "xml:lang"; XHTML 1.0 has both! For example, Mozilla 1.7 recognizes the lang attribute http://www.unics.uni-hannover.de/nhtcapri/temp/lang-attribute.htm but it does not recognize the xml:lang attribute. http://www.unics.uni-hannover.de/nhtcapri/temp/lang-attribute.xhtml What do we gain from "xml:lang"? Andreas Prilop wrote: > What was the reason to introduce a new attribute "xml:lang" > instead of "lang"? > What do we gain from "xml:lang"? By putting the attribute in the general and predefined namespace http://www.w3.org/XML/1998/namespace it can be used by any XML application (e.g. XHTML, SVG) without any further effort and without any danger of colliding with attributes in no namespace a particular XML application might want to define. -- Martin Honnen http://JavaScript.FAQTs.com/ Andreas Prilop wrote: > What was the reason to introduce a new attribute "xml:lang" > instead of "lang"? Since it is useful to have a means of describing language in the core of XML. It only looks silly from an (X)HTML-centric viewpoint. -- David Dorward http://dorward.me.uk/ In article <Pine.GSO.4.44.0603311415390.8640-100000@s5b004.rrzn.u...

Bison reduce/reduce problem
Hello. I have been trying to figure out how to solve some of these reduce/reduce errors in bison and have looked through their manual on it and still don't have much luck. So, here is their example changed to show the type of problem I am having. %token ID %% def: param_spec {} | return_spec ',' {} ; param_spec: type {} | name_list ':' type {} ; return_spec: type {} | name ':' type ...

Blank
-- "Senator Obama has never been a Muslim, was not raised a Muslim, and is a committed Christian" http://my.barackobama.com/page/content/fightthesmearshome/ "...n 1971, Obama enrolled in the Besuki Primary School, a government school, as Barry Soetoro, Muslim" http://web.israelinsider.com/Articles/Politics/12745.htm ""In the Muslim school, the teacher wrote to tell mother I made faces during Koranic studies."" From "Dreams From My Father" Barack Obama's autobigraphy In article <e6pad456sg371sjnp9o3olmedlhf1ad8cb@4ax.com>, Mayor of R'lyeh <mayor.of.rlyeh@gmail.com> wrote: Did your brain blank out again, Clyde? Trying to think again? Typical of Wintrolls. ...

lang
fortran ...

Blank
Blank "G. Lee" <chips2rose@gmail.com> schrieb im Newsbeitrag news:42db5c68$0$2684$7a214f24@news.kaist.ac.kr... > Blank .... blank, blank ... Hans Herrmann wrote: > "G. Lee" schrieb: > > Blank > ... blank, blank ... % string repeat "" [expr int(pow(2,30))] -- MKS blank "G. Lee" <chips2rose@gmail.com> wrote in message news:42db5c68$0$2684$7a214f24@news.kaist.ac.kr... > Blank blank "Melissa Schrumpf" <m_schrumpf_at_yahoo_com_NOT@microsoft.com> wrote in message news:m_schrumpf_at_yahoo_com_NOT-34CD4B.08093218072005@comcast.dca.giganews.com... > Hans Herrmann wrote: > >> "G. Lee" schrieb: > >> > Blank > >> ... blank, blank ... > > % string repeat "" [expr int(pow(2,30))] > > -- > MKS ...

A Lange & Sohne Lange 1 Watches: Quality A Lange & Sohne Discount Watches
A Lange & Sohne Lange 1 Watches: Quality A Lange & Sohne Discount Watches Quality A Lange & Sohne Lange 1 Watches http://a-lange-sohne-watches.pxhelp.com/a-lange-sohne-lange-1.html Thank you for choosing http://www.pxhelp.com/ Discount A Lange & Sohne Watches http://a-lange-sohne-watches.pxhelp.com/ We guarantee our A Lange & Sohne Lange 1 Watches and A Lange & Sohne Lange 1 Luxury Watches aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Lange 1 Watch produced is examined carefully by ...

A Lange & Sohne Grand Lange 1 Watches: Quality A Lange & Sohne Discount Watches
A Lange & Sohne Grand Lange 1 Watches: Quality A Lange & Sohne Discount Watches Quality A Lange & Sohne Grand Lange 1 Watches http://a-lange-sohne-watches.pxhelp.com/a-lange-sohne-grand-lange-1.html Thank you for choosing http://www.pxhelp.com/ Discount A Lange & Sohne Watches http://a-lange-sohne-watches.pxhelp.com/ We guarantee our A Lange & Sohne Grand Lange 1 Watches and A Lange & Sohne Grand Lange 1 Luxury Watches aren't just a simple imitation. We use the same fine materials and technology that the original does. Each A Lange & Sohne Grand Lange 1 Watc...

Report footer on separate page; optionally hide it, reduce total page count by 1, and don't print last (blank) page
Different users of the app will want or not want to see report footer ( appears as a separate page). I can make the section invisible with a DLookup of a Y or N value from a 'parameters' table Private Sub ReportFooter_Format(Cancel As Integer, FormatCount As Integer) Reports!rptValuationDetail.Section(acFooter).Visible = _ DLookup("[z_text]", "sysparms", "[z_pname] = " & Chr(34) & "printReportGrandTot" & Chr(34)) = "Y" End Sub The next thing to do is reduce the total page count by 1 and not create the last pag...

Re: Blank is not blank but some other character? #3
Nichas - With a $hex format you can discover what the offending character is... data chars; badvar='a strange '||'0A'x ||' char';; badchar=compress(badvar,,'w'); put badchar $hex2.; run; ASCII table at... http://www.asciitable.com/ hth- Paul Choate DDS Data Extraction (916) 654-2160 -----Original Message----- From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of ./ ADD NAME=Data _null_, Sent: Wednesday, October 08, 2008 9:45 AM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: Blank is not blank but some other character? As this is urgent I did is as fast as could. You can use COMPRESS and (K)eep the (W)ritable characters this way you don't necessarily need to figure out what the offending character is. data _null_; length x $8; x = cat('A ','19'x,'B');; l = length(x); c1 = compress(x); l2 = length(c1); c2 = compress(x,,'KW'); l2 = length(c2); put 'NOTE: The results' @; put (_all_)(= / 'NOTE- '); run; On 10/8/08, nichas <sachin.gadkar@gmail.com> wrote: > Hi All, > > I have a data which seems to be blank space but on trying > length(compress(Variable)) its not coming to be 1 but is more than one > indicating that the value which seems to be blank but is some other > character which seems in SAS as blank. > > Please help its urgent! > > Thanks. > ...

Web resources about - Reduce Blanks challenge - comp.lang.pl1

Challenge - Wikipedia, the free encyclopedia
Text is available under the Creative Commons Attribution-ShareAlike License ;additional terms may apply. By using this site, you agree to the ...

Senator Bob Day in High Court challenge against Senate voting reforms
Two senators facing potential political death will launch a High Court challenge to voting laws ahead of an imminent federal election.

NSW protest laws may face legal challenge
Controverisal new anti-protest laws passed in NSW may face a challenge in the High Court.

High Court challenge against Senate voting reforms launched by Bob Day
Key senate crossbencher Bob Day is launching a High Court challenge against the laws changing the way Australians vote for senators.

Senator Bob Day in High Court challenge against Senate voting reforms
Two senators facing potential political death will launch a High Court challenge to voting laws ahead of an imminent federal election.

Senate voting reform: Bob Day to challenge legislation over exhausted votes concerns
Family First senator Bob Day will be taking the Government's new Senate voting laws to the High Court next week.

Look Who’s Leading the TVNewser Bracket Challenge After Day One
The first day of the NCAA Tournament always brings the Madness, and this year was no different. After Little Rock’s upset of Purdue, all but ...

Cruz: No Surprise Trump ‘Is Trying To Stir Up Riots,’ Challenges Him To Debate in DC
Cruz: No Surprise Trump 'Is Trying To Stir Up Riots,' Challenges Him To Debate in DC

All over the world, people are overcoming huge challenges to make a career in video games
At this week's Game Developers Conference in San Francisco, a panel of game developers and critics gathered for the fourth annual #1ReasonToBe ...

Case challenges big Obamacare reimburse
The Obama administration is accused of illegally giving insurers reimbursement to cut Obamacare customer out-of-pocket costs.

Resources last updated: 3/19/2016 6:47:18 PM