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

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.

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
>| 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:


 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.


 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
>>
>>                "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:
|

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:
>> |
>>
>> 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
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.


 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

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

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?
>

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:)/='
>
> 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
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
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

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.

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  fill1 7 .lcomm I 4 .lcomm .T2_ 4 .rdata .align 01:
.long   0x3F800000 # .float 1.000000
.long   0x40A00000 # .float 5.000000
.byte   0 : 8
.section .drectve1 ".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)
>
> bounds_1
> Microsoft (R) Incremental Linker Version 6.00.8447
>
> /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
> 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
> 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:) /= ' ',


 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:) /= '

>> 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
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
"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
>>
>>
>> accordingly to use    PACK (  a(2:),  a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /= '
>>
>> 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
>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
>>>
>>>
>>>accordingly to use    PACK (  a(2:),  a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /='
>>>
>>>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
>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.
>>
>>
>>
>> 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
>>>"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
>"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

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. ...

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