Home > Archive > Cobol > January 2008 > Quicksort recursiv
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 |
Quicksort recursiv
|
|
|
| Hi,
Is it possible to program the Quicksort Algorithm recursive in Cobol?
I know that it is possible to call SubPrograms with CALL "name" an
give the SubProgram some Data.
What would happen if the SupProgram calls itself? Will that be real
recursive or doesn't that work?
Does somebody already have a conclusion?
Markus
| |
|
| In article <aee81659-5d9a-4562-830f-b2bf1d70a7e3@z17g2000hsg.googlegroups.com>,
Mr. G <gronoworx@gmx.de> wrote:
>Hi,
>
>Is it possible to program the Quicksort Algorithm recursive in Cobol?
This smells remarkably like homework... but it might not be.
The kind of sort coded that would be most efficient depends on the kind of
data being passed through it; please detail the size and data-type of your
sort key, the length of the data element associated with it and the source
of the data (external file or a WORKING-STORAGE table) and the situation
might be addressed more readily.
DD
| |
| Robert 2008-01-10, 6:56 pm |
| On Thu, 10 Jan 2008 04:24:25 -0800 (PST), "Mr. G" <gronoworx@gmx.de> wrote:
>Hi,
>
>Is it possible to program the Quicksort Algorithm recursive in Cobol?
>
>I know that it is possible to call SubPrograms with CALL "name" an
>give the SubProgram some Data.
>
>What would happen if the SupProgram calls itself? Will that be real
>recursive or doesn't that work?
Recursion works if the compiler follows the 2002 Cobol Standadrd or supports object
oriented. But then, if it follows the 2002 Standard for SORT verb, you can sort a table in
memory with one line of code. If not, you can call the C qsort function with one line of
code.
Quicksort is not the fastest, in general. For extra points, try to find a faster sort
algorithm .. or (hint) combination of algorithms.
| |
| HeyBub 2008-01-10, 6:56 pm |
| Robert wrote:
> On Thu, 10 Jan 2008 04:24:25 -0800 (PST), "Mr. G" <gronoworx@gmx.de>
> wrote:
>
>
> Recursion works if the compiler follows the 2002 Cobol Standadrd or
> supports object oriented. But then, if it follows the 2002 Standard
> for SORT verb, you can sort a table in memory with one line of code.
> If not, you can call the C qsort function with one line of code.
>
> Quicksort is not the fastest, in general. For extra points, try to
> find a faster sort algorithm .. or (hint) combination of algorithms.
Or use the SORT verb and let the operating system figure it out.
| |
| Judson McClendon 2008-01-10, 6:56 pm |
| "Mr. G" <gronoworx@gmx.de> wrote:
>
> Is it possible to program the Quicksort Algorithm recursive in Cobol?
>
> I know that it is possible to call SubPrograms with CALL "name" an
> give the SubProgram some Data.
>
> What would happen if the SupProgram calls itself? Will that be real
> recursive or doesn't that work?
>
> Does somebody already have a conclusion?
It depends on the COBOL compiler. I once wrote a recursive parts
explosion algorithm in COBOL, and it was very simple and elegant.
That compiler supported recursive performs, but not local recursive data,
so I had to use a table stack for that, which made it a bit less elegant than
I would have liked.
--
Judson McClendon judmc@sunvaley0.com (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."
| |
| Charles Hottel 2008-01-10, 6:56 pm |
|
"Mr. G" <gronoworx@gmx.de> wrote in message
news:aee81659-5d9a-4562-830f-b2bf1d70a7e3@z17g2000hsg.googlegroups.com...
> Hi,
>
> Is it possible to program the Quicksort Algorithm recursive in Cobol?
>
> I know that it is possible to call SubPrograms with CALL "name" an
> give the SubProgram some Data.
>
> What would happen if the SupProgram calls itself? Will that be real
> recursive or doesn't that work?
>
> Does somebody already have a conclusion?
>
> Markus
Google is your friend. Search google groups, comp.lang.cobol, for jazqsort:
http://groups.google.com/group/comp...831b92b2c05b4ca
| |
| Robert 2008-01-11, 3:55 am |
| On Thu, 10 Jan 2008 08:20:35 -0600, "HeyBub" <heybub@gmail.com> wrote:
>Robert wrote:
[color=darkred]
>Or use the SORT verb and let the operating system figure it out.
You must be referring to the SyncSort operating system. I booted it on my Genius (as seen
on TV). Now it not only chops, slices and dices, but also sorts the pieces into neat
little heaps. That was on the Heapsort setting, of course.
Then I took it to the laundry room, set it on Bubblesort, and dumped my clothes in. It
worked, but performance sucked. It ran in n^2. The book said I could expect n(log n).
Since there were only two buckets, white and colored, would Bucketsort have run faster?
I couldn't find Coinsort, so I tried sorting my change with Shell Sort. It threw them all
into the reject pile. Next time I'll try Pigeonhole or Bozo Sort.
| |
| Arnold Trembley 2008-01-11, 3:55 am |
| Mr. G wrote:
> Hi,
>
> Is it possible to program the Quicksort Algorithm recursive in Cobol?
>
> I know that it is possible to call SubPrograms with CALL "name" an
> give the SubProgram some Data.
>
> What would happen if the SupProgram calls itself? Will that be real
> recursive or doesn't that work?
>
> Does somebody already have a conclusion?
>
> Markus
It is certainly possible to code the Quicksort Algorithm in COBOL,
using either recursion or iteration. Most traditional COBOL
programmers will probably find iteration easier.
Here's an interesting article on table sorting in COBOL. The author
includes an example of Quicksort written in COBOL using iteration
rather than recursion:
http://home.att.net/~arnold.trembley/svalgard.htm
Perhaps we can get Robert to post an example of a Radix Sort in COBOL,
which he says is faster than Quicksort.
With kindest regards,
--
http://arnold.trembley.home.att.net/
| |
| Howard Brazee 2008-01-11, 6:56 pm |
| On Fri, 11 Jan 2008 04:51:38 GMT, Arnold Trembley
<arnold.trembley@worldnet.att.net> wrote:
>Here's an interesting article on table sorting in COBOL. The author
>includes an example of Quicksort written in COBOL using iteration
>rather than recursion:
>http://home.att.net/~arnold.trembley/svalgard.htm
I have programmed the Quicksort in CoBOL to sort some large tables.
It's fast, easy, and clear. That said, there should be no need for
it - I should be able to CoBOL to sort it, and CoBOL should be able to
tell the system to pick the best sort.
But my shop's CoBOL can't do that.
| |
| William M. Klein 2008-01-11, 6:56 pm |
| Howard,
Aren't you using IBM COBOL? If so, you can (and I know I have posted this
before). It isn't FASTSRT - or even totally "obvious" - but it does use DFSort
or SyncSort to do the sorting. See:
http://publibz.boulder.ibm.com/cgi-...3pg32/1.12.10.2
Yes, I would like IBM to add the "native" table sort feature, but what you ask
for is possible.
P.S. At least on mainframes (IBM or otherwise) I would expect this technique
often to use the system's "optimal" sort technique for the data involved.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:ks1fo3h4b9htj8e011u1h016087ff1co2k@
4ax.com...
> On Fri, 11 Jan 2008 04:51:38 GMT, Arnold Trembley
> <arnold.trembley@worldnet.att.net> wrote:
>
>
> I have programmed the Quicksort in CoBOL to sort some large tables.
> It's fast, easy, and clear. That said, there should be no need for
> it - I should be able to CoBOL to sort it, and CoBOL should be able to
> tell the system to pick the best sort.
>
> But my shop's CoBOL can't do that.
| |
| Howard Brazee 2008-01-11, 6:56 pm |
| On Fri, 11 Jan 2008 20:01:56 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
> Aren't you using IBM COBOL? If so, you can (and I know I have posted this
>before). It isn't FASTSRT - or even totally "obvious" - but it does use DFSort
>or SyncSort to do the sorting. See:
>
>http://publibz.boulder.ibm.com/cgi-...3pg32/1.12.10.2
>
>Yes, I would like IBM to add the "native" table sort feature, but what you ask
>for is possible.
>
>P.S. At least on mainframes (IBM or otherwise) I would expect this technique
>often to use the system's "optimal" sort technique for the data involved.
Our compiler options are set the same for all programs when they get
migrated to production.
| |
| Frank Swarbrick 2008-01-11, 6:56 pm |
| >>> On 1/11/2008 at 1:28 PM, in message
<09kfo39k2ed2uoag56np597v4mj6g4ao38@4ax.com>, Howard
Brazee<howard@brazee.net> wrote:
> On Fri, 11 Jan 2008 20:01:56 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
> this
> DFSort
[color=darkred]
> 0.2
> you ask
> technique
>
> Our compiler options are set the same for all programs when they get
> migrated to production.
What happens if you put a PROCESS or CBL card at the top of your source
file? Will production implementation reject it because you are trying to
use a non-standard compile option?
| |
| William M. Klein 2008-01-11, 6:56 pm |
| Huh???
Compiler options have nothing to do with this. For IBM mainframes, the code
from the programming guide will work the same (and use the "system sort program"
to sort tables) regardless of compiler option.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:09kfo39k2ed2uoag56np597v4mj6g4ao38@
4ax.com...
> On Fri, 11 Jan 2008 20:01:56 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> Our compiler options are set the same for all programs when they get
> migrated to production.
| |
| Robert 2008-01-11, 6:56 pm |
| On Fri, 11 Jan 2008 08:16:44 -0700, Howard Brazee <howard@brazee.net> wrote:
>On Fri, 11 Jan 2008 04:51:38 GMT, Arnold Trembley
><arnold.trembley@worldnet.att.net> wrote:
>
>
>I have programmed the Quicksort in CoBOL to sort some large tables.
>It's fast, easy, and clear. That said, there should be no need for
>it - I should be able to CoBOL to sort it, and CoBOL should be able to
>tell the system to pick the best sort.
>
>But my shop's CoBOL can't do that.
Doesn't your shop's CoBOL support object oriented?
| |
| Pete Dashwood 2008-01-11, 9:56 pm |
|
"Robert" <no@e.mail> wrote in message
news:r7kdo3pfq09catidnsddj0favs4e0uqqsj@
4ax.com...
> On Thu, 10 Jan 2008 08:20:35 -0600, "HeyBub" <heybub@gmail.com> wrote:
>
>
>
> You must be referring to the SyncSort operating system. I booted it on my
> Genius (as seen
> on TV). Now it not only chops, slices and dices, but also sorts the pieces
> into neat
> little heaps. That was on the Heapsort setting, of course.
>
> Then I took it to the laundry room, set it on Bubblesort, and dumped my
> clothes in. It
> worked, but performance sucked. It ran in n^2. The book said I could
> expect n(log n).
> Since there were only two buckets, white and colored, would Bucketsort
> have run faster?
>
> I couldn't find Coinsort, so I tried sorting my change with Shell Sort. It
> threw them all
> into the reject pile. Next time I'll try Pigeonhole or Bozo Sort.
ROFL!
Great job, Robert!
Thanks, I needed that... :-)
Pete.
--
"I used to write COBOL...now I can do anything."
| |
| HeyBub 2008-01-12, 7:55 am |
| Robert wrote:
> Then I took it to the laundry room, set it on Bubblesort, and dumped
> my clothes in. It worked, but performance sucked. It ran in n^2. The
> book said I could expect n(log n). Since there were only two buckets,
> white and colored, would Bucketsort have run faster?
>
Buckets (and faucets) labeled "white" and "colored" are illegal.
| |
| Robert 2008-01-12, 9:58 pm |
| On Sat, 12 Jan 2008 07:31:51 -0600, "HeyBub" <heybub@gmail.com> wrote:
>Robert wrote:
>
>Buckets (and faucets) labeled "white" and "colored" are illegal.
<slap on the forehead> How stupid of me. I should have said free and slave.
Under the Mariah Carey Rule, clothes with one drop of color belong in the slave bucket.
Indian clothes are a special case; they get the  ie wash cycle.
| |
| Alistair 2008-01-14, 7:55 am |
| On 13 Jan, 03:12, Robert <n...@e.mail> wrote:
> On Sat, 12 Jan 2008 07:31:51 -0600, "HeyBub" <hey...@gmail.com> wrote:
>
>
> <slap on the forehead> How stupid of me. I should have said free and slave.
> Under the Mariah Carey Rule, clothes with one drop of color belong in the slave bucket.
>
> Indian clothes are a special case; they get the ie wash cycle.
Coollies were Chinese, not Indian.
| |
| Robert 2008-01-14, 6:56 pm |
| On Mon, 14 Jan 2008 02:32:48 -0800 (PST), Alistair <alistair@ld50macca.demon.co.uk> wrote:
>On 13 Jan, 03:12, Robert <n...@e.mail> wrote:
>
>Coollies were Chinese, not Indian.
"For example, by the 1850s in Trinidad, the annual Muharram or Hosay festival that came
over from India was being called "the Coolie Carnival." Through the Caribbean, as well as
in Sri Lanka, South Africa, and elsewhere, the word soon came to denote any person of
Indian origin or descent."
http://en.wikipedia.org/wiki/Coolie
| |
| Alistair 2008-01-14, 6:56 pm |
| On 14 Jan, 14:11, Robert <n...@e.mail> wrote:
> On Mon, 14 Jan 2008 02:32:48 -0800 (PST), Alistair <alist...@ld50macca.demon.co.uk> wrote:
>
>
>
>
>
> "For example, by the 1850s in Trinidad, the annual Muharram or Hosay festival that came
> over from India was being called "the Coolie Carnival." Through the Caribbean, as well as
> in Sri Lanka, South Africa, and elsewhere, the word soon came to denote any person of
> Indian origin or descent."http://en.wikipedia.org/wiki/Coolie- Hide quoted text -
>
> - Show quoted text -
It seems that you are right. My comment was based on living in
Singapore and seeing the local chines labour called lies. I was
not aware that it was a generic term for Asian labour.
| |
| Howard Brazee 2008-01-14, 6:56 pm |
| On Sat, 12 Jan 2008 00:35:44 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:
>Huh???
> Compiler options have nothing to do with this. For IBM mainframes, the code
>from the programming guide will work the same (and use the "system sort program"
>to sort tables) regardless of compiler option.
OK, then I have no idea how to select a particular sort with the SORT
command for my CoBOL without using compiler options.
| |
| Howard Brazee 2008-01-14, 6:56 pm |
| On Fri, 11 Jan 2008 18:45:52 -0600, Robert <no@e.mail> wrote:
>
>Doesn't your shop's CoBOL support object oriented?
No. But table sorts don't need OO, they just need to be implemented
in my compiler.
| |
| Howard Brazee 2008-01-14, 6:56 pm |
| On Fri, 11 Jan 2008 16:05:22 -0700, "Frank Swarbrick"
<Frank.Swarbrick@efirstbank.com> wrote:
>What happens if you put a PROCESS or CBL card at the top of your source
>file? Will production implementation reject it because you are trying to
>use a non-standard compile option?
They get ignored in Endevor's migration process. (I've tried it)
| |
| William M. Klein 2008-01-14, 6:56 pm |
| If you actually WANT to tell DFSort or SyntcSort to use a specific type of SORT,
then you need to also have one of their special DD cards in your JCL. I could
look up some references if you actually want them, but I don't think that
(usually) when doing a table sort (on IBM mainframes) the way the same I gave
suggested, that this would usually be needed.
Let me know if you do want me to look it up.
--
Bill Klein
wmklein <at> ix.netcom.com
"Howard Brazee" <howard@brazee.net> wrote in message
news:untmo35qb5hma5gea14q4hl1vlsbsuj7m6@
4ax.com...
> On Sat, 12 Jan 2008 00:35:44 GMT, "William M. Klein"
> <wmklein@nospam.netcom.com> wrote:
>
>
> OK, then I have no idea how to select a particular sort with the SORT
> command for my CoBOL without using compiler options.
| |
| Frank Swarbrick 2008-01-14, 6:56 pm |
| >>> On 1/14/2008 at 7:54 AM, in message
<9rtmo3lkbfsilidnpb3lklnol7ukh7227c@4ax.com>, Howard
Brazee<howard@brazee.net> wrote:
> On Fri, 11 Jan 2008 16:05:22 -0700, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com> wrote:
>
>
> They get ignored in Endevor's migration process. (I've tried it)
Sounds like the work of source code Nazis! :-)
Frank
| |
| Arnold Trembley 2008-01-15, 3:55 am |
| Howard Brazee wrote:
> On Fri, 11 Jan 2008 16:05:22 -0700, "Frank Swarbrick"
> <Frank.Swarbrick@efirstbank.com> wrote:
>
>
> They get ignored in Endevor's migration process. (I've tried it)
I believe this is configurable with Endevor. My shop uses Endevor,
and I have no problems embedding PROCESS or CBL compile directives in
my COBOL source code, and they work as expected. We recently had a
problem with a CICS program that extracted EDSA usage numbers from
CICS, and it would not work correctly without TRUNC(BIN), which is
discouraged for performance reasons. If PROCESS/CBL commands could
not be specified in the COBOL source file, they would need to build a
special Endevor compile processor just for that one program.
(EDSA=Extended Dynamic Storage Area. The usage is reported in binary
fullwords, which are PIC S9(9) COMP in COBOL, but actually contained
values larger than the Picture clause. We have production CICS
regions with EDSA defined as 2 gigabytes).
Obviously, you don't want to use DYNAM with a CICS program, but that's
the only example I can think of off the top of my head that will
actually break a program. The local sysprogs wanted to discourage the
use of RENT in batch COBOL programs for performance reasons, but they
had to do some research to see if DB2 would still work.
Our Endevor is configured to compile the program only when it is first
ADDed, and all subsequent promotions through intermediate environments
and stages are moves of source and executable. We chose to move
rather than recompile at each step under the theory that recompiling a
program after testing and before implementing into PROD was too risky.
With kindest regards,
--
http://arnold.trembley.home.att.net/
| |
| Howard Brazee 2008-01-15, 6:56 pm |
| On Tue, 15 Jan 2008 08:39:12 GMT, Arnold Trembley
<arnold.trembley@worldnet.att.net> wrote:
>
>I believe this is configurable with Endevor.
It is. But not by me.
| |
| tim Josling 2008-01-15, 6:56 pm |
| On Tue, 15 Jan 2008 09:45:49 -0700, Howard Brazee wrote:
> On Tue, 15 Jan 2008 08:39:12 GMT, Arnold Trembley
> <arnold.trembley@worldnet.att.net> wrote:
>
>
> It is. But not by me.
By this guy:
http://en.wikipedia.org/wiki/Bastard_Operator_From_Hell
Tim Josling
|
|
|
|
|