Fortran - Reduce Blanks continued

Author

Reduce Blanks continued

David Frank

2005-08-17, 4:07 am

"discussion" continues here as existing topic's tree cant be seen.

For those who have lost track of this topic, my Reduce_Blanks function can
be found in my string_functions module:

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

And a benchmark to use this module with OTHER submitted solutions can be
found:

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

As BV reports with below link, Microsoft feels this subject is PATENTABLE,
while a submitter and myself both claim to have first come up with the
1-line technique:
outline = transfer(pack(array, out, pad) ,outline) hilarious, ENJOY!

http://appft1.uspto.gov/netacgi/nph...d+TTL/White&RS=((TTL/Adding+AND+T
TL/Removing)+AND+TTL/White)

David Frank

2005-08-17, 4:07 am

As keeper of the benchmark at:
http://home.earthlink.net/~dave_gemini/reduce.f90

let me state the competition is NOT closed.
But new versions shud either have some "interesting" syntax or be fast.

James Giles

2005-08-17, 5:04 pm

David Frank wrote:
>[...] while a submitter and myself both claim to have first
> come up with the 1-line technique:
> outline = transfer(pack(array, out, pad) ,outline) hilarious,

It wasn't me. I never came up with *any* one line technique
(as the above doesn't work anyway: out is not defined).
But, one liners are *inherently* less legible, and in this
case less efficient as well.

--
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-18, 4:04 am

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:7JIMe.107761$5N3.26635@bgtnsc05-news.ops.worldnet.att.net...
> David Frank wrote:
>
> It wasn't me. I never came up with *any* one line technique
> (as the above doesn't work anyway: out is not defined).

Yes its you that claims my routine was first devised by you and shud be
removed from the reduce blanks benchmark.
I showed your routine was a direct ripoff of my routine since it was posted
a w

after mine,
to which you havent replied.

My technique is not a 1-liner, but it can be as short as a 3 liner..

1. copy string into char array

a = transfer(line,a)

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)) ]

3. pack chars, then transfer chars to outline string

outline = transfer(a,out)

I have updated my Reduce_Blanks string function to reflect the new 1 line
mask setting:

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

I wonder if above 3 lines are patentable as "white space reduction" as per
Microsoft patent app.

James Giles

2005-08-18, 5:59 pm

David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:7JIMe.107761$5N3.26635@bgtnsc05-news.ops.worldnet.att.net...
>
> Yes its you that claims my routine was first devised by you and
> shud be removed from the reduce blanks benchmark.

Then you're still lying above: "while a submitter and myself both
claim to have first come up with the 1-line technique". I posted
no 1-line technique. I claimed authorship of any 1-line technique.
You solution wasn't a 1-line technique. You had to have additional
instruction: when *my* solution was in error and *you* copied
it, you denied my correction was necessary!!!!! Even when I made
it clear *why* the correction was needed.

> I showed your routine was a direct ripoff of my routine since it
> was posted a w

after mine,
> to which you havent replied.

Interesting, so you made the same error I did a w

before?
I saw no such example.

This newsgroup is archived. There is no reason to lie
about past statements.

> I wonder if above 3 lines are patentable as "white space reduction"
> as per Microsoft patent app.

Why bother? It's less legible than the ordinary scalar loop
that's also faster.

--
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-19, 4:18 pm

David Frank

2005-08-19, 4:18 pm

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:LO6Ne.630496$cg1.578049@bgtnsc04-news.ops.worldnet.att.net...
> David Frank wrote:
>
>
> Then you're still lying above: "while a submitter and myself both
> claim to have first come up with the 1-line technique".

This was referring to the 1 line that outputs
outline = transfer( pack( a, out), outline)

in this response you have deleted my 3 points proving you plagiarized my
routine posted at least a w

before yours.

Here is what you just deleted in THIS response: (equivalents to all 3
statements below are used by you)
<<<
My technique is not a 1-liner, but it can be as short as a 3 liner..

1. copy string into char array

a = transfer(line,a)

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)) ]

3. pack chars, then transfer chars to outline string

outline = transfer( pack(a,out),outline)
[color=darkred]
>
> This newsgroup is archived. There is no reason to lie
> about past statements.
>

Apparently there is some reason, what is it?

James Giles

2005-08-19, 4:18 pm

David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> My technique is not a 1-liner, but it can be as short as a 3
> liner..
>
> 1. copy string into char array
>
> a = transfer(line,a)

OK, since I never looked at *your* "solution" before posting
any of mine (since back then people that I have at least a
little respect for were pointing out that yours was not
correct for one reason or another - and you were making
totally bogus noises about appending nulls - which is still
the *wrong* thing to do) I may have "copied" the above
obvious line. (Like there's another way to do it.) A trip
through the archive will disclose that I copied the
line from another of *my* solutions - and I *stated*
when I posted *that* solution that I had copied it from
NucWiz and that I didn't actually understand why it
helped on my implementation of the much better and
still fastest version on the list.

> 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. It is also not
what *your* "solution" looked like prior to my version
of JvB's code (which is *really* what I copied - as I explicitly
stated at the time).

> outline = transfer( pack(a,out),outline)

Again, that's not what I wrote. I would not make an
assignment to OUTLINE that leaves undefined trailing
characters in it. That's all yours! You can have it.

TRANSFER does *NOT* define what the remaining
characters beyond the length of the PACK are. It
probably leaves the data the same as OUTLINE
started with: whatever was in that space on the
stack before OUTLINE was declared.

>
> Apparently there is some reason, what is it?

You're the one that knows.

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

[JvO]

2005-08-19, 6:56 pm

No, CHARACTER assignments where destination is larger than source
are well defined. Padded with blanks.
See F95 7.5.1.4

[JvO]

David Frank

2005-08-19, 6:56 pm

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:eSrNe.114979$5N3.104032@bgtnsc05-news.ops.worldnet.att.net...
> David Frank wrote:
>
> OK, since I never looked at *your* "solution" before posting
> any of mine

<snip>

OK, forget it..

I kinda like my new version which replaces the transfers with a generic copy
routine
Its fast enuf to move it into 4th place giving me 2 of the top 4 results (on
my system)

below routine for the benchmark's Frank_2 result was extracted from:

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

! --------------------
FUNCTION Reduce_Blanks (line) RESULT (outline)
CHARACTER(*) :: line
CHARACTER(LEN(line)) :: outline
CHARACTER :: a(len(line)), pad(len(line))
LOGICAL :: out(len(line))
INTEGER :: i, n

pad = char(0) ; n = len(line)
a = Copy(line) ! copy line to char array
out(1) = .TRUE. ! col 1 always output
DO i = 2,n
out(i) = a(i) /= ' '.OR.a(i-1) /= ' '
END DO
outline = Copy( PACK(a, out, pad) ) ! copy char array to C string
preserving last blank if present
END FUNCTION Reduce_Blanks

James Giles

2005-08-19, 6:56 pm

[JvO] wrote:
> No, CHARACTER assignments where destination is larger than source
> are well defined. Padded with blanks.
> See F95 7.5.1.4

The length of the result of TRANSFER is the same
as the length of the MOLD (if MOLD is a scalar, which
a string is). But what's in that extra space if the SOURCE
is shorter than the MOLD is *explicitly* left undefined by
the standard. See the description of TRANSFER.

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

Rich Townsend

2005-08-19, 9:56 pm

James Giles wrote:
> [JvO] wrote:
>
>
>
> The length of the result of TRANSFER is the same
> as the length of the MOLD (if MOLD is a scalar, which
> a string is). But what's in that extra space if the SOURCE
> is shorter than the MOLD is *explicitly* left undefined by
> the standard. See the description of TRANSFER.
>

Yep. This is, IMHO, one of the biggest TRANSFER gotchas (although all
good books spell it out).

cheers,

Rich

James Van Buskirk

2005-08-19, 9:56 pm

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:de5s56$hum$1@scrotar.nss.udel.edu...

> Yep. This is, IMHO, one of the biggest TRANSFER gotchas (although all
> good books spell it out).

Why is this a gotcha? Isn't this exactly what you would expect
for a low-level primitive? Any mechanism for context-free access
to memory, such as COMMON, EQUIVALENCE, or storage association
is going to have the same issue.

P.S.:

module reduce_mod
implicit none
contains
function reduce_blanks(x)
character(*), intent(in) :: x
character, parameter :: y(0) = ''
character( &
count( &
transfer(x,y) /= ' ' .OR. &
eoshift( &
transfer(x,y), &
1, &
'*') /= ' ') &
) reduce_blanks

reduce_blanks = transfer( &
pack( &
transfer(x,y), &
transfer(x,y) /= ' ' .OR. &
eoshift( &
transfer(x,y), &
1, &
'*') /= ' '), &
reduce_blanks)

end function reduce_blanks
end module reduce_mod

program test
use reduce_mod
implicit none
character(40) :: string = ' The quick brown fox jumps'

write(*,*) '!'//reduce_blanks(string)//'!'
end program test

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

Rich Townsend

2005-08-19, 9:56 pm

James Van Buskirk wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:de5s56$hum$1@scrotar.nss.udel.edu...
>
>
>
>
> Why is this a gotcha?

Well, it got me before I read the documentation properly and thought
about it.

cheers,

Rich

David Frank

2005-08-20, 7:57 am

"David Frank" <dave_frank@hotmail.com> wrote in message
news:vJCMe.8206$Je.5176@newsread2.news.atl.earthlink.net...
> As keeper of the benchmark at:
> http://home.earthlink.net/~dave_gemini/reduce.f90
>
> let me state the competition is NOT closed.
> But new versions shud either have some "interesting" syntax or be fast.
>
>

Above reduce.f90 link currently shows below runtimes.

However, Skip Knoble's athlon gets a different lineup where Giles_1 is #1
and my #1 routine drops to same
timing as my #2.
Perhaps someone else can confirm below rankings or NOT..

Note: my #2 result below is a result of new "interesting" syntax (see
frank_2 source in reduce.f90)
as it now uses a copy function to substitute for transfer function, see
generic copy routine at:
http://home.earthlink.net/~davegemini/strings.f90

ALSO note that ONLY Frank solutions are producing the CORRECT output with a
trailing blank
even tho the output statements below NOW use my CTRIM to output what came
back from user functions.
Now it only remains to submitters to mark the presence of a trailing blank
in their output.

Frank_1 0.59 sec | the quick brown fox jumps |
Frank_2 0.78 sec | the quick brown fox jumps |
Giles_1 0.67 sec | the quick brown fox jumps|
Giles_2 1.19 sec | the quick brown fox jumps|
Chandler 0.72 sec | the quick brown fox jumps|
NucWiz 0.92 sec | the quick brown fox jumps|
Vanbuskirk 1.56 sec | the quick brown fox jumps|
FJRA 2.83 sec | the quick brown fox jumps|

Using my function with THE STANDARD looks like a natural fit.
character(:),allocatable :: newline
newline = Ctrim(Reduce_Blanks(line))

newline automatically allocated to exact length of Ctrim result with
trailing blank.
None of submitters routines are compatible with THE STANDARD in this regard.

David Frank

2005-08-20, 6:59 pm

I keep screwing up posting links

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

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

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

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

If you want to submit or resubmit a solution that meets these revisions, be
my guest, sometime next w

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

Sponsored Links