---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00307 Date: 04/16/98
From: EDMAN ROHAN Time: 07:20pm
\/To: TOM TORFS (Read 2 times)
Subj: qbasic
TT> Edman Rohan wrote in a message to All:
ER> If anyone who know about qbasic sent me a mail
TT>
TT> If they do, they should do so either via private
TT> mail or in a (Quick-) Basic echo. We discuss C in
TT> here.
TT>
TT> greetings,
TT> Tom
TT> tomtorfs@village.uunet.be
THANK's
can you tell me he adresse
--- Maximus/2 3.01
* Origin: Juxtaposition BBS. Lasalle, Quebec, Canada (1:167/133)
---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00308 Date: 04/17/98
From: BOB STOUT Time: 02:56am
\/To: BOB GEARHART (Read 2 times)
Subj: Read keyboard 00
On , Bob Gearhart (1:2410/400@fidonet) wrote:
AT> Does somebody know how to read 2 (or more) keys from the keyboard
AT> at the same time ??? Thanks !!
> Follows for the small memory model dos...
...with no PD notice.
--- QM v1.00
* Origin: MicroFirm : Down to the C in chips (1:106/2000.6)
---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00309 Date: 04/13/98
From: JASEN BETTS Time: 07:28pm
\/To: ALL (Read 2 times)
Subj: LICORICE ALLSORTS
Here's some more noise on the subject of sort algorithms.
Quickersort here is my Qsort routine, qsort() is from stdlib (TC2.0), and
rg-qsort() is from snippets (by Raymond Gardner), I compiled it without
"swapints". The other code is as posted by Herman Schonfeld. The timing was
s
done by the u_clock routines from snippets, times are in seconds on my
86/25.
The OS was MS_DOS, the code 16 bit, real mode, small model.
The "items" sorted here are strings containing random 3-digit hex numbers
Interestingly R.G.'s code faster than anything except when sorting sorted
lists. (maybe qsort() here is large model code)
Testing Sort algorithms
10 items random sorted reversed
QuickerSort 0.000372 0.000313 0.000332
rg-qsort() 0.000200 0.000145 0.000163
qsort() 0.000292 0.000286 0.000302
SHELLsort 0.000307 0.000181 0.000278
BUBBLEsort 0.000409 0.000255 0.000591
F-BUBBLEsort 0.000372 0.000119 0.000597
INSERTIONsort 0.000284 0.000176 0.000414
for 10 items the Quick algorithms are about the same speed as the Slow ones
100 items random sorted reversed
QuickerSort 0.005195 0.003622 0.008910 **
rg-qsort() 0.002913 0.001822 0.002015
qsort() 0.004046 0.003183 0.008735
SHELLsort 0.007369 0.002067 0.006106
BUBBLEsort 0.040063 0.019139 0.062629
F-BUBBLEsort 0.039919 0.000463 0.062649
INSERTIONsort 0.016411 0.001084 0.032993
with 100 items Qsort is significantly faster.
There's a bug in my QuickerSort code which shows up with delays on reversed
lists
1000 items random sorted reversed
QuickerSort 0.077360 0.045845 0.258279
rg-qsort() 0.044622 0.027386 0.032527
qsort() 0.055817 0.042685 0.047450
SHELLsort 0.126076 0.031925 0.086139
BUBBLEsort 4.285668 2.000795 6.384675
F-BUBBLEsort 4.259138 0.004033 6.384581
INSERTIONsort 1.710788 0.010202 3.286429
Qsort is now 100 times faster
5000 items random sorted reversed
QuickerSort 0.486165 0.297714 7.398698 (oops)
rg-qsort() 0.271696 0.204589 0.222277
qsort() 0.324517 0.266680 0.273787
SHELLsort 1.014061 0.233066 0.556002
BUBBLEsort 107.265709 52.786568 161.341303 (YAWN!)
F-BUBBLEsort 106.853152 0.020990 161.317909 ...
INSERTIONsort 41.932821 0.052172 83.745034 (10 minutes later)
... and the winner is rg_qsort by a small fraction over the library function.
Bubblesort, isertion etc: Don't do this at home -ah- work :)
My QuickerSort is beginning to look sick too.
SHELLsort may be faster with a more efficient swap routine.
F-Bubble and insertion are the fastest on sorted lists, but that's about all
they have going for them.
All of these algorithms will be slower when sorting more complex structures
like arrays of pointers to strings or structs etc.
Well, I learned that even with tiny arrays Qsort has a speed advantage, and
with it provided as a library function, and in snippets there's not much
excuse for not using it.
--- EzyQwk V1.20 01fa018d
* Origin: CSS Brisbane, Qld, Australia. (61-7-3367-3890) (3:640/350)
---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00310 Date: 04/14/98
From: HERMAN SCHONFELD Time: 02:35pm
\/To: DARIN MCBRIDE (Read 2 times)
Subj: Event Handler
HS> Most compilers accept non-standard code. And most
HS> people understand non-standard code aswell.
DM>Are you sure about either, or is it just YOUR compiler(s)? I seem to
DM>recall you going on about some non-standard code (cprintf?) that happens
DM>to work on YOUR compilers, but not really _ALL_ current compilers.
How many other compilers need cprintf? There's no use whining if someone is
too stupid to realize that cprintf() is only useful within DOS. Hence, all
DOS compilers have it (the ones that I know of anyway, and that list is big).
If a DOS compilers doesn't have it, then it would most likely contain an
equivalent. Another error in your previous asseration is your assumption that
cprintf() is in the standard. It is not.
HS> why bother to do something like
HS> SomeType *mytime = (SomeType *)malloc(sizeof(SomeType))
HS> when,
HS> SomeType *mytype = malloc(.... etc
HS> compiles. Even though ANSI-C++ forbids void *
DM>We're not talking about C++, are we? I thought this was the C echo.
Same concept applies to C. You did realize that, didn't you?
HS> conversion it still works, doesn't it? I could go on
HS> and on about it but I assume you get the idea.
DM>Yes, I get the idea that you have no clue about what standards mean.
Just as I suspected. Your brain failed to synapse such infantile logic.
... Drive not ready: Abort, Retry, Fail, Wait?
--- Ezycom V1.48g0 01fd016b
* Origin: Fox's Lair BBS Bris Aus +61-7-38033908 V34+ Node 2 (3:640/238)
---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00311 Date: 04/12/98
From: BILL BIRRELL Time: 07:15pm
\/To: GEORGE WHITE (Read 2 times)
Subj: atoi(const char *s)
> Careful, some of my original code is in the loft on 80
> col punched cards
> :-).
Punched paper tape took up less room. :-) KSR?? was a tty with keyboard
and a PTR and punch fitted, so it was a fair way to reload programs quickly.
Nuts to the Ecology! There was no shortage of paper of rain forest in those
days. :-)
bb.
---
* Origin: Meerkats Anonymous (2:2504/200)
---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00312 Date: 04/12/98
From: BILL BIRRELL Time: 07:25pm
\/To: CAREY BLOODWORTH (Read 2 times)
Subj: QSORT-ING A STRUCT
Hi Carey,
> Actually, most public libraries (at least the past 3
> places I've lived)
> don't carry stuff like that. Often, their up to date
> computer stuff is
> limited to a subscription to PC-Week, with the books
> themselves talking
> about Basic, Logo, the Apple 2, VisiCalc, etc.
That may be so. I'm not far from Cambridge, so we get a lot of students,
so maybe our libraries are better stocked.
It makes no difference to the main point. Sorting is a matter of
algorithms, and algorithms can be converted to any half way decent
programming language, so there is no intrinsic connection between C and the
current rage, so however interesting, it is not particularly on topic for
this echo. I keep trying to drop out. :-)
Best wishes,
Bill.
---
* Origin: Meerkats Anonymous (2:2504/200)
---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00313 Date: 04/12/98
From: BILL BIRRELL Time: 07:28pm
\/To: SEAN RIMA (Read 2 times)
Subj: AKA Sorting
Hi Sean,
> I think the old gray cells are not functioning too
> well these days but I do get there in time. With all
> the help I got here, there are a lot of happy people
> in R50 :) I stopped programming for a number of years
> and then jumped back in.
Nice to have you back in harness.
> The converting was no major problem as the file I was
> reading stores the zones, nets etc as Long anyway, but
> it was too easy that was the problem. Looked for a
> complicated solution to a simple question.
Glad it's sorted. :-) (awful pun intentional).
Bill.
---
* Origin: Meerkats Anonymous (2:2504/200)
---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00314 Date: 03/25/98
From: DAVID BURNS Time: 01:00am
\/To: JONATHAN DE BOYNE POLLARD (Read 2 times)
Subj: RE:How to quote the C language in Englis01:00:3003/25/98
Hello Jonathan, I wish to discuss with you the merits of "RE:How to quote the
C language in English"
JdBP> When using foreign words or phrases within an English sentence, italics
JdBP> or some other change of font are recommended. Unfortunately, that is
JdBP> not (yet) possible in Fidonet echomail. So the best that we can do I
JdBP> think is to use quotation marks, as in
Well, a good number of fidonet programs will display _this_ //this// and
*this* as underlined italicisised and bold already, so it can be done.
Dave.
|\ |) Internet: burns@rosscontrols.com
|/avid |)urns FidoNet: 2:257/145.6
--- FIPS/32 v0.98 W95/NT [M]
* Origin: It All Ended In Fire... (2:257/145.6)
---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00315 Date: 04/12/98
From: GEORGE WHITE Time: 11:26am
\/To: CAREY BLOODWORTH (Read 2 times)
Subj: Bubble And Squeak Sortin
Hi Carey,
You wrote to David Noon:
CB>DN>Hence, my consistent statements about Insertion sort being typically
twic
CB>DN>as fast as Bubble sort. Since the exchanges are the CPU hogs and,
etter
CB>DN>still, Insertion sort uses moves instead of exchanges,
CB>DN>the ratio is actually
CB>DN>a conservative one.
CB>I don't want to get into what sort routine is the best for small arrays
CB>(or what 'small' means or on what particular data, compiler, language,
CB>implementation, etc.), but I do think it should be pointed out that
CB>comparisons and exchanges aren't really the whole story. (I should also
CB>point out that with most real 'bubble sorts', there will only be 'n'
CB>exchanges. Most implementations will find the highest/lowest and then
CB>exchange in the outer loop, rather than in the inner on every successful
CB>comparisons. [Well, the 'highest' will be set, but that's very
CB>different from exchanging, esp. when the data is large structures.])
I'm glad you said 'bubble sort', because as soon as you change to the
method you describe it is no longer a "bubble sort" but a "selection
sort", and indeed selection sorts are generally quicker than Bubble
sorts. The disadvantage is that a correctly written selection sort will
always make 1/2 * (N**2 - N) comparisons, there is no way round that
without changing to another algorithm.
CB>On small data sets (both quantity and size), the loop overhead (setup,
CB>iter, end, etc.) can have a significant impact. Also, the quality of
CB>the code, the size of the items to compare/swap, the time it takes to
CB>compare, etc. all play a major roll in small data sets. When the cost
CB>of exchanging is much larger than doing the comparison (like with a
CB>struct, etc.) it can often be worth doing a few more comparisons to
CB>reduce the number of exchanges you have to do.
Seconded... (or thirded if David gets here first!)
I agree with the sentiments of the rest of your posting. Indeed my
interest is in sorting a fairly large data set (5000 or 10000 items
where the size of an item is 2k), and looking at ways of presenting the
data to the customer in sequences sorted on different fields. This _has_
to be done by sorting pointers to the data as for system performance
reasons (this is "real time" - as in quick response) magnetic card
control system where the index into the database is stored on the
magnetic card so that I can get to the record to load for
checking/update without any intermediate look up stages.
George
* SLMR 2.1a * Wastebasket: Something to throw things near.
--- Maximus/2 3.01
* Origin: DoNoR/2,Woking UK (44-1483-717905) (2:440/4)
---------------
FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F5G00316 Date: 04/13/98
From: DAVID NOON Time: 05:38pm
\/To: SIMON AVERY (Read 2 times)
Subj: Curiouser And Curiouser.
In a message dated 04-11-98, Simon Avery said to All about Curioser And
Curioser...
Hi Simon,
SA>Simple function to parse a text config file thus:
SA>(Config file entry:)
SA>-!-
SA>Security 100
SA>-!-
SA>function;
SA>{
SA>char dummy[101];
SA>FILE *cfg; (Opened)
SA>char *ptr,*ptr2
^^^ ^^^^
Where do these guys point?
SA>int writelevel;
SA>while(fgets(dummy,100,cfg))
SA> {
SA> // other stuff
SA> rmtrail(dummy); // See SNIPPETS.
SA> sscanf(dummy,"%s %s",ptr,ptr2);
^^^ ^^^^
They still don't point anywhere "good", AFAICS. They most likely each have a
value of zero, which will be taken as an offset into the data segment.
SA> if (!strcmpi(ptr,"Security"))
SA> {
SA> writelevel=atoi(ptr2);
SA> printf("Ping! [%s][%d]\n",ptr2,writelevel);
SA> }
SA> }
SA>printf("Ping! [%s][%d]\n",ptr2,writelevel);
SA>}
SA>At the first "Ping!" writelevel is true;= 10.
SA>At the second, it returns 26723
SA>This ONLY occurs if "writelevel" is declared globally.
Like, if it is close to zero offset into the data segment.
SA> If I declare it
SA>local to the function then it works properly. It does the same with the
SA>other three atoi() ints I read in, and yes, I have checked that I've not
SA>re-used "writelevel" elsewhere. It shouldn't change!
SA>Why is this?
Memory corruption due to misuse of sscanf(), perhaps?
SA>(TCC3 16-bit dos under Win95. Small mem model, trivial program in
SA>early stages and no memory holes that I can see.)
In whose memory? ... :-)
You could avoid these problems if you would either:
Use the parser I sent you, in this echo, about 2 years ago;
Use flat memory model code and get GPF's during testing for this stuff.
[Also, note the change of subject spelling!]
Regards
Dave
___
* MR/2 2.25 #353 * OS/2: Windows with bullet-proof glass.
--- Maximus/2 3.01
* Origin: DoNoR/2,Woking UK (44-1483-717905) (2:440/4)