Home > Archive > Fortran > August 2005 > Final Reduce_Blanks function?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Final Reduce_Blanks function?
|
|
| David Frank 2005-08-23, 7:57 am |
| My previous
outline = line(1:1) // Copy( Pack( a(2:), a(2:)/=' '.or.a(1:len(line)-1)/='
', pad )
altho faster/more legible/briefer than giles function, still LOOKs a
little nasty due to the concatenation and a little mess in the Pack args..
Sooo below
1. maintains 3% speed advantage.
2. increases legibility by eliminating concatenation
3. maintains statement count advantage
outline = Copy (Pack( a(1:), a(1:)/=' '.or.a(0:n) /= ' ', pad ) ! TA
DA finished ?
http://home.earthlink.net/~davegemini/test.f90
for testing source acceptable to CVF,
but due to the BUG discovered with CVF in Pack args, that isnt conclusive
so eye-ball it yourself.
| |
|
|
| Herman D. Knoble 2005-08-23, 7:57 am |
| For information, when test.f90 is run using ifort V9 on an Opteron
with O2 (default) optimization I get the following reproducible timing:
frank 0.98 | a b c d e f g h i j k l m n o p q r s t u v w x y z |
giles 1.17 | a b c d e f g h i j k l m n o p q r s t u v w x y z |
I also ran the code through Lahey LF95 with: --checkglobal
and it ran there with no bounds checks or ununitialized variables.
Timings are relative. Absolute figures like above differ by platform.
Skip
On Tue, 23 Aug 2005 12:15:55 GMT, "David Frank" <dave_frank@hotmail.com> wrote:
-|My previous
-|outline = line(1:1) // Copy( Pack( a(2:), a(2:)/=' '.or.a(1:len(line)-1)/='
-|', pad )
-|
-|altho faster/more legible/briefer than giles function, still LOOKs a
-|little nasty due to the concatenation and a little mess in the Pack args..
-|
-|Sooo below
-|1. maintains 3% speed advantage.
-|2. increases legibility by eliminating concatenation
-|3. maintains statement count advantage
-|
-|outline = Copy (Pack( a(1:), a(1:)/=' '.or.a(0:n) /= ' ', pad ) ! TA
-|DA finished ?
-|
-|http://home.earthlink.net/~davegemini/test.f90
-|
-|for testing source acceptable to CVF,
-| but due to the BUG discovered with CVF in Pack args, that isnt conclusive
-|so eye-ball it yourself.
-|
| |
| David Frank 2005-08-23, 7:00 pm |
|
"Herman D. Knoble" <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote in message
news:786mg1hnn4sequoqhvrjtfqu8u3h9danf1@
4ax.com...
> For information, when test.f90 is run using ifort V9 on an Opteron
> with O2 (default) optimization I get the following reproducible timing:
>
> frank 0.98 | a b c d e f g h i j k l m n o p q r s t u v w x y z |
> giles 1.17 | a b c d e f g h i j k l m n o p q r s t u v w x y z |
>
> I also ran the code through Lahey LF95 with: --checkglobal
> and it ran there with no bounds checks or ununitialized variables.
>
> Timings are relative. Absolute figures like above differ by platform.
>
> Skip
>
Skip, thanks for running http://home.earthlink.net/~dave_gemini/test.f90
on your Opteron
I am restoring the cross-post to comp.lang.pl1, as your results are a final
coda to what has been a fun exercise for this old-fart, that is
out-Fortran'ing the young bloods AGAIN !!
| |
| Rich Townsend 2005-08-23, 7:00 pm |
| David Frank wrote:
> "Herman D. Knoble" <SkipKnobleLESS@SPAMpsu.DOT.edu> wrote in message
> news:786mg1hnn4sequoqhvrjtfqu8u3h9danf1@
4ax.com...
>
>
>
> Skip, thanks for running http://home.earthlink.net/~dave_gemini/test.f90
> on your Opteron
>
> I am restoring the cross-post to comp.lang.pl1, as your results are a final
> coda to what has been a fun exercise for this old-fart, that is
> out-Fortran'ing the young bloods AGAIN !!
>
>
On a 1.6Ghz Pentium M Dothan, running Gentoo Linux:
frank 4.42 | a b c d e f g h i j k l m n o p q r s t u v w x y z |
giles 4.24 | a b c d e f g h i j k l m n o p q r s t u v w x y z |
The fat lady has sung. Now let's go home.
cheers,
Rich
| |
| James Giles 2005-08-23, 7:00 pm |
| Rich Townsend wrote:
> On a 1.6Ghz Pentium M Dothan, running Gentoo Linux:
>
> frank 4.42 | a b c d e f g h i j k l m n o p q r s t u v w x y z |
> giles 4.24 | a b c d e f g h i j k l m n o p q r s t u v w x y z |
On my machine as well, I get consistently faster results than DF's.
I use a larger variety of test strings and test for a larger number
of cycles. My timings are consistent within about half a
percent from one run to the next. My solutions are consistently
about 7 to 8 percent faster than DF's newest one (announced in
this new thread) with one exception.
I say my "solutions" because I tried all the red-herrings that
DF consistently misleads with. I tried OR instead of AND
(that is, I applied DeMorgan's rule, reversed the sense of the
compare, used OR and removed the NOT operator), with no
discernable change in the speed of my code. I tried testing
each character twice, like DF's does, and got a 7 to 8 percent
slowdown in my version of the code - to match DF's poor
performance. I tried padding with nulls instead of (the
correct) blanks, no change in the speed (just a lack of correct
results). I tried using a PAD argument to PACK instead of
using a separate statement to fill trailing elements of the result,
with no change in speed.
The only *positive* change was with replacing TRANSFER
with COPY, and only when the compiler was CVF (and even
then, only if the COPY routines were in a MODULE - if they
were external procedures or were internal to the main routine
with the other test procedures, they slowed the code down).
Evidently CVF doesn't implement TRANSFER very well if
a simple-minded scalar loop to move the characters is faster
than the semantically equivalent TRANSFER. *
When I look at the assembly code generated by CVF (6.6c
with no options used from the command line), DF's version
quite clearly does more work than mine (except for the one
where I also double-tested each character). It clearly does
*NOT* short-cut the ORs. That remains the major speed
difference between his slower code and my faster, more
legible versions.
"Look, I took the liberty of examining that parrot, and I
discovered that the only reason that it had been sitting on
its perch in the first place was that it had been nailed there."
- John Cleese
Well, I took the liberty of examining DF's claims very carefully
and found them similarly lacking. And this thread is about as
dead a parrot as we're likely to get.
--
*
When TRANSFER was first debated by the Fortran
committee, I remember one of the claims filtering out
to us ouside the committee room was that it was very
cheap. "In many uses it would even be a no-op! At worst,
it would be as fast as the most efficient way of moving raw
data on a given platform." CVF seems to have messed up
on that.
And, speaking of simple scalar loops. My original scalar
loop solutions to this problem are *both* faster than DF's
current version - by more than 40%. Even on CVF (6.6c,
compiled from the command line with no options). And
both are more legible too.
--
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
| |
| David Frank 2005-08-23, 7:00 pm |
|
"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:NpLOe.660732$cg1.179337@bgtnsc04-news.ops.worldnet.att.net...
> My solutions are consistently about 7 to 8 percent faster
I note you dont identify your machine/compiler, you afraid someone will
double-check your results?
| |
| James Giles 2005-08-23, 7:00 pm |
| David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:NpLOe.660732$cg1.179337@bgtnsc04-news.ops.worldnet.att.net...
>
>
> I note you dont identify your machine/compiler, you afraid someone
> will double-check your results?
Compiler: CVF 6.6c (used from the command line with no
options specified - as stated clearly *twice* in the very article
you claim I didn't mention it in). And an old AMD 1.2 GHz
Athlon (as previously stated in my first article in this bogus
challenge).
--
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
| |
| David Frank 2005-08-23, 7:00 pm |
|
"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:NpLOe.660732$cg1.179337@bgtnsc04-news.ops.worldnet.att.net...
> I tried testing each character twice, like DF's does,
Thats crap and you know it, CVF short-circuits ORs see below...
Here is a extracted reduce_blanks_frank_1 from reduce.f90 which has the
FASTEST run time on my machine, see:
http://home.earthlink.net/~dave_gemini/reduce.f90
DOES ANYONE agree that Giles flag-setting is more legible that my simple 2
char test below?
! ---------------------------------
function reduce_blanks_frank_1(line) result (outline)
character(*) :: line
character(len(line)) :: outline
integer :: i, n
outline(1:1) = line(1:1) ; n = 1 ! always output col. 1
do i = 2,len(line)
if (line(i:i) /= ' '.OR.line(i-1:i-1) /= ' ') then
n = n+1 ; outline(n:n) = line(i:i)
end if
end do
outline(n+1:n+1) = char(0) ! C string out saves trailing blank, if present
end function reduce_blanks_frank_1
Here is the IF statement's above ASSY code, note the JUMPS after the tests
for ' '
mov ebx, edi ; 000008
movzx ecx, byte ptr .data$+4[ebx]
cmp ecx, 32
jne lab$0007 looks like a short circuited OR jump to me
movzx eax, byte ptr .data$+3[ebx]
cmp eax, 32
je lab$0009
| |
| James Giles 2005-08-23, 9:57 pm |
| David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:NpLOe.660732$cg1.179337@bgtnsc04-news.ops.worldnet.att.net...
>
>
> Thats crap and you know it, CVF short-circuits ORs see below...
Obviously CVF has *LOTS* of problems with character
data and no solid conclusions are possible except that
varying the target machine causes it to generate differently
sub-optimal code.. On my machine, the generated code
definitely *DOES*NOT* shortcut the ORs. Nor is the code
you present the most efficient way to run this code (my s
imple scalar loop is).
--
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
| |
|
| David Frank wrote in message
>My previous
>outline = line(1:1) // Copy( Pack( a(2:), a(2:)/=' '.or.a(1:len(line)-1)/='
>', pad )
>
>altho faster/more legible/briefer than giles function, still LOOKs a
>little nasty due to the concatenation and a little mess in the Pack args..
>
>Sooo below
>1. maintains 3% speed advantage.
>2. increases legibility by eliminating concatenation
>3. maintains statement count advantage
>
>outline = Copy (Pack( a(1:), a(1:)/=' '.or.a(0:n) /= ' ', pad ) ! TADA
finished ?
And what is n ?
| |
|
|
| David Frank 2005-08-24, 3:57 am |
|
"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:Y_OOe.128396$5N3.106942@bgtnsc05-news.ops.worldnet.att.net...
> David Frank wrote:
>
> Obviously CVF has *LOTS* of problems with character
> data and no solid conclusions are possible except that
> varying the target machine causes it to generate differently
> sub-optimal code.. On my machine, the generated code
> definitely *DOES*NOT* shortcut the ORs. Nor is the code
> you present the most efficient way to run this code (my s
> imple scalar loop is).
>
You are itching to explain but p.o.'ed that NO-ONE has asked you whats
happening inside your giles_1 scalar loop
function.. SIMPLE is not the word to describe it
Anyone want to see what JG calls simple, see his Giles_1 and compare with
my SIMPLE Frank_1
http://home.earthlink.net/~davegemini/reduce.f90
| |
| David Frank 2005-08-24, 3:57 am |
| http://home.earthlink.net/~dave_gemini/reduce.f90
and while I'm here making the usual link correction, pls explain
If my CVF short-cuts ORs WHY doesnt your CVF short-cut ORs ?
I post code proving it doesnt, where is your proof it does?
re: >> On my machine, the generated code definitely *DOES*NOT* shortcut
the ORs.
| |
| David Frank 2005-08-24, 3:57 am |
| 2 bad responses from me this morning BEFORE I have my 1st cup of coffee.
"David Frank" <dave_frank@hotmail.com> wrote in message
news:V8WOe.1263$_84.505@newsread1.news.atl.earthlink.net...
> http://home.earthlink.net/~dave_gemini/reduce.f90
>
> and while I'm here making the usual link correction, pls explain
> If my CVF short-cuts ORs WHY doesnt your CVF short-cut ORs ?
>
> I post code proving it doesnt, where is your proof it does?
>
I post code proving it DOES, where is your proof it does NOT?
| |
| James Giles 2005-08-24, 6:59 pm |
| David Frank wrote:
.....
> You are itching to explain but p.o.'ed that NO-ONE has asked you
> whats happening inside your giles_1 scalar loop
> function.. SIMPLE is not the word to describe it
Simple is *exactly* the word to describ it:
Pure function reduce_blanks_jlg_1(in_str) result(out_str)
Implicit none
Character(*), intent(in) :: in_str
Character(len(in_str)) :: out_str
Integer :: dest, source, blanks
blanks = 0
dest = 1
Do source = 1, len(in_str)
blanks = merge(0, blanks+1, in_str(source:source)/=" ")
If(blanks > 1) Cycle
out_str(dest:dest) = in_str(source:source)
dest = dest+1
End do
out_str(dest:) = " "
End function reduce_blanks_jlg_1
Here, there is *obviously* *ONE* and only *ONE* loop.
(All DF's solutions involve at least 4 loops, at least two
hidden is his pair of COPY calls.) It *obviously* processes
each input character once. If CVF's optimization wasn't
buggy, this would be the fastest without any further
modification.
--
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
| |
| James Giles 2005-08-24, 6:59 pm |
| David Frank wrote:
> 2 bad responses from me this morning BEFORE I have my 1st cup of
> coffee.
>
> "David Frank" <dave_frank@hotmail.com> wrote in message
> news:V8WOe.1263$_84.505@newsread1.news.atl.earthlink.net...
>
> I post code proving it DOES, where is your proof it does NOT?
I could post the assembly that it generates, but you would
accuse me of writing it by hand. I the presence of the
dishonest, there is no way to prove by mere testimony.
Let others actually *try* *it*, most will find thart I'm
right.
--
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
| |
| David Frank 2005-08-25, 6:59 pm |
| Sooo, can anyone supply my reduce_blanks function code thats been deleted?
I'm sure it runs faster than my fastest routine, AND doesnt need my
string_functions module
AND outputs 0 or 1 trailing blank..
! ---------------
program test
character(40) :: line = ' the quick brown fox jumps '
write (*,*) '|', line(1:reduce_blanks(???), '|' ! outputs | the quick
brown fox jumps |
stop
contains
??? so whats my CVF code thats deleted here?
end program
| |
| David Frank 2005-08-25, 6:59 pm |
|
> Sooo, can anyone supply my reduce_blanks function code thats been
> deleted?
> I'm sure it runs faster than my fastest routine,
OK, I found a way to time this slick-sucker, it lowers my FASTEST runtime
from 0.59 to 0.17 sec
see previous timings: http://home.earthlink.net/~dave_gemini/reduce.f90
Otoh your "obscure" not "simple" Giles_1 routine is 4x slower,
I wouldnt be surprised that my new function can even be grasped/read by
the dynamic-duo Townsend and Vowels
| |
| Rich Townsend 2005-08-25, 6:59 pm |
| David Frank wrote:
>
>
> OK, I found a way to time this slick-sucker, it lowers my FASTEST runtime
> from 0.59 to 0.17 sec
> see previous timings: http://home.earthlink.net/~dave_gemini/reduce.f90
>
> Otoh your "obscure" not "simple" Giles_1 routine is 4x slower,
>
> I wouldnt be surprised that my new function can even be grasped/read by
> the dynamic-duo Townsend and Vowels
>
>
On my 1.6GHz Pentium M, using Intel ifort:
Frank_1 1.41 sec | the quick brown fox jumps |
Frank_2 1.36 sec | the quick brown fox jumps |
Giles_1 0.52 sec | the quick brown fox jumps|
Giles_2 1.76 sec | the quick brown fox jumps|
Chandler 0.55 sec | the quick brown fox jumps|
NucWiz 0.98 sec | the quick brown fox jumps|
Vanbuskirk 7.67 sec | the quick brown fox jumps|
FJRA 3.00 sec | the quick brown fox jumps|
I may not be able to read the code; but I can read its output, which
shows Giles_1 wiping the floor with both of DF's attempts.
Yours, superbly happily,
Rich
| |
| David Frank 2005-08-25, 6:59 pm |
|
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:del665$6ej$1@scrotar.nss.udel.edu...
>
> I may not be able to read the code
And I wish him luck in his continued journey toward being able to read
Fortran.programs.
| |
| Rich Townsend 2005-08-25, 6:59 pm |
| David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:del665$6ej$1@scrotar.nss.udel.edu...
>
>
>
>
> And I wish him luck in his continued journey toward being able to read
> Fortran.programs.
I was being sarcastic. Whereas, you inability to program correct Fortran
has been demonstrated in this very forum, on multiple occasions, by
yourself.
Surely, there's a better way to spend your retirement than ruining your
credibility in a public forum?
cheers,
Rich
| |
| David Frank 2005-08-25, 6:59 pm |
|
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:delcjm$85t$1@scrotar.nss.udel.edu...
> David Frank wrote:
>
> I was being sarcastic. Whereas, you inability to program correct Fortran
> has been demonstrated in this very forum, on multiple occasions, by
> yourself.
>
> Surely, there's a better way to spend your retirement than ruining your
> credibility in a public forum?
>
> cheers,
>
> Rich
So you think I havent as yet "ruined my credibility" otoh, what are you
doing here,
you cant read fortran, you cant come up with my "deleted" source challenge,
etc.. etc.
| |
| Richard E Maine 2005-08-25, 6:59 pm |
| In article <delcjm$85t$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
> Surely, there's a better way to spend your retirement than ruining your
> credibility in a public forum?
If I may offer some advice, I'd suggest recalling the adage about
wresting with pigs. I.E. "Never wrestle with a pig. You'll both get
dirty and only the pig will enjoy it."
Flame wars like this are "no-win" situations. You can't help your
reputation by "winning" one; you can hurt it. As in the quote from "War
Games" about thermonuclear war, "The only way to win is not to play the
game."
Kill file him, or just resist the temptation to keep responding. His
rants can't hurt your reputation. Your responses can. (Some people have
reputations too low for further hurt to be an issue, but you don't have
that "luxury".)
--
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
| |
| David Frank 2005-08-25, 9:57 pm |
|
"Richard E Maine" <nospam@see.signature> wrote in message
news:nospam-D54C80.15562325082005@news.supernews.com...
> In article <delcjm$85t$1@scrotar.nss.udel.edu>,
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
>
>
> If I may offer some advice, I'd suggest recalling the adage about
> wresting with pigs. I.E. "Never wrestle with a pig. You'll both get
> dirty and only the pig will enjoy it."
>
> Flame wars like this are "no-win" situations. You can't help your
> reputation by "winning" one; you can hurt it. As in the quote from "War
> Games" about thermonuclear war, "The only way to win is not to play the
> game."
>
> Kill file him, or just resist the temptation to keep responding. His
> rants can't hurt your reputation. Your responses can. (Some people have
> reputations too low for further hurt to be an issue, but you don't have
> that "luxury".)
>
MAINE, we had a agreement to not respond to each others posts, you
CONTINUALLY violate that agreement,
by FLAMING ME (at least twice this last w ), you seem to want to goad me
in revealing to folks what the origin
of my depising you is, and FOLKS, IT AINT PRETTY..
I really dont know why you would want that, but keep calling me names ???
| |
| Tim Challenger 2005-08-26, 3:56 am |
| On Fri, 26 Aug 2005 00:48:12 GMT, David Frank wrote:
> "Richard E Maine" <nospam@see.signature> wrote in message
> news:nospam-D54C80.15562325082005@news.supernews.com...
>
> MAINE, we had a agreement to not respond to each others posts, you
> CONTINUALLY violate that agreement,
> by FLAMING ME (at least twice this last w), you seem to want to goad me
> in revealing to folks what the origin
> of my depising you is, and FOLKS, IT AINT PRETTY..
> I really dont know why you would want that, but keep calling me names ???
Don't worry, Dave, I think we can live with knowing that
1) you're not popular and
2) there are people you don't like.
Grown-ups are like that. You'll find out one day.
And there's no need to shout.
--
Tim C.
| |
| David Frank 2005-08-26, 7:57 am |
| Sooo, no-one can deduce/reproduce my #1 reduce_blanks function that was
used in below statement..
write (*,*) '|', line(1:reduce_blanks(???), '|'
Here are timings for my current testing program:
http://home.earthlink.net/~dave_gemini/test.f90
! CVF Intel 2.8ghz
! frank_1 0.17 | the quick brown fox |
! frank_2 0.80 | the quick brown fox |
! giles_1 0.64 | the quick brown fox|
! giles_2 1.14 | the quick brown fox|
Above shows my super-slick frank_1 function timing of 1 million lines
containing above shortened string
to ease the memory requirement for tester PCs while still doing same
#iterations as before.
test.f90 contains Giles_1 Giles_2 functions, to view my generic'ized 2
reduce_blank functions see:
http://home.earthlink.net/~strings.f90
RT, tell us what my new test.f90 on your obsolete Pentium "M" for Mediocre
PC results are..
| |
|
|
| Tim Challenger 2005-08-26, 7:57 am |
| On Fri, 26 Aug 2005 10:09:57 GMT, David Frank wrote:
> RT, tell us what my new test.f90 on your obsolete Pentium "M" for Mediocre
> PC results are..
I would say 2.8GHz is fairly mediocre nowadays.
--
Tim C.
| |
| David Frank 2005-08-26, 7:57 am |
|
"Tim Challenger" <tim.challenger@aon.at> wrote in message
news:1125038435. 3d7f24a15fa7ee8ee631632e75c20258@teranew
s...
>
> Don't worry, Dave, I think we can live with knowing that
> 1) you're not popular and
> 2) there are people you don't like.
> Grown-ups are like that. You'll find out one day.
>
> And there's no need to shout.
> --
> Tim C.
And how grown-up/smart for one's career to KNOWINGLY post claims for
non-existent PL/I syntax under your own name?
But your last post in comp.lang.pl1 admits it and hints you are turning over
a new leaf, unlike IBM-syncophant Robin Vowels who has'nt the slightest
qualm about posting flat-out lies, and likely will cut his throat on
learning IBM has pulled PL/I's plug.
It reminds me of my years-ago trolling in comp.os.os2.advocacy (not theres
a home for fanatics) where at last one of the self-proclaimed psuedo
moderators when pinned down on a posted lie, admitted to me, "THE END
JUSTIFIES THE MEANS" Thats obviously the principle that comp.lang.pl1's
"leading light" lives by.
FYI, Richard Maine is a wannabe moderator in comp.lang.fortran, and "Aye,
Theres The Rub"
| |
| Tim Challenger 2005-08-26, 7:57 am |
| On Fri, 26 Aug 2005 11:19:12 GMT, David Frank wrote:
> "Tim Challenger" <tim.challenger@aon.at> wrote in message
> news:1125038435. 3d7f24a15fa7ee8ee631632e75c20258@teranew
s...
>
> And how grown-up/smart for one's career to KNOWINGLY post claims for
> non-existent PL/I syntax under your own name?
It would be more stupid to do that under a false name.
> But your last post in comp.lang.pl1 admits it and hints you are turning over
> a new leaf,
hints at what?
>... unlike IBM-syncophant Robin Vowels who has'nt the slightest
> qualm about posting flat-out lies, and likely will cut his throat on
> learning IBM has pulled PL/I's plug.
>
> It reminds me of my years-ago trolling in comp.os.os2.advocacy
You haven't learnt much since the, have you?
>...bla bla snipped ...
> FYI, Richard Maine is a wannabe moderator in comp.lang.fortran, and "Aye,
> Theres The Rub"
You mean someone who doesn't agree with you is a wannabe moderator?
There're a lot of us about in that case.
--
Tim C.
| |
| Rich Townsend 2005-08-26, 7:57 am |
| David Frank wrote:
> Sooo, no-one can deduce/reproduce my #1 reduce_blanks function that was
> used in below statement..
>
> write (*,*) '|', line(1:reduce_blanks(???), '|'
>
> Here are timings for my current testing program:
> http://home.earthlink.net/~dave_gemini/test.f90
I can't get this to compile:
fortcom: Error: test.f90, line 21: The number of actual arguments cannot
be greater than the number of dummy arguments. [REDUCE_BLANKS]
nc = reduce_blanks ( loc(lines(n)),len(lines(n)) ) ! generic
function
-----------^
fortcom: Error: test.f90, line 21: The type of the actual argument
differs from the type of the dummy argument. [LOC]
nc = reduce_blanks ( loc(lines(n)),len(lines(n)) ) ! generic
function
---------------------------^
fortcom: Error: test.f90, line 21: The assignment operation or the
binary expression operation is invalid for the data types of the two
operands.
nc = reduce_blanks ( loc(lines(n)),len(lines(n)) ) ! generic
function
-----------^
compilation aborted for test.f90 (code 1)
Looks like buggy code to me.
cheers,
Rich
| |
| David Frank 2005-08-26, 7:57 am |
|
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:den02j$m34$1@scrotar.nss.udel.edu...
> compilation aborted for test.f90 (code 1)
>
> Looks like buggy code to me.
>
> cheers,
>
> Rich
Looks like you didnt open a new box of strings for breakfast..
| |
| Rich Townsend 2005-08-26, 7:57 am |
| David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:den02j$m34$1@scrotar.nss.udel.edu...
>
>
>
>
> Looks like you didnt open a new box of strings for breakfast..
>
>
No, I downloaded a fresh copy of strings.f90 straight after I downloaded
test.f90. I think you forgot to update it.
cheers,
Rich
| |
| Rich Townsend 2005-08-26, 7:57 am |
| Rich Townsend wrote:
> David Frank wrote:
>
>
> No, I downloaded a fresh copy of strings.f90 straight after I downloaded
> test.f90. I think you forgot to update it.
>
> cheers,
>
> Rich
OK, scratch that, wget was renaming the file after it downloaded it, to
avoid clobbering a previously-existing version.
However, your code is still buggy. Where do you define the loc()
function used on line 21?
cheers,
Rich
| |
| David Frank 2005-08-26, 7:57 am |
|
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:den2gn$mp9$1@scrotar.nss.udel.edu...
> David Frank wrote:
>
> No, I downloaded a fresh copy of strings.f90 straight after I downloaded
> test.f90. I think you forgot to update it.
>
> cheers,
>
> Rich
Check your strings for a generic declaration for reduce_blanks.
The time of the file sez its uploaded 10:39 GMT (2 hrs ago)
http://home.earthlink.net/~dave_gemini/strings.f90
| |
| David Frank 2005-08-26, 6:59 pm |
|
"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:den32i$mup$1@scrotar.nss.udel.edu...
> OK, scratch that, wget was renaming the file after it downloaded it, to
> avoid clobbering a previously-existing version.
>
> However, your code is still buggy. Where do you define the loc() function
> used on line 21?
>
Its compatible with CVF, and IFC, and Lahey? probably not supported by the
GEE-WHIZ Fortran flavors.
THE STANDARD has the function C_LOC so you either can run it now using
whatever your compiler syntax is for getting a variable's physical memory
address and it ports in the future with C_LOC...
Btw, Skip Knoble 64-bit Opteron compiler complains:
Warning: Strings.f90, line 81: A DEC Fortran pointer variable has been
explicitly given a data type that is not the longest integer type
associated with the current platform. [LOCLINE]
CHARACTER :: a(lenline) ; pointer (locline,a)
------------------------------------^
| |
| Rich Townsend 2005-08-26, 6:59 pm |
| David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:den32i$mup$1@scrotar.nss.udel.edu...
>
>
>
>
> Its compatible with CVF, and IFC, and Lahey? probably not supported by the
> GEE-WHIZ Fortran flavors.
Try compiling using standards compliance checking. Intel ifort and Lahey
lf95 will complain that LOC() is not a standard intrinsic. Therefore,
your code is non-standard, and need not be considered any further.
>
> THE STANDARD has the function C_LOC so you either can run it now using
> whatever your compiler syntax is for getting a variable's physical memory
> address and it ports in the future with C_LOC...
No, C_LOC is not the same as LOC. You wrote LOC. Your code needs fixing.
>
> Btw, Skip Knoble 64-bit Opteron compiler complains:
>
> Warning: Strings.f90, line 81: A DEC Fortran pointer variable has been
> explicitly given a data type that is not the longest integer type
> associated with the current platform. [LOCLINE]
> CHARACTER :: a(lenline) ; pointer (locline,a)
> ------------------------------------^
Same on 32-bit Intel ifort.
cheers,
Rich
| |
| David Frank 2005-08-27, 7:56 am |
| ! my eye-opener for this morning...
! ---------------------------------
! >demo.exe infile -> outfile (with blanks reduced)
! ---------------------------------
program demo_reduce_file_blanks
integer,external :: ftell
character,allocatable :: text(:)
character(20) :: infile, outfile
integer :: filesize
logical :: exists
call getarg(1,infile)
call getarg(2,outfile)
inquire (file=infile, exist = exists)
if (.not.exists) then
write (*,*) trim(infile), ' does not exist' ; stop
end if
open (1,file=infile,form='binary',position='a
ppend')
filesize = ftell(1) ; allocate ( text(filesize) )
rewind (1) ; read (1) text ; close (1)
open (2,file=outfile,form='binary')
write(2) text(1:Reduce_Blanks(loc(text), filesize)) ! huh?
stop
contains
! ------------------------------------------------
integer function Reduce_Blanks (loctext,sizetext)
integer :: loctext, sizetext, i, n
character :: a(sizetext) ; pointer (loctext,a)
n = 1
do i = 2,sizetext ! leave 1st char as is
if (a(i) /= ' '.or. a(i-1) /= ' ') then
n = n+1 ; a(n) = a(i)
end if
end do
Reduce_Blanks = n
end function Reduce_Blanks
end program
| |
| James Giles 2005-08-27, 6:58 pm |
| David Frank wrote:
> integer function Reduce_Blanks (loctext,sizetext)
> integer :: loctext, sizetext, i, n
> character :: a(sizetext) ; pointer (loctext,a)
> n = 1
> do i = 2,sizetext ! leave 1st char as is
> if (a(i) /= ' '.or. a(i-1) /= ' ') then
> n = n+1 ; a(n) = a(i)
> end if
> end do
> Reduce_Blanks = n
> end function Reduce_Blanks
Well, now he is no longer using Fortran and he has
changed the functionality of the procedure since the
return value is no longer a string, but the length of
the result. And the argument is not longer left unchanged.
(The latter point makes timing the code in a loop that
passes the same argument again and again impossible.)
Note that the statement:
pointer (loctext, a)
is not Fortran. It is an extension than only some
compilers support. It *should* be unnecessary in
this code anyway - I'll get back to that point again.
However, if I use some of the same tricks on my
original solution:
Function reduce_blanks (dloc,dsize) result(dest)
Implicit none
Integer, intent(in) :: dloc, dsize
Pointer (dloc, c) ! not a Fortran POINTER
Character :: c(dsize)
Integer :: dest, source, blanks
blanks = 0
dest = 0
Do source = 2, dsize
blanks = merge(0, blanks+1, c(source)/=" ")
If(blanks > 1) Cycle
dest = dest+1
c(dest) = c(source)
End do
End function reduce_blanks
On my system, this version of my solution is faster than
his code. Mine still tests only one character from the input
on each pass throught he loop, not two. It's irrelevant in
mine whether OR short-cuts or not since there is no OR.
Hence, there's not even the overhead of a conditional
branch or anything else associated with the second test.
However, there is also a second test in mine, against the
BLANKS count. I can well believe that on *some*
target architectures, that may make my code and DF's
pretty much a dead even race.
If DF hadn't again resorted to bogus programming efforts,
I would not now be responding. His previous solution
was a reasonably simple scalar loop. It was relatively
easy to read and didn't try to use the fewest possible
lines or any other such garbage (brevity is *NOT* a
valid programming goal).
However, he has now gone back off the deep end by using
non-Fortran in his "solution". This calls into question what
problem he's trying to solve. The problem that using Cray
style pointers solves is the one I mentioned in my first
response to this issue: CVF does a *very* bad job on
character strings. You have to convert the string to a
character array in order to get the compiler to produce
efficient code. This should *NOT* be necessary. And,
it's not something that would necessarily be faster, or
work at all, on other Fortran implementations. DF still
has problems recognizing which of the things he does
are inherent to the problem being solved and which are
specific to peculiarities of the compiler he is using.
And he continues to claim that such implementation
specific work-arounds are actually algorithm improvements.
This reflects a poor understanding of programming and
is not the kind of thing that others should be taught.
--
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
| |
| David Frank 2005-08-27, 6:58 pm |
|
"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:dY3Qe.685425$cg1.335522@bgtnsc04-news.ops.worldnet.att.net...
> David Frank wrote:
>
> Well, now he is no longer using Fortran and he has
> changed the functionality of the procedure since the
> return value is no longer a string, but the length of
> the result. And the argument is not longer left unchanged.
> (The latter point makes timing the code in a loop that
> passes the same argument again and again impossible.)
>
> Note that the statement:
>
> pointer (loctext, a)
>
> is not Fortran. It is an extension than only some
> compilers support. It *should* be unnecessary in
> this code anyway - I'll get back to that point again.
>
> However, if I use some of the same tricks on my
> original solution:
>
> Function reduce_blanks (dloc,dsize) result(dest)
>
> Implicit none
> Integer, intent(in) :: dloc, dsize
> Pointer (dloc, c) ! not a Fortran POINTER
> Character :: c(dsize)
>
> Integer :: dest, source, blanks
>
> blanks = 0
> dest = 0
>
> Do source = 2, dsize
> blanks = merge(0, blanks+1, c(source)/=" ")
>
> If(blanks > 1) Cycle
>
> dest = dest+1
> c(dest) = c(source)
>
> End do
>
> End function reduce_blanks
>
> On my system, this version of my solution is faster than
> his code. Mine still tests only one character from the input
> on each pass throught he loop, not two. It's irrelevant in
> mine whether OR short-cuts or not since there is no OR.
> Hence, there's not even the overhead of a conditional
> branch or anything else associated with the second test.
> However, there is also a second test in mine, against the
> BLANKS count. I can well believe that on *some*
> target architectures, that may make my code and DF's
> pretty much a dead even race.
>
> If DF hadn't again resorted to bogus programming efforts,
> I would not now be responding. His previous solution
> was a reasonably simple scalar loop. It was relatively
> easy to read and didn't try to use the fewest possible
> lines or any other such garbage (brevity is *NOT* a
> valid programming goal).
>
Thats a understatement, there is no simpler scalar loop than my reduce.f90
benchmark code.
Frank_1 http://home.earthlink.net/~davegemini/reduce.f90
do i = 2,len(line)
if (line(i-1:i) == ' ') cycle
n = n+1 ; outline(n:n) = line(i:i)
end do
which is faster on my computer than your merge code because you have to pass
3 arguments to merge plus it then has to make a char test and choose between
1 of the 2 input args for its output, WHEW!!
As a result NO-ONE understands your Giles_1 function, ITS NOT-LEGIBLE..
(you could have at least used logical args in the merge decision instead of
integers which would have clarified whats going on a good deal)..
> However, he has now gone back off the deep end by using
> non-Fortran in his "solution".
Thats B.S. Cray pointers have been supported by SERIOUS Fortran compilers
for what? 40 years?
AND C Pointers are in THE STANDARD so what are you bitching about?
>This calls into question what problem he's trying to solve.
IN THE SPEC the goals are:
1. Fastest
2. Most Legible
3. Briefest
My new Frank_1 is 4x faster than your Giles_1 on my system, (and Skip
Knoble's)..
If you want to OFFICIALLY change your Giles_1 to use a Cray pointer be my
guest but be aware on my system
its NOT faster than mine, PLUS it again plagiarizes my solution, as Giles_2
plagiarizes Frank_2 solution
( I was the first to use PACK) and is SIGNIFICANTLY slower.
Or better yet, just accept you came in second in this challenge and lets
move on..
| |
| James Giles 2005-08-27, 6:58 pm |
| David Frank wrote:
....
> do i = 2,len(line)
> if (line(i-1:i) == ' ') cycle
> n = n+1 ; outline(n:n) = line(i:i)
> end do
>
> which is faster on my computer than your merge code because you
> have to pass 3 arguments to merge plus it then has to make a char
> test and choose between 1 of the 2 input args for its output,
> WHEW!!
My MERGE is inlined, and I don't believe that CVF doesn't
inline everywhere. Hence, it evaluates no arguments until
it needs them. But, replace it with the following if you insist:
If(c(source)/=" ") then
blanks = 0
Else
blanks = blanks+1
Endif
> As a result NO-ONE understands your Giles_1 function, ITS
> NOT-LEGIBLE.. (you could have at least used logical args in the
> merge decision instead of integers which would have clarified whats
> going on a good deal)..
No, logicals decrease clarity because the statement of the problem
itself is in terms of a *number* of consecutive blanks. That's the
reason I went to a number in the first place. It *increases*
clarity. I didn't even care if it was less efficient becasue it's
obviously clearer. As witness the fact that I can extend my
solution to allow a different number of blanks (as I've demonstrated
before), I can alter my solution in a very simple way to solve
your counting-columns problem (as I've demonstrated before),
etc.
>
> Thats B.S. Cray pointers have been supported by SERIOUS Fortran
> compilers for what? 40 years?
> AND C Pointers are in THE STANDARD so what are you bitching about?
Again, you miss the *main* point. The use of pointers
of *any* kind should be completely *unnecessary*!!!!!!
The weakness of CVF's sub-optimization of the use of
basic character strings is the only reason to even consider
pointer use.
--
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
| |
| David Frank 2005-08-28, 7:57 am |
|
"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:XX6Qe.141612$5N3.109097@bgtnsc05-news.ops.worldnet.att.net...
> David Frank wrote:
> ...
>
> My MERGE is inlined, and I don't believe that CVF doesn't
> inline everywhere. Hence, it evaluates no arguments until
> it needs them. But, replace it with the following if you insist:
>
> If(c(source)/=" ") then
> blanks = 0
> Else
> blanks = blanks+1
> Endif
>
Above produces same timings for your Giles_1 so CVF does inline the merge.
>
> Again, you miss the *main* point. The use of pointers
> of *any* kind should be completely *unnecessary*!!!!!!
> The weakness of CVF's sub-optimization of the use of
> basic character strings is the only reason to even consider
> pointer use.
>
The problem has been there forever..
When DVF 5.0 was released, I had a look at its code being produced and
complained to Lionel than DEC wasnt using very efficent Intel instructions
to handle chars,
e.g. I didnt see in the tests I ran back then that it used LB STB
instructions to just move a byte, or the table move instructions to
manipulate sub-strings, as a result I posted some timings showing my old
16-bit MS Fortran 5.1 compiler ran faster than DVF5.0 manipulating string
syntax even tho the 16-bit compiler's applications had to run in a 16-bit
DOS window under Windows 95 not a 32-bit window. I also ran these tests
using MS's FPS4.0 32-bit windows compiler and saw more efficient Intel
32-bit instructions being used and MS FPS4.0 outperforming DVF,
but NOT as I recall, MS FORTRAN 5.1
|
|
|
|
|