Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #143374 > unrolled thread
| Started by | rick.c.hodgin@gmail.com |
|---|---|
| First post | 2019-04-24 09:08 -0700 |
| Last post | 2019-05-04 05:53 -0700 |
| Articles | 20 on this page of 103 — 26 participants |
Back to article view | Back to comp.lang.c
qsort() standard functions rick.c.hodgin@gmail.com - 2019-04-24 09:08 -0700
Re: qsort() standard functions gazelle@shell.xmission.com (Kenny McCormack) - 2019-04-24 16:12 +0000
Re: qsort() standard functions rick.c.hodgin@gmail.com - 2019-04-24 09:18 -0700
Re: qsort() standard functions Chad <cdalten@gmail.com> - 2019-05-02 12:02 -0700
Re: qsort() standard functions Real Troll <real.troll@trolls.com> - 2019-04-24 22:30 -0400
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 19:32 -0700
Re: qsort() standard functions Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-04-25 10:19 +0000
Re: qsort() standard functions rick.c.hodgin@gmail.com - 2019-04-25 04:09 -0700
Re: qsort() standard functions Richard Damon <Richard@Damon-Family.org> - 2019-04-25 08:13 -0400
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-25 06:39 -0700
Re: qsort() standard functions already5chosen@yahoo.com - 2019-04-25 07:23 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-25 00:39 -0700
Re: qsort() standard functions Real Troll <Real.Troll@Trolls.com> - 2019-04-25 23:27 +0100
Re: qsort() standard functions John Bode <jfbode1029@gmail.com> - 2019-04-24 09:34 -0700
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 09:47 -0700
Re: qsort() standard functions John Bode <jfbode1029@gmail.com> - 2019-04-24 09:47 -0700
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 12:54 -0400
Re: qsort() standard functions John Bode <jfbode1029@gmail.com> - 2019-04-24 11:33 -0700
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 14:41 -0400
Re: qsort() standard functions John Bode <jfbode1029@gmail.com> - 2019-04-24 11:52 -0700
Re: qsort() standard functions gazelle@shell.xmission.com (Kenny McCormack) - 2019-04-24 19:12 +0000
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 16:05 -0400
Re: qsort() standard functions queequeg@trust.no1 (Queequeg) - 2019-04-24 20:39 +0000
Re: qsort() standard functions James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-04-24 16:33 -0700
Re: qsort() standard functions gazelle@shell.xmission.com (Kenny McCormack) - 2019-04-24 19:18 +0000
Re: qsort() standard functions Bart <bc@freeuk.com> - 2019-04-24 20:28 +0100
Re: qsort() standard functions gazelle@shell.xmission.com (Kenny McCormack) - 2019-04-24 21:27 +0000
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 12:31 -0700
Re: qsort() standard functions John Bode <jfbode1029@gmail.com> - 2019-04-24 13:02 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 13:41 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 14:00 -0700
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-04-25 00:22 +0300
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 15:04 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 15:20 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 15:40 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 15:57 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 16:06 -0700
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-04-25 23:49 +0300
Re: qsort() standard functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-25 22:45 +0100
Re: qsort() standard functions Bart <bc@freeuk.com> - 2019-04-25 23:00 +0100
Re: qsort() standard functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-25 23:24 +0100
Re: qsort() standard functions Real Troll <Real.Troll@Trolls.com> - 2019-04-25 23:20 +0100
Re: qsort() standard functions Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-04-26 13:06 +0300
Re: qsort() standard functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-26 13:38 +0100
Re: qsort() standard functions Anton Shepelev <anton.txt@g{oogle}mail.com> - 2019-04-26 16:43 +0300
Re: qsort() standard functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-26 17:46 +0100
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-04-27 14:55 +0300
Re: qsort() standard functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-27 14:59 +0100
Re: qsort() standard functions Robert Wessel <robertwessel2@yahoo.com> - 2019-04-27 11:41 -0500
Re: qsort() standard functions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-05-02 09:46 -0700
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-05-02 20:35 +0300
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-05-02 15:35 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-05-05 04:39 -0700
Re: qsort() standard functions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-05-04 07:35 -0700
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-05-05 00:01 +0300
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-05-02 15:11 +0300
Re: qsort() standard functions Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-02 16:36 +0100
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-04-27 14:47 +0300
Re: qsort() standard functions Robert Wessel <robertwessel2@yahoo.com> - 2019-04-27 08:30 -0500
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-05-02 14:52 +0300
Re: qsort() standard functions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-05-04 07:13 -0700
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-05-05 22:57 +0300
Re: qsort() standard functions David Brown <david.brown@hesbynett.no> - 2019-05-06 10:09 +0200
Re: qsort() standard functions Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-01 05:22 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-25 17:09 -0700
Re: qsort() standard functions Bart <bc@freeuk.com> - 2019-04-26 10:58 +0100
Re: qsort() standard functions mark.bluemel@gmail.com - 2019-04-26 03:59 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-26 06:34 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-26 07:16 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-26 07:45 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-26 08:29 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-26 12:06 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-26 13:09 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-26 13:37 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-26 14:05 -0700
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-04-27 14:59 +0300
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-27 06:19 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-27 06:32 -0700
Re: qsort() standard functions Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-04-24 10:54 -0600
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 10:10 -0700
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-04-25 00:06 +0300
Re: qsort() standard functions scott@slp53.sl.home (Scott Lurndal) - 2019-04-24 17:37 +0000
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 10:56 -0700
Re: qsort() standard functions Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-04-24 12:12 -0600
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 14:27 -0400
Re: qsort() standard functions John Bode <jfbode1029@gmail.com> - 2019-04-24 11:44 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 11:57 -0700
Re: qsort() standard functions fir <profesor.fir@gmail.com> - 2019-04-24 12:04 -0700
Re: qsort() standard functions nobody@example.org (Scott) - 2019-04-25 01:16 +0000
Re: qsort() standard functions James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-04-24 21:38 -0400
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 14:42 -0400
Re: qsort() standard functions David Brown <david.brown@hesbynett.no> - 2019-04-24 22:13 +0200
Re: qsort() standard functions queequeg@trust.no1 (Queequeg) - 2019-04-24 20:46 +0000
Re: qsort() standard functions jadill33@gmail.com - 2019-04-24 14:01 -0700
Re: qsort() standard functions "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2019-04-24 15:41 -0700
Re: qsort() standard functions "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-04-26 22:24 +0800
Re: qsort() standard functions Anton Shepelev <anton.txt@gmail.com> - 2019-05-02 15:05 +0300
Re: qsort() standard functions "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-05-03 17:02 +0800
Re: qsort() standard functions Chad <cdalten@gmail.com> - 2019-05-03 10:10 -0700
Re: qsort() standard functions "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-05-04 01:22 +0800
Re: qsort() standard functions Chad <cdalten@gmail.com> - 2019-05-03 15:14 -0700
[OT]Eternal.... programmer? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-05-04 06:20 +0800
Re: [OT]Eternal.... programmer? Chad <cdalten@gmail.com> - 2019-05-04 05:53 -0700
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-04-24 19:12 +0000 |
| Message-ID | <q9qcff$hs6$1@news.xmission.com> |
| In reply to | #143391 |
In article <60431626-a673-4a46-afc9-9d180ee434e3@googlegroups.com>,
John Bode <jfbode1029@gmail.com> wrote:
...
>Grow the hell up, Rick.
Asking Rick to grow up is, well, the essence of the problem.
His being who he is is, well, the essence of Rick being Rick.
Like the tides and the seasons, it ain't gonna change.
--
One should not believe everything posted to USENET.
- Aharon (Arnold) Robbins arnold AT skeeve DOT com -
- 4/15/19 -
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2019-04-24 16:05 -0400 |
| Message-ID | <q9qfg0$13g$1@dont-email.me> |
| In reply to | #143391 |
On 4/24/2019 2:52 PM, John Bode wrote: > So you rely on *us* to invest all the time and effort you don't want to so we can answer > *your* questions. For trivial questions like this, sometimes. > And I thought *I* was lazy. > > Seriously, why do you think we *can* answer your (ridiculously easy) questions off the top > of our heads? How do you think we acquired that knowledge? You think we were born with > it? Had it downloaded straight into our heads a la The Matrix? You are C experts. And you participate in the comp.lang.c group to help people and discuss things related to C. > What makes you so .. entitled that you believe you shouldn't have to put in > *any* effort of your own? It was a trivial question. I had no idea it would evoke such emotion. > Grow the hell up, Rick. Your replies to me seem unjustifiably harsh and hateful given the question I asked. I believe you are letting the content of my other threads influence your attitude toward me in this thread. At least I know you are reading and hearing the things I post in the other threads, otherwise you wouldn't be so fired up. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | queequeg@trust.no1 (Queequeg) |
|---|---|
| Date | 2019-04-24 20:39 +0000 |
| Message-ID | <e17b058f-b603-414f-b1e5-f313bf8db50f@trust.no1> |
| In reply to | #143400 |
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote: > You are C experts. And you participate in the comp.lang.c group to > help people and discuss things related to C. To help people, not to be their Google interface. > I believe you are letting the content of my other threads influence your > attitude toward me in this thread. > > At least I know you are reading and hearing the things I post in the > other threads, otherwise you wouldn't be so fired up. At least now we know the true reason behind your posts. It's called trolling. -- https://www.youtube.com/watch?v=9lSzL1DqQn0
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-04-24 16:33 -0700 |
| Message-ID | <0d19a9be-1e22-47d2-b5d7-f36d0694cf7e@googlegroups.com> |
| In reply to | #143388 |
On Wednesday, April 24, 2019 at 2:40:25 PM UTC-4, Rick C. Hodgin wrote: > On 4/24/2019 2:33 PM, John Bode wrote: ... > > You would check what functions *are* listed in the standard library - if none of them look > > like the functions you're expecting to see, then that's your answer. Presumably if they > > existed, they'd be described alongside qsort() and bsearch(). > > > > There's nothing stopping individual implementations from providing their own comparison > > functions (I'm not aware of any that do offhand), but again, that's a matter of checking > > the documentation. > > I see the pages 493 to 520 with standard library functions. I did a > search for "const void *, const void *" to see how many functions there > were with that signature and I found four references (bsearch() and > qsort(), twice each). It was suggested that you should search for the descriptions of the bsearch() and qsort() functions, to see whether any suitable helper functions were mentioned there. All of the relevant description is in section 7.22.5, which is all of two pages long. It should not have taken you very long to read that section and verify that it contains no such cross-references. However, if you're going to randomly search for functions that just happen to have the right function type, there's an important issue you should keep in mind: 6.2.5p28: "A pointer to void shall have the same representation and alignment requirements as a pointer to a character type.48)", where "48)" is a reference to footnote 48: "The same representation and alignment requirements are meant to imply interchangeability as arguments to functions, return values from functions, and members of unions." Notice that the standard does not in fact guarantee such interchangeability, so I would ordinarily recommend not relying upon it. The footnote merely asserts that the phrase was "meant to imply" it, which is a statement about the mental state of the authors of the standard, and presumably correct. However, having the "same representation and alignment requirements" does NOT, in fact, imply interchangeability. Among other things, in order to be interchangeable, both types need to use the same protocol when passed as an argument to or returned as a value from a function. They might, for instance be passed around using different registers. However, in the real world, there's usually no good reason to use different protocols for such types. Therefore, you would probably be able to get away with taking a function with the type int(const char*, const char*), and converting a pointer to that function to int(*)(const void*, const void*) before passing it to either bsearch() or qsort(). I found three such functions in the C standard library: rename(), strcmp(), and strcoll(). If you created an array of fixed-length arrays of char, each of which contained at least one null character, and passed either strcmp() or strcoll() along with that array to either bsearch() or qsort(), there's a pretty good chance that it would work as desired. I remember actually doing that with strcmp() at one time, though that might have been before void* was standardized, in which case there would not have been any type compatibility issues. rename() is a different matter, since it can return a different value on two consecutive calls with the same arguments. A comparison function is supposed to impose a total ordering on the elements of the array. The behavior when the second argument of rename() names an existing file is implementation-defined, and the non-zero value returned when rename() fails is unspecified. Depending upon how an implementation chooses to handle those issues, there might some way of getting rename() to impose a total order - but I'm not going to bother figuring out how.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-04-24 19:18 +0000 |
| Message-ID | <q9qcpl$hs6$2@news.xmission.com> |
| In reply to | #143379 |
In article <fda6fac4-7cdb-4c35-9383-9c65a154a70f@googlegroups.com>,
John Bode <jfbode1029@gmail.com> wrote:
>On Wednesday, April 24, 2019 at 11:35:26 AM UTC-5, John Bode wrote:
>> On Wednesday, April 24, 2019 at 11:08:57 AM UTC-5, rick....@gmail.com wrote:
>> > Does qsort() provide any standard function support? Like if
>> > I'm sorting a list of integers, is there a qsort_int() func
>> > I can use without creating my own? And what about strings?
>> > Or other things which are standard forms to C?
>> >
>> > --
>> > Rick C. Hodgin
>>
>> Nope. Gotta roll your own, even for primitive types.
>
>For future reference, an online draft of the 2011 standard is here:
>
>http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
>
>It will tell you what is in the standard library.
To be fair, the problem is that reading the standards documents will only
tell you what *is* in there. It won't tell you what isn't there.
Unless and until you've committed the whole thing to memory, as many
long-time CLC posters clearly have done, you won't know from reading it if
the thing you seek isn't in there.
Therefore, I actually get where Rick is coming from. Not being a class-A
CLC nerd, he hasn't committed the thing to memory. But he knows that many
of you have, so he comes here hoping to put some of that knowledge to use.
Think of it this way: Rick's asking this question *validates* your having
committed the whole damn thing to memory. He has given you a reason for
having done this otherwise stupid and pointless thing. For that, he should
be thanked, not mocked.
He has given you an opportunity to show off - and to validate your
otherwise useless life.
--
The difference between communism and capitalism?
In capitalism, man exploits man. In communism, it's the other way around.
- Daniel Bell, The End of Ideology (1960) -
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-04-24 20:28 +0100 |
| Message-ID | <VN2wE.143713$II6.127282@fx07.am4> |
| In reply to | #143395 |
On 24/04/2019 20:18, Kenny McCormack wrote: > In article <fda6fac4-7cdb-4c35-9383-9c65a154a70f@googlegroups.com>, >> It will tell you what is in the standard library. > > To be fair, the problem is that reading the standards documents will only > tell you what *is* in there. It won't tell you what isn't there. > > Unless and until you've committed the whole thing to memory, as many > long-time CLC posters clearly have done, you won't know from reading it if > the thing you seek isn't in there. It's a wonder a group such as this exists, given the answers to all possible C questions are within those 700-odd pages. And the answers to all queries about compilers and libraries and OSes will be in their respective documentation.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-04-24 21:27 +0000 |
| Message-ID | <q9qkc8$mci$1@news.xmission.com> |
| In reply to | #143397 |
In article <VN2wE.143713$II6.127282@fx07.am4>, Bart <bc@freeuk.com> wrote:
>On 24/04/2019 20:18, Kenny McCormack wrote:
>> In article <fda6fac4-7cdb-4c35-9383-9c65a154a70f@googlegroups.com>,
>
>>> It will tell you what is in the standard library.
>>
>> To be fair, the problem is that reading the standards documents will only
>> tell you what *is* in there. It won't tell you what isn't there.
>>
>> Unless and until you've committed the whole thing to memory, as many
>> long-time CLC posters clearly have done, you won't know from reading it if
>> the thing you seek isn't in there.
>
>It's a wonder a group such as this exists, given the answers to all
>possible C questions are within those 700-odd pages.
Quite so. When a group explicitly limits its scope to a given document,
then all possible questions are already answered.
I've noted this before. Since all possible questions have already been
answered, it is true by definition that every possible post is off-topic.
(Since part of the definition of "off-topc" is "A question that's already
been answered - generally, many times...")
>And the answers to all queries about compilers and libraries and OSes
>will be in their respective documentation.
--
The scent of awk programmers is a lot more attractive to women than
the scent of perl programmers.
(Mike Brennan, quoted in the "GAWK" manual)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-04-24 12:31 -0700 |
| Message-ID | <8aec9702-80a2-4766-b3a1-053c967e505f@googlegroups.com> |
| In reply to | #143395 |
W dniu środa, 24 kwietnia 2019 21:18:21 UTC+2 użytkownik Kenny McCormack napisał: > In article <fda6fac4-7cdb-4c35-9383-9c65a154a70f@googlegroups.com>, > John Bode <jfbode1029@gmail.com> wrote: > >On Wednesday, April 24, 2019 at 11:35:26 AM UTC-5, John Bode wrote: > >> On Wednesday, April 24, 2019 at 11:08:57 AM UTC-5, rick....@gmail.com wrote: > >> > Does qsort() provide any standard function support? Like if > >> > I'm sorting a list of integers, is there a qsort_int() func > >> > I can use without creating my own? And what about strings? > >> > Or other things which are standard forms to C? > >> > > >> > -- > >> > Rick C. Hodgin > >> > >> Nope. Gotta roll your own, even for primitive types. > > > >For future reference, an online draft of the 2011 standard is here: > > > >http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf > > > >It will tell you what is in the standard library. > > To be fair, the problem is that reading the standards documents will only > tell you what *is* in there. It won't tell you what isn't there. > > Unless and until you've committed the whole thing to memory, as many > long-time CLC posters clearly have done, you won't know from reading it if > the thing you seek isn't in there. > > Therefore, I actually get where Rick is coming from. Not being a class-A > CLC nerd, he hasn't committed the thing to memory. But he knows that many > of you have, so he comes here hoping to put some of that knowledge to use. > > Think of it this way: Rick's asking this question *validates* your having > committed the whole damn thing to memory. He has given you a reason for > having done this otherwise stupid and pointless thing. For that, he should > be thanked, not mocked. > > He has given you an opportunity to show off - and to validate your > otherwise useless life. > i also find this kind of naive questions are not a problem (i sometimes ask (asked) them - thsi is becouse when coding sometimes i felt so tired i was unable to set my mind up to google it alone) the problem is hella different, dik is heavy blockhed and 'powerful' (or rather powerfool) devestator whit a long and bad history of harm here, this group will not be free will always be stupidized and bored if dik will be feeded and his attampts to stupidize this place constantly amplified arent you curious how this group can get healthier without this stupidizations? maybe something more interesting would born? help thsi group and mark spammers and imbeciles as spam instead allowing it to grow and destroy sanity
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2019-04-24 13:02 -0700 |
| Message-ID | <b648a32d-5671-4702-9b6d-5ecba83f3559@googlegroups.com> |
| In reply to | #143395 |
On Wednesday, April 24, 2019 at 2:18:21 PM UTC-5, Kenny McCormack wrote: > In article <fda6fac4-7cdb-4c35-9383-9c65a154a70f@googlegroups.com>, [snip] > Think of it this way: Rick's asking this question *validates* your having > committed the whole damn thing to memory. He has given you a reason for > having done this otherwise stupid and pointless thing. For that, he should > be thanked, not mocked. > > He has given you an opportunity to show off - and to validate your > otherwise useless life. > Funny, I thought that's what my job was for...
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-04-24 13:41 -0700 |
| Message-ID | <19389b6d-4521-467c-8308-8fc152e94e1b@googlegroups.com> |
| In reply to | #143399 |
W dniu środa, 24 kwietnia 2019 22:03:16 UTC+2 użytkownik John Bode napisał: > On Wednesday, April 24, 2019 at 2:18:21 PM UTC-5, Kenny McCormack wrote: > > In article <fda6fac4-7cdb-4c35-9383-9c65a154a70f@googlegroups.com>, > > [snip] > > > Think of it this way: Rick's asking this question *validates* your having > > committed the whole damn thing to memory. He has given you a reason for > > having done this otherwise stupid and pointless thing. For that, he should > > be thanked, not mocked. > > > > He has given you an opportunity to show off - and to validate your > > otherwise useless life. > > > > Funny, I thought that's what my job was for... dik is sorta grower (farmer) but instead to grow marijuana he growsseeds of stupidity and some 'unresponsible users' water it alowst the bushes of stupidity grow for naow it may be a good mood as he get some break (and my thread on stackless c was interesting and genereted sane thread) but soon if bushes will grow the doom of stupidity will act again and really its no fun (i know what im saying) (as i said it already started, stop it when you can... its really no fun to waste time and braincells on it and again..its devastating and simply boring )
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-04-24 14:00 -0700 |
| Message-ID | <e81a78e6-05ff-442e-b037-8005bf2fe0a1@googlegroups.com> |
| In reply to | #143403 |
W dniu środa, 24 kwietnia 2019 22:42:16 UTC+2 użytkownik fir napisał: > W dniu środa, 24 kwietnia 2019 22:03:16 UTC+2 użytkownik John Bode napisał: > > On Wednesday, April 24, 2019 at 2:18:21 PM UTC-5, Kenny McCormack wrote: > > > In article <fda6fac4-7cdb-4c35-9383-9c65a154a70f@googlegroups.com>, > > > > [snip] > > > > > Think of it this way: Rick's asking this question *validates* your having > > > committed the whole damn thing to memory. He has given you a reason for > > > having done this otherwise stupid and pointless thing. For that, he should > > > be thanked, not mocked. > > > > > > He has given you an opportunity to show off - and to validate your > > > otherwise useless life. > > > > > > > Funny, I thought that's what my job was for... > > dik is sorta grower (farmer) but instead to grow marijuana he growsseeds of stupidity and some 'unresponsible users' water it alowst the bushes of stupidity grow > > for naow it may be a good mood as he get some break (and my thread on stackless c was interesting and genereted sane thread) but soon if bushes will grow the doom of stupidity will act again and really its no fun (i know what im saying) > > (as i said it already started, stop it when you can... its really no fun to waste time and braincells on it and again..its devastating and simply boring ) if someone is boring instead of reading and answering dik (even reading is harmfull) state some usefull thread, i dont know it might be "how to write a quicksort in non stack version" that would be something usefull (in wiki afai is a version on stack and c lib verion of quicksort wouldnt be optimal if it firec function for every comparison, and mayybe use recursion under the hood) so working out code of non stack ersions, maybe made some contest for most quick version would be usefull (i would state it but i got no time to much work on it myself so it wouldnt be unfair to state it i guess - but this is a proposition of sane thread if someone is bored)
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-04-25 00:22 +0300 |
| Message-ID | <20190425002215.1c2496a880790d835596fc4e@gmail.com> |
| In reply to | #143405 |
fir:
> if someone is boring instead of reading and answering dik
> (even reading is harmfull) state some usefull thread, i
> dont know it might be
>
> "how to write a quicksort in non stack version"
Good idea. Here is my quick take at it:
------------------------------------ sort.h ------------------------------------
/* Comparison function:
> 0 <=> data[i] > data[j]
< 0 <=> data[i] < data[j]
== 0 <=> data[i] = data[j] */
typedef int (*comp_f)( void * data, int i, int j, const void * extra );
typedef void (*swap_f)( void * data, int i, int j );
void sort /* sort an array */
( void * data, /* pointer to the array to be sorted */
int len, /* length of that array */
comp_f comp, /* comparison function */
swap_f swap, /* swap function */
const void * extra /* user-suppied data to comp */
);
------------------------------------ sort.c ------------------------------------
#include <stdio.h>
#include <limits.h>
#include "sort.h"
static int partition
( void * data,
int l,
int r,
comp_f comp,
swap_f swap,
const void * extra
)
{ int m;
m = (l + r)/2;
while( 1 )
{ while( comp(data, l, m, extra) < 0 ) l = l + 1;
while( comp(data, r, m, extra) > 0 ) r = r - 1;
if( l >= r ) break;
swap( data, l, r );
if( l == m ) m = r;
else if( r == m ) m = l;
l = l + 1; r = r - 1;
}
return r;
}
void sort
( void * data,
int len,
comp_f comp,
swap_f swap,
const void * extra
)
{ int sl[sizeof(int) * CHAR_BIT];
int sr[sizeof(int) * CHAR_BIT];
int newr, q, l, r, lpos, rpos;
q = 1;
l = 0; r = len - 1;
sl[0] = l; sr[0] = r;
while( q > 0 )
{ q = q - 1;
l = sl[q]; r = sr[q];
if( l >= r ) continue;
newr = partition( data, l , r, comp, swap, extra );
/* process the shorter sub-array first to ease the stack: */
lpos = q; rpos = q;
if( newr - l > r - newr - 1 ) rpos = rpos + 1;
else lpos = lpos + 1;
sl[lpos] = l; sr[lpos] = newr;
sl[rpos] = newr+1; sr[rpos] = r;
q = q + 2;
}
}
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-04-24 15:04 -0700 |
| Message-ID | <80f77202-d485-47aa-837d-2c2b4e55dfc9@googlegroups.com> |
| In reply to | #143408 |
W dniu środa, 24 kwietnia 2019 23:22:23 UTC+2 użytkownik Anton Shepelev napisał:
> fir:
>
> > if someone is boring instead of reading and answering dik
> > (even reading is harmfull) state some usefull thread, i
> > dont know it might be
> >
> > "how to write a quicksort in non stack version"
>
> Good idea. Here is my quick take at it:
> ------------------------------------ sort.h ------------------------------------
> /* Comparison function:
> > 0 <=> data[i] > data[j]
> < 0 <=> data[i] < data[j]
> == 0 <=> data[i] = data[j] */
> typedef int (*comp_f)( void * data, int i, int j, const void * extra );
> typedef void (*swap_f)( void * data, int i, int j );
>
> void sort /* sort an array */
> ( void * data, /* pointer to the array to be sorted */
> int len, /* length of that array */
> comp_f comp, /* comparison function */
> swap_f swap, /* swap function */
> const void * extra /* user-suppied data to comp */
> );
> ------------------------------------ sort.c ------------------------------------
> #include <stdio.h>
> #include <limits.h>
> #include "sort.h"
>
> static int partition
> ( void * data,
> int l,
> int r,
> comp_f comp,
> swap_f swap,
> const void * extra
> )
> { int m;
>
> m = (l + r)/2;
> while( 1 )
> { while( comp(data, l, m, extra) < 0 ) l = l + 1;
> while( comp(data, r, m, extra) > 0 ) r = r - 1;
> if( l >= r ) break;
> swap( data, l, r );
> if( l == m ) m = r;
> else if( r == m ) m = l;
> l = l + 1; r = r - 1;
> }
> return r;
> }
>
> void sort
> ( void * data,
> int len,
> comp_f comp,
> swap_f swap,
> const void * extra
> )
> { int sl[sizeof(int) * CHAR_BIT];
> int sr[sizeof(int) * CHAR_BIT];
> int newr, q, l, r, lpos, rpos;
>
> q = 1;
> l = 0; r = len - 1;
> sl[0] = l; sr[0] = r;
> while( q > 0 )
> { q = q - 1;
> l = sl[q]; r = sr[q];
> if( l >= r ) continue;
>
> newr = partition( data, l , r, comp, swap, extra );
>
> /* process the shorter sub-array first to ease the stack: */
> lpos = q; rpos = q;
> if( newr - l > r - newr - 1 ) rpos = rpos + 1;
> else lpos = lpos + 1;
>
> sl[lpos] = l; sr[lpos] = newr;
> sl[rpos] = newr+1; sr[rpos] = r;
> q = q + 2;
> }
> }
>
good someone take response but it would be better to state it as new thread (it has then granted like a boost to publicity ;c )
i may see it rather toomoroorw as i go to sleep; (and as i said this is interesting but im not necessary in mood to do it, ebentually i may check if i would wrote it better/more in my style) is it checked if it work? some runtime time measurments could be done and compare if it is faster.. (than stack version)
i also think that for simplicity it could be only a version that sorts say array of floats, dont need to be general, simpletr is better for illustration
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-04-24 15:20 -0700 |
| Message-ID | <4313c268-dcfe-4253-b089-f5d431b1aafb@googlegroups.com> |
| In reply to | #143410 |
W dniu czwartek, 25 kwietnia 2019 00:04:48 UTC+2 użytkownik fir napisał:
> W dniu środa, 24 kwietnia 2019 23:22:23 UTC+2 użytkownik Anton Shepelev napisał:
> > fir:
> >
> > > if someone is boring instead of reading and answering dik
> > > (even reading is harmfull) state some usefull thread, i
> > > dont know it might be
> > >
> > > "how to write a quicksort in non stack version"
> >
> > Good idea. Here is my quick take at it:
> > ------------------------------------ sort.h ------------------------------------
> > /* Comparison function:
> > > 0 <=> data[i] > data[j]
> > < 0 <=> data[i] < data[j]
> > == 0 <=> data[i] = data[j] */
> > typedef int (*comp_f)( void * data, int i, int j, const void * extra );
> > typedef void (*swap_f)( void * data, int i, int j );
> >
> > void sort /* sort an array */
> > ( void * data, /* pointer to the array to be sorted */
> > int len, /* length of that array */
> > comp_f comp, /* comparison function */
> > swap_f swap, /* swap function */
> > const void * extra /* user-suppied data to comp */
> > );
> > ------------------------------------ sort.c ------------------------------------
> > #include <stdio.h>
> > #include <limits.h>
> > #include "sort.h"
> >
> > static int partition
> > ( void * data,
> > int l,
> > int r,
> > comp_f comp,
> > swap_f swap,
> > const void * extra
> > )
> > { int m;
> >
> > m = (l + r)/2;
> > while( 1 )
> > { while( comp(data, l, m, extra) < 0 ) l = l + 1;
> > while( comp(data, r, m, extra) > 0 ) r = r - 1;
> > if( l >= r ) break;
> > swap( data, l, r );
> > if( l == m ) m = r;
> > else if( r == m ) m = l;
> > l = l + 1; r = r - 1;
> > }
> > return r;
> > }
> >
> > void sort
> > ( void * data,
> > int len,
> > comp_f comp,
> > swap_f swap,
> > const void * extra
> > )
> > { int sl[sizeof(int) * CHAR_BIT];
> > int sr[sizeof(int) * CHAR_BIT];
> > int newr, q, l, r, lpos, rpos;
> >
> > q = 1;
> > l = 0; r = len - 1;
> > sl[0] = l; sr[0] = r;
> > while( q > 0 )
> > { q = q - 1;
> > l = sl[q]; r = sr[q];
> > if( l >= r ) continue;
> >
> > newr = partition( data, l , r, comp, swap, extra );
> >
> > /* process the shorter sub-array first to ease the stack: */
> > lpos = q; rpos = q;
> > if( newr - l > r - newr - 1 ) rpos = rpos + 1;
> > else lpos = lpos + 1;
> >
> > sl[lpos] = l; sr[lpos] = newr;
> > sl[rpos] = newr+1; sr[rpos] = r;
> > q = q + 2;
> > }
> > }
> >
> good someone take response but it would be better to state it as new thread (it has then granted like a boost to publicity ;c )
> i may see it rather toomoroorw as i go to sleep; (and as i said this is interesting but im not necessary in mood to do it, ebentually i may check if i would wrote it better/more in my style) is it checked if it work? some runtime time measurments could be done and compare if it is faster.. (than stack version)
>
> i also think that for simplicity it could be only a version that sorts say array of floats, dont need to be general, simpletr is better for illustration
besides wat is the idea - roughly looking i doubt if it will work 9hovever id ont readed into it longer than few minutes and odnt know what some ariables mean, like q
in recursive auicksort afair you take initial partition take some walue in the middle of it then swipe less than ot on its left bigger on its right
then you do the same recursively with left and right part
in some non recursive version you would need to get rid some way this recursive part, and the question is how
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-04-24 15:40 -0700 |
| Message-ID | <9eb64b53-05ac-4eb5-8a48-053341616af3@googlegroups.com> |
| In reply to | #143411 |
W dniu czwartek, 25 kwietnia 2019 00:21:14 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 25 kwietnia 2019 00:04:48 UTC+2 użytkownik fir napisał:
> > W dniu środa, 24 kwietnia 2019 23:22:23 UTC+2 użytkownik Anton Shepelev napisał:
> > > fir:
> > >
> > > > if someone is boring instead of reading and answering dik
> > > > (even reading is harmfull) state some usefull thread, i
> > > > dont know it might be
> > > >
> > > > "how to write a quicksort in non stack version"
> > >
> > > Good idea. Here is my quick take at it:
> > > ------------------------------------ sort.h ------------------------------------
> > > /* Comparison function:
> > > > 0 <=> data[i] > data[j]
> > > < 0 <=> data[i] < data[j]
> > > == 0 <=> data[i] = data[j] */
> > > typedef int (*comp_f)( void * data, int i, int j, const void * extra );
> > > typedef void (*swap_f)( void * data, int i, int j );
> > >
> > > void sort /* sort an array */
> > > ( void * data, /* pointer to the array to be sorted */
> > > int len, /* length of that array */
> > > comp_f comp, /* comparison function */
> > > swap_f swap, /* swap function */
> > > const void * extra /* user-suppied data to comp */
> > > );
> > > ------------------------------------ sort.c ------------------------------------
> > > #include <stdio.h>
> > > #include <limits.h>
> > > #include "sort.h"
> > >
> > > static int partition
> > > ( void * data,
> > > int l,
> > > int r,
> > > comp_f comp,
> > > swap_f swap,
> > > const void * extra
> > > )
> > > { int m;
> > >
> > > m = (l + r)/2;
> > > while( 1 )
> > > { while( comp(data, l, m, extra) < 0 ) l = l + 1;
> > > while( comp(data, r, m, extra) > 0 ) r = r - 1;
> > > if( l >= r ) break;
> > > swap( data, l, r );
> > > if( l == m ) m = r;
> > > else if( r == m ) m = l;
> > > l = l + 1; r = r - 1;
> > > }
> > > return r;
> > > }
> > >
> > > void sort
> > > ( void * data,
> > > int len,
> > > comp_f comp,
> > > swap_f swap,
> > > const void * extra
> > > )
> > > { int sl[sizeof(int) * CHAR_BIT];
> > > int sr[sizeof(int) * CHAR_BIT];
> > > int newr, q, l, r, lpos, rpos;
> > >
> > > q = 1;
> > > l = 0; r = len - 1;
> > > sl[0] = l; sr[0] = r;
> > > while( q > 0 )
> > > { q = q - 1;
> > > l = sl[q]; r = sr[q];
> > > if( l >= r ) continue;
> > >
> > > newr = partition( data, l , r, comp, swap, extra );
> > >
> > > /* process the shorter sub-array first to ease the stack: */
> > > lpos = q; rpos = q;
> > > if( newr - l > r - newr - 1 ) rpos = rpos + 1;
> > > else lpos = lpos + 1;
> > >
> > > sl[lpos] = l; sr[lpos] = newr;
> > > sl[rpos] = newr+1; sr[rpos] = r;
> > > q = q + 2;
> > > }
> > > }
> > >
> > good someone take response but it would be better to state it as new thread (it has then granted like a boost to publicity ;c )
> > i may see it rather toomoroorw as i go to sleep; (and as i said this is interesting but im not necessary in mood to do it, ebentually i may check if i would wrote it better/more in my style) is it checked if it work? some runtime time measurments could be done and compare if it is faster.. (than stack version)
> >
> > i also think that for simplicity it could be only a version that sorts say array of floats, dont need to be general, simpletr is better for illustration
>
> besides wat is the idea - roughly looking i doubt if it will work 9hovever id ont readed into it longer than few minutes and odnt know what some ariables mean, like q
>
> in recursive auicksort afair you take initial partition take some walue in the middle of it then swipe less than ot on its left bigger on its right
>
> then you do the same recursively with left and right part
>
> in some non recursive version you would need to get rid some way this recursive part, and the question is how
a bit thinking on it:
say you sort 1000 floats
you take soem value from midle and swipe
say it ended you got two partitions
0 to 776 and 778 to 999
by the function named
int SwipePartition(int first, int last);
it seems in non recursive version you should add those resulted two partition boundaries to array
0, 776
778 ,999
then run it on in loop on this array, working on first one will again produce two so like this first may be replaced by left but you got three and run it untill it will be consumed
hope you get it
i belive that verion should be faster than atack based one becouse you dont pass retvalues on stack (if that sorting is long that ammout of retvalues to pass on stack may be counted in megabytes and that makes additional cost so non stack version 'should' be faster (it seems to me but i never checked it, besides its more safe as you may conroll stack overflow (by allocking anough ram for most pessymistic case of at least by adding if-check though this might cost a bit in runtime so maybe its not preffered
i eventually can maybe test it toomorrow
(at least that kind of threads makes something useful not like hodgin mental devastations or other cheap blablings)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-04-24 15:57 -0700 |
| Message-ID | <ae3d83e3-0647-4474-b496-2b77da35d46d@googlegroups.com> |
| In reply to | #143412 |
W dniu czwartek, 25 kwietnia 2019 00:41:07 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 25 kwietnia 2019 00:21:14 UTC+2 użytkownik fir napisał:
> > W dniu czwartek, 25 kwietnia 2019 00:04:48 UTC+2 użytkownik fir napisał:
> > > W dniu środa, 24 kwietnia 2019 23:22:23 UTC+2 użytkownik Anton Shepelev napisał:
> > > > fir:
> > > >
> > > > > if someone is boring instead of reading and answering dik
> > > > > (even reading is harmfull) state some usefull thread, i
> > > > > dont know it might be
> > > > >
> > > > > "how to write a quicksort in non stack version"
> > > >
> > > > Good idea. Here is my quick take at it:
> > > > ------------------------------------ sort.h ------------------------------------
> > > > /* Comparison function:
> > > > > 0 <=> data[i] > data[j]
> > > > < 0 <=> data[i] < data[j]
> > > > == 0 <=> data[i] = data[j] */
> > > > typedef int (*comp_f)( void * data, int i, int j, const void * extra );
> > > > typedef void (*swap_f)( void * data, int i, int j );
> > > >
> > > > void sort /* sort an array */
> > > > ( void * data, /* pointer to the array to be sorted */
> > > > int len, /* length of that array */
> > > > comp_f comp, /* comparison function */
> > > > swap_f swap, /* swap function */
> > > > const void * extra /* user-suppied data to comp */
> > > > );
> > > > ------------------------------------ sort.c ------------------------------------
> > > > #include <stdio.h>
> > > > #include <limits.h>
> > > > #include "sort.h"
> > > >
> > > > static int partition
> > > > ( void * data,
> > > > int l,
> > > > int r,
> > > > comp_f comp,
> > > > swap_f swap,
> > > > const void * extra
> > > > )
> > > > { int m;
> > > >
> > > > m = (l + r)/2;
> > > > while( 1 )
> > > > { while( comp(data, l, m, extra) < 0 ) l = l + 1;
> > > > while( comp(data, r, m, extra) > 0 ) r = r - 1;
> > > > if( l >= r ) break;
> > > > swap( data, l, r );
> > > > if( l == m ) m = r;
> > > > else if( r == m ) m = l;
> > > > l = l + 1; r = r - 1;
> > > > }
> > > > return r;
> > > > }
> > > >
> > > > void sort
> > > > ( void * data,
> > > > int len,
> > > > comp_f comp,
> > > > swap_f swap,
> > > > const void * extra
> > > > )
> > > > { int sl[sizeof(int) * CHAR_BIT];
> > > > int sr[sizeof(int) * CHAR_BIT];
> > > > int newr, q, l, r, lpos, rpos;
> > > >
> > > > q = 1;
> > > > l = 0; r = len - 1;
> > > > sl[0] = l; sr[0] = r;
> > > > while( q > 0 )
> > > > { q = q - 1;
> > > > l = sl[q]; r = sr[q];
> > > > if( l >= r ) continue;
> > > >
> > > > newr = partition( data, l , r, comp, swap, extra );
> > > >
> > > > /* process the shorter sub-array first to ease the stack: */
> > > > lpos = q; rpos = q;
> > > > if( newr - l > r - newr - 1 ) rpos = rpos + 1;
> > > > else lpos = lpos + 1;
> > > >
> > > > sl[lpos] = l; sr[lpos] = newr;
> > > > sl[rpos] = newr+1; sr[rpos] = r;
> > > > q = q + 2;
> > > > }
> > > > }
> > > >
> > > good someone take response but it would be better to state it as new thread (it has then granted like a boost to publicity ;c )
> > > i may see it rather toomoroorw as i go to sleep; (and as i said this is interesting but im not necessary in mood to do it, ebentually i may check if i would wrote it better/more in my style) is it checked if it work? some runtime time measurments could be done and compare if it is faster.. (than stack version)
> > >
> > > i also think that for simplicity it could be only a version that sorts say array of floats, dont need to be general, simpletr is better for illustration
> >
> > besides wat is the idea - roughly looking i doubt if it will work 9hovever id ont readed into it longer than few minutes and odnt know what some ariables mean, like q
> >
> > in recursive auicksort afair you take initial partition take some walue in the middle of it then swipe less than ot on its left bigger on its right
> >
> > then you do the same recursively with left and right part
> >
> > in some non recursive version you would need to get rid some way this recursive part, and the question is how
>
> a bit thinking on it:
>
> say you sort 1000 floats
>
> you take soem value from midle and swipe
> say it ended you got two partitions
> 0 to 776 and 778 to 999
>
> by the function named
> int SwipePartition(int first, int last);
>
> it seems in non recursive version you should add those resulted two partition boundaries to array
>
>
> 0, 776
> 778 ,999
>
> then run it on in loop on this array, working on first one will again produce two so like this first may be replaced by left but you got three and run it untill it will be consumed
>
> hope you get it
>
> i belive that verion should be faster than atack based one becouse you dont pass retvalues on stack (if that sorting is long that ammout of retvalues to pass on stack may be counted in megabytes and that makes additional cost so non stack version 'should' be faster (it seems to me but i never checked it, besides its more safe as you may conroll stack overflow (by allocking anough ram for most pessymistic case of at least by adding if-check though this might cost a bit in runtime so maybe its not preffered
>
> i eventually can maybe test it toomorrow
> (at least that kind of threads makes something useful not like hodgin mental devastations or other cheap blablings)
imn some simpel schme this code shoule probably look sorte like this
AddPartitionBoundary(0,999)
for()
{
if(NoMorePartitions() break;
partition = TakePartitionToSwpie()
int div = SwipePartition(partition)
if(div-partition.left>1) AddPartitionBoundary(partition.left,div-1);
if(partition.right-div>1) AddPartitionBoundary(div+1,partition.right)
}
(not suere as to this >1 but dont even want to think now)
something like this maybe i will write it toomorrow
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2019-04-24 16:06 -0700 |
| Message-ID | <cfd3e5ea-bfd3-4e46-96e5-4785d017764a@googlegroups.com> |
| In reply to | #143414 |
W dniu czwartek, 25 kwietnia 2019 00:57:49 UTC+2 użytkownik fir napisał:
> W dniu czwartek, 25 kwietnia 2019 00:41:07 UTC+2 użytkownik fir napisał:
> > W dniu czwartek, 25 kwietnia 2019 00:21:14 UTC+2 użytkownik fir napisał:
> > > W dniu czwartek, 25 kwietnia 2019 00:04:48 UTC+2 użytkownik fir napisał:
> > > > W dniu środa, 24 kwietnia 2019 23:22:23 UTC+2 użytkownik Anton Shepelev napisał:
> > > > > fir:
> > > > >
> > > > > > if someone is boring instead of reading and answering dik
> > > > > > (even reading is harmfull) state some usefull thread, i
> > > > > > dont know it might be
> > > > > >
> > > > > > "how to write a quicksort in non stack version"
> > > > >
> > > > > Good idea. Here is my quick take at it:
> > > > > ------------------------------------ sort.h ------------------------------------
> > > > > /* Comparison function:
> > > > > > 0 <=> data[i] > data[j]
> > > > > < 0 <=> data[i] < data[j]
> > > > > == 0 <=> data[i] = data[j] */
> > > > > typedef int (*comp_f)( void * data, int i, int j, const void * extra );
> > > > > typedef void (*swap_f)( void * data, int i, int j );
> > > > >
> > > > > void sort /* sort an array */
> > > > > ( void * data, /* pointer to the array to be sorted */
> > > > > int len, /* length of that array */
> > > > > comp_f comp, /* comparison function */
> > > > > swap_f swap, /* swap function */
> > > > > const void * extra /* user-suppied data to comp */
> > > > > );
> > > > > ------------------------------------ sort.c ------------------------------------
> > > > > #include <stdio.h>
> > > > > #include <limits.h>
> > > > > #include "sort.h"
> > > > >
> > > > > static int partition
> > > > > ( void * data,
> > > > > int l,
> > > > > int r,
> > > > > comp_f comp,
> > > > > swap_f swap,
> > > > > const void * extra
> > > > > )
> > > > > { int m;
> > > > >
> > > > > m = (l + r)/2;
> > > > > while( 1 )
> > > > > { while( comp(data, l, m, extra) < 0 ) l = l + 1;
> > > > > while( comp(data, r, m, extra) > 0 ) r = r - 1;
> > > > > if( l >= r ) break;
> > > > > swap( data, l, r );
> > > > > if( l == m ) m = r;
> > > > > else if( r == m ) m = l;
> > > > > l = l + 1; r = r - 1;
> > > > > }
> > > > > return r;
> > > > > }
> > > > >
> > > > > void sort
> > > > > ( void * data,
> > > > > int len,
> > > > > comp_f comp,
> > > > > swap_f swap,
> > > > > const void * extra
> > > > > )
> > > > > { int sl[sizeof(int) * CHAR_BIT];
> > > > > int sr[sizeof(int) * CHAR_BIT];
> > > > > int newr, q, l, r, lpos, rpos;
> > > > >
> > > > > q = 1;
> > > > > l = 0; r = len - 1;
> > > > > sl[0] = l; sr[0] = r;
> > > > > while( q > 0 )
> > > > > { q = q - 1;
> > > > > l = sl[q]; r = sr[q];
> > > > > if( l >= r ) continue;
> > > > >
> > > > > newr = partition( data, l , r, comp, swap, extra );
> > > > >
> > > > > /* process the shorter sub-array first to ease the stack: */
> > > > > lpos = q; rpos = q;
> > > > > if( newr - l > r - newr - 1 ) rpos = rpos + 1;
> > > > > else lpos = lpos + 1;
> > > > >
> > > > > sl[lpos] = l; sr[lpos] = newr;
> > > > > sl[rpos] = newr+1; sr[rpos] = r;
> > > > > q = q + 2;
> > > > > }
> > > > > }
> > > > >
> > > > good someone take response but it would be better to state it as new thread (it has then granted like a boost to publicity ;c )
> > > > i may see it rather toomoroorw as i go to sleep; (and as i said this is interesting but im not necessary in mood to do it, ebentually i may check if i would wrote it better/more in my style) is it checked if it work? some runtime time measurments could be done and compare if it is faster.. (than stack version)
> > > >
> > > > i also think that for simplicity it could be only a version that sorts say array of floats, dont need to be general, simpletr is better for illustration
> > >
> > > besides wat is the idea - roughly looking i doubt if it will work 9hovever id ont readed into it longer than few minutes and odnt know what some ariables mean, like q
> > >
> > > in recursive auicksort afair you take initial partition take some walue in the middle of it then swipe less than ot on its left bigger on its right
> > >
> > > then you do the same recursively with left and right part
> > >
> > > in some non recursive version you would need to get rid some way this recursive part, and the question is how
> >
> > a bit thinking on it:
> >
> > say you sort 1000 floats
> >
> > you take soem value from midle and swipe
> > say it ended you got two partitions
> > 0 to 776 and 778 to 999
> >
> > by the function named
> > int SwipePartition(int first, int last);
> >
> > it seems in non recursive version you should add those resulted two partition boundaries to array
> >
> >
> > 0, 776
> > 778 ,999
> >
> > then run it on in loop on this array, working on first one will again produce two so like this first may be replaced by left but you got three and run it untill it will be consumed
> >
> > hope you get it
> >
> > i belive that verion should be faster than atack based one becouse you dont pass retvalues on stack (if that sorting is long that ammout of retvalues to pass on stack may be counted in megabytes and that makes additional cost so non stack version 'should' be faster (it seems to me but i never checked it, besides its more safe as you may conroll stack overflow (by allocking anough ram for most pessymistic case of at least by adding if-check though this might cost a bit in runtime so maybe its not preffered
> >
> > i eventually can maybe test it toomorrow
> > (at least that kind of threads makes something useful not like hodgin mental devastations or other cheap blablings)
>
> imn some simpel schme this code shoule probably look sorte like this
>
>
> AddPartitionBoundary(0,999)
>
> for()
> {
> if(NoMorePartitions() break;
> partition = TakePartitionToSwpie()
> int div = SwipePartition(partition)
> if(div-partition.left>1) AddPartitionBoundary(partition.left,div-1);
> if(partition.right-div>1) AddPartitionBoundary(div+1,partition.right)
>
> }
>
> (not suere as to this >1 but dont even want to think now)
> something like this maybe i will write it toomorrow
i see maybe your code do this same 9but with no elanation) (introductions and explanations are important as nobody likes guessing - i dont like it)
now im to sleepy, but eventually mau check it tomorow (yawn)
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2019-04-25 23:49 +0300 |
| Message-ID | <20190425234955.d5e41956e47d87a13c5d2be8@gmail.com> |
| In reply to | #143415 |
fir:
> i see maybe your code do this same 9but with no elanation)
> (introductions and explanations are important as nobody
> likes guessing - i dont like it)
>
> now im to sleepy, but eventually mau check it tomorow
> (yawn)
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include "sort.h"
void print( int * a, int n )
{ int i;
for( i = 0; i < n; i++ )
printf("%i ", a[i] );
printf("\n");
}
/* comparison function: */
int comp( void * data, int i, int j )
{ return ( (int*)data )[i] -
( (int*)data )[j];
}
/* comparison function for standard qsort: */
compar(const void * a, void * b)
{ return *((int*)a) - *((int*)b);
}
/* swap function: */
void swap( void * data, int i, int j )
{ int buf;
buf = ( (int[])data )[i];
( (int*)data )[i] = ( (int*)data )[j];
( (int*)data )[j] = buf;
}
#define testlen 2500
void test()
{ int a[testlen], c[testlen];
int i, j;
clock_t st, tot;
tot = 0;
for( i = 0; i < 1000; i++ )
{ for( j = 0; j < testlen; j++ )
{ a[j] = rand() % 5;
c[j] = a[j];
}
st = clock();
//qsort( a, testlen, sizeof(int), &compar );
sort( a, testlen, &comp, &swap, NULL );
tot = tot + clock() - st;
for( j = 0; j < testlen-1; j++ )
{ if( a[j] > a[j+1] )
{ print( c, testlen );
print( a, testlen );
return;
}
}
}
printf("Time: %f\n", (float)tot / CLOCKS_PER_SEC );
}
#define len 2
int main( int argc, char** argv )
{ /*int ta[5] = {7,8,9,10,2};*/
/*int ta[5] = {9,8,8,9,7};*/
test();
return 0;
int ta[len] = {2,1};
int pr;
print( ta, len );
sort( ta, len, &comp, &swap, NULL );
print( ta, len );
}
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-04-25 22:45 +0100 |
| Message-ID | <87ef5pu5cf.fsf@bsb.me.uk> |
| In reply to | #143439 |
Anton Shepelev <anton.txt@gmail.com> writes:
You play fast and loose with types here! One case prevents compilation
and there is also an int overflow bug that really matters.
> #include <stdio.h>
> #include <stdlib.h>
> #include <time.h>
> #include "sort.h"
>
> void print( int * a, int n )
> { int i;
> for( i = 0; i < n; i++ )
> printf("%i ", a[i] );
> printf("\n");
> }
>
> /* comparison function: */
> int comp( void * data, int i, int j )
> { return ( (int*)data )[i] -
> ( (int*)data )[j];
> }
Your header specifies a fourth parameter:
typedef int (*comp_f)( void * data, int i, int j, const void * extra );
Also, did you mean for the "const"s to be the other way round?
typedef int (*comp_f)(const void *data, int i, int j, void * extra);
makes more sense to me. (I'd use size_t for all the offsets but not
doing that is presumably a deliberate decision on your part.)
> /* comparison function for standard qsort: */
> compar(const void * a, void * b)
> { return *((int*)a) - *((int*)b);
> }
qsort wants both pointers to point to const void. Also, this
declaration uses implicit int, but I think you said you write C90. Mind
you, adding the return type is, to my mind, good practise even in C90.
> /* swap function: */
> void swap( void * data, int i, int j )
> { int buf;
> buf = ( (int[])data )[i];
You can't cast to an array type, nor to an incomplete type; int [] is both!
> ( (int*)data )[i] = ( (int*)data )[j];
> ( (int*)data )[j] = buf;
> }
Subtracting ints can lead to unintended behaviour when the result
overflows, even when the actual behaviour is the expected "wrap-around"
one.
I don't want to be overly negative -- you are one of the few people who
posts actual code here. I really liked your sort function.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-04-25 23:00 +0100 |
| Message-ID | <86qwE.122463$da5.88401@fx13.am4> |
| In reply to | #143440 |
On 25/04/2019 22:45, Ben Bacarisse wrote: > Anton Shepelev <anton.txt@gmail.com> writes: > I don't want to be overly negative -- you are one of the few people who > posts actual code here. I really liked your sort function. Did you get the main sort module to work? I couldn't get it to do that, either with my own test code, or the code that was posted an hour ago.
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web