Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #55164 > unrolled thread
| Started by | lehs <skydda.barnen@gmail.com> |
|---|---|
| First post | 2017-02-27 01:51 -0800 |
| Last post | 2017-02-27 21:24 +0100 |
| Articles | 20 on this page of 121 — 16 participants |
Back to article view | Back to comp.lang.forth
Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 01:51 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 02:35 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 02:46 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-27 17:38 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 14:12 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 04:42 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 08:58 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 14:15 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 11:51 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 15:17 -0500
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 09:02 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-28 19:15 -0500
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-01 02:23 +0100
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-28 20:57 -0500
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-01 13:24 +0100
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-01 14:23 -0500
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-01 08:50 +0000
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-01 10:04 -0600
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-01 14:51 -0500
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-03-01 13:00 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-02 15:34 +0000
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-01 18:09 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-01 14:55 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-01 21:28 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-01 22:23 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-02 00:21 -0800
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-03-02 01:01 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-02 01:30 -0800
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-03-02 01:46 -0800
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-03-02 02:41 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-02 11:01 +0000
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-03-01 13:48 -0800
Re: Is GForth KEY really ANS Forth standard? antispam@math.uni.wroc.pl - 2017-03-04 04:02 +0000
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-04 12:29 +0000
Re: Is GForth KEY really ANS Forth standard? Paul Rubin <no.email@nospam.invalid> - 2017-02-28 03:24 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 04:14 -0800
Re: Is GForth KEY really ANS Forth standard? Coos Haak <htrofhc@gmail.com> - 2017-02-27 21:50 +0100
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 13:48 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 17:41 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 15:07 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-27 19:03 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 23:10 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-02-28 03:29 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 01:28 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 09:58 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 02:37 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 12:46 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 05:01 -0800
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-28 12:46 +0100
Re: Is GForth KEY really ANS Forth standard? Mikael Nordman <oh2aun@gmail.com> - 2017-02-28 03:52 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 04:10 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 05:48 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-28 10:07 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-28 02:42 -0800
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-02-28 02:44 -0800
Re: Is GForth KEY really ANS Forth standard? Coos Haak <htrofhc@gmail.com> - 2017-02-28 12:13 +0100
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-02-28 05:10 -0800
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-02-28 12:12 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 13:51 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-27 15:38 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-02-27 10:13 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-02-27 11:15 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-03 12:04 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-03 17:30 -0500
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-03 23:13 +0000
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-03 18:02 -0600
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-04 01:12 +0000
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-03 19:12 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-03 19:23 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-05 18:45 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-05 18:54 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-05 20:47 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 09:20 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 05:04 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 14:07 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 06:36 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 15:04 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-07 07:38 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-07 07:56 -0800
Re: Is GForth KEY really ANS Forth standard? Mark Wills <markwills1970@gmail.com> - 2017-03-07 08:07 -0800
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-07 08:37 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 15:41 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-09 01:13 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-09 13:03 +0000
Re: Is GForth KEY really ANS Forth standard? julian.fondren@endurance.com - 2017-03-07 08:36 -0800
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-07 19:02 +0100
Re: Is GForth KEY really ANS Forth standard? alex@rivadpm.com - 2017-03-08 06:08 -0800
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-09 00:46 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-09 12:39 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-09 12:42 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-09 23:13 -0800
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 14:34 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 15:33 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 15:45 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-08 22:48 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 09:28 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 05:22 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 14:25 +0000
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-06 06:46 -0800
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-06 15:43 +0000
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-06 09:55 -0800
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-06 11:04 -0600
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-07 07:44 -0800
Re: Is GForth KEY really ANS Forth standard? Cecil Bayona <cbayona@cbayona.com> - 2017-03-07 10:50 -0600
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-03-08 11:30 +0000
Re: Is GForth KEY really ANS Forth standard? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-03-08 13:37 +0000
Re: Is GForth KEY really ANS Forth standard? Alex <alex@rivadpm.com> - 2017-03-08 14:14 +0000
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-03-08 15:16 +0100
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-03-08 16:14 +0000
Re: Is GForth KEY really ANS Forth standard? john <anon@example.com> - 2017-03-08 14:49 +0000
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-09 10:57 -0500
Re: Is GForth KEY really ANS Forth standard? hughaguilar96@gmail.com - 2017-03-05 18:22 -0800
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-04 10:48 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-04 21:00 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-05 02:24 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-05 16:44 -0500
Re: Is GForth KEY really ANS Forth standard? Julian Fondren <julian.fondren@gmail.com> - 2017-03-04 20:02 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-04 23:34 -0500
Re: Is GForth KEY really ANS Forth standard? lehs <skydda.barnen@gmail.com> - 2017-03-05 02:38 -0800
Re: Is GForth KEY really ANS Forth standard? rickman <gnuarm@gmail.com> - 2017-03-05 16:55 -0500
Re: Is GForth KEY really ANS Forth standard? albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-02-27 21:24 +0100
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-03-07 08:37 -0800 |
| Message-ID | <6687830c-63e4-4f49-87a4-18ab6ec217e8@googlegroups.com> |
| In reply to | #55502 |
On Tuesday, March 7, 2017 at 10:07:23 AM UTC-6, Mark Wills wrote: > Is that right? I only briefly looked at his code, but it looks like it's > built on the concept of a deferred word called PRECEDES that takes two > addresses and returns a Boolean. That means that the *implementation* of > PRECEDES is free to do anything with those addresses. ... > Of course, EXCHANGE would have to be changed > according to the datum being sorted. With only PRECEDES deferred you can sort any data structure by first making an array of addresses into it and then, after sorting the indirect array, rebuilding the original data structure by it. In the case of a linked list f.e. you can loop over the indirect array and rewrite ->next links directly. Rather than addresses you could also sort a list of indexes, again using PRECEDES to interrogate the original structure based on the index. This would be more useful if you wanted to sort a bunch of structures the same way, based on how only one of them sorts out. In both cases the indirect array is transient, can be built at HERE or in ALLOCATEd memory and then thrown away.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-08 15:41 +0000 |
| Message-ID | <o9p8hp$hd$1@dont-email.me> |
| In reply to | #55503 |
On 3/7/2017 16:37, Julian Fondren wrote: > On Tuesday, March 7, 2017 at 10:07:23 AM UTC-6, Mark Wills wrote: >> Is that right? I only briefly looked at his code, but it looks like it's >> built on the concept of a deferred word called PRECEDES that takes two >> addresses and returns a Boolean. That means that the *implementation* of >> PRECEDES is free to do anything with those addresses. > ... >> Of course, EXCHANGE would have to be changed >> according to the datum being sorted. > > With only PRECEDES deferred you can sort any data structure by first > making an array of addresses into it and then, after sorting the > indirect array, rebuilding the original data structure by it. In the > case of a linked list f.e. you can loop over the indirect array and > rewrite ->next links directly. > > Rather than addresses you could also sort a list of indexes, again > using PRECEDES to interrogate the original structure based on the > index. This would be more useful if you wanted to sort a bunch of > structures the same way, based on how only one of them sorts out. > > In both cases the indirect array is transient, can be built at HERE or > in ALLOCATEd memory and then thrown away. > Hopefully Hugh will read this, and he will have a lightbulb moment. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-09 01:13 -0800 |
| Message-ID | <54c2bf4a-9894-4d5c-ace1-bca0799ad8f4@googlegroups.com> |
| In reply to | #55553 |
On Wednesday, March 8, 2017 at 8:41:22 AM UTC-7, Alex wrote: > On 3/7/2017 16:37, Julian Fondren wrote: > > On Tuesday, March 7, 2017 at 10:07:23 AM UTC-6, Mark Wills wrote: > >> Is that right? I only briefly looked at his code, but it looks like it's > >> built on the concept of a deferred word called PRECEDES that takes two > >> addresses and returns a Boolean. That means that the *implementation* of > >> PRECEDES is free to do anything with those addresses. > > ... > >> Of course, EXCHANGE would have to be changed > >> according to the datum being sorted. > > > > With only PRECEDES deferred you can sort any data structure by first > > making an array of addresses into it and then, after sorting the > > indirect array, rebuilding the original data structure by it. In the > > case of a linked list f.e. you can loop over the indirect array and > > rewrite ->next links directly. > > > > Rather than addresses you could also sort a list of indexes, again > > using PRECEDES to interrogate the original structure based on the > > index. This would be more useful if you wanted to sort a bunch of > > structures the same way, based on how only one of them sorts out. > > > > In both cases the indirect array is transient, can be built at HERE or > > in ALLOCATEd memory and then thrown away. > > > > Hopefully Hugh will read this, and he will have a lightbulb moment. > > -- > Alex This is very basic programming that I would expect any high-school student to be familiar with (I was familiar with this in high-school, which was over 30 years ago) --- you are making complete fools of yourselves by publicly teaching me this stuff --- maybe later you can find a master mechanic with 30 years experience and teach him how to replace the brake pads in a car... ANS-Forth is a cult --- you make complete fools out of yourselves every day --- your "leading expert" Elizabeth Rather says this about herself: ------------------------------------------------------------------------------------ Elizabeth Rather is the co-founder of FORTH, Inc. and is a leading expert in the Forth programming language. Elizabeth was a colleague of Chuck Moore when he worked at NRAO in the early 1970s. During his development of Forth, she became the second ever Forth programmer. Since then, she has become a leading expert in the language and one of its main proponents. Elizabeth was the chair of the ANSI Technical Committee that produced the ANSI Standard for Forth (1994). She is an author of several books on Forth and gave many training seminars on its usage. ------------------------------------------------------------------------------------ Note that there is nothing here to indicate that she has ever written a Forth program --- this is because she has not done so --- her description of herself is a head-on collision of ignorance and arrogance. Note also that Andrew Haley worked for Forth Inc. and taught the same "training seminar" mentioned above when Elizabeth Rather wasn't available to teach it --- this is his only background in Forth --- this is why Elizabeth Rather appointed him to the Forth-200x committee.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-09 13:03 +0000 |
| Message-ID | <o9rjmc$646$1@dont-email.me> |
| In reply to | #55569 |
On 3/9/2017 09:13, hughaguilar96@gmail.com wrote: > > This is very basic programming that I would expect any high-school > student to be familiar with (I was familiar with this in high-school, > which was over 30 years ago) --- you are making complete fools of > yourselves by publicly teaching me this stuff --- maybe later you can > find a master mechanic with 30 years experience and teach him how to > replace the brake pads in a car... This is where the conversation started; https://groups.google.com/forum/message/raw?msg=comp.lang.forth/gGkYxHDqWzY/Ib-iPcNM5vYJ <quote> I think that it is is important that, when code is posted on c.l.f., it should meet basic requirements of quality. When code is posted for a SORT function that only works with integers, that just induces WJ to say that Forth is a "stone-age toy" only useful for programming toilet-flushers, etc., etc.. So long as the c.l.f. crowd continues to live in the stone-age, WJ will continue to say that all Forthers are living in the stone-age. </quote> High school indeed. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | julian.fondren@endurance.com |
|---|---|
| Date | 2017-03-07 08:36 -0800 |
| Message-ID | <e1660b74-c0bf-4bac-9b0d-c3b5d92bd0dc@googlegroups.com> |
| In reply to | #55502 |
On Tuesday, March 7, 2017 at 10:07:23 AM UTC-6, Mark Wills wrote: > Is that right? I only briefly looked at his code, but it looks like it's > built on the concept of a deferred word called PRECEDES that takes two > addresses and returns a Boolean. That means that the *implementation* of > PRECEDES is free to do anything with those addresses. ... > Of course, EXCHANGE would have to be changed > according to the datum being sorted. With only PRECEDES deferred you can sort any data structure by first making an array of addresses into it and then, after sorting the indirect array, rebuilding the original data structure by it. In the case of a linked list f.e. you can loop over the indirect array and rewrite ->next links directly. Rather than addresses you could also sort a list of indexes, again using PRECEDES to interrogate the original structure based on the index. This would be more useful if you wanted to sort a bunch of structures the same way, based on how only one of them sorts out. In both cases the indirect array is transient, can be built at HERE or in ALLOCATEd memory and then thrown away.
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-03-07 19:02 +0100 |
| Message-ID | <o9msjh$odv$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #55504 |
In article <e1660b74-c0bf-4bac-9b0d-c3b5d92bd0dc@googlegroups.com>, <julian.fondren@endurance.com> wrote: >On Tuesday, March 7, 2017 at 10:07:23 AM UTC-6, Mark Wills wrote: >> Is that right? I only briefly looked at his code, but it looks like it's >> built on the concept of a deferred word called PRECEDES that takes two >> addresses and returns a Boolean. That means that the *implementation* of >> PRECEDES is free to do anything with those addresses. >... >> Of course, EXCHANGE would have to be changed >> according to the datum being sorted. > >With only PRECEDES deferred you can sort any data structure by first >making an array of addresses into it and then, after sorting the >indirect array, rebuilding the original data structure by it. In the >case of a linked list f.e. you can loop over the indirect array and >rewrite ->next links directly. > >Rather than addresses you could also sort a list of indexes, again >using PRECEDES to interrogate the original structure based on the >index. This would be more useful if you wanted to sort a bunch of >structures the same way, based on how only one of them sorts out. > >In both cases the indirect array is transient, can be built at HERE or >in ALLOCATEd memory and then thrown away. My qsort has the property that it can actually swap structures. If you want to reorder a database for improved access, it is no use to have an array of indices. There is a subtlety involved with the pivot. Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | alex@rivadpm.com |
|---|---|
| Date | 2017-03-08 06:08 -0800 |
| Message-ID | <42d36d15-eef1-42f8-98c2-ecc1e2ce8991@googlegroups.com> |
| In reply to | #55502 |
On Tuesday, March 7, 2017 at 4:07:23 PM UTC, Mark Wills wrote: > On Tuesday, 7 March 2017 15:56:36 UTC, hughag...@gmail.com wrote: > > On Monday, March 6, 2017 at 8:04:35 AM UTC-7, Alex wrote: > > > On 3/6/2017 14:36, hughaguilar96@gmail.com wrote: > > > > Anyway, I've never seen Wil Baden's much-touted SORT function. I > > > > tried to download it but the webpage was kaput. > > > > > > http://www.wilbaden.com/neil_bawd/qsort.txt is still there, and still > > > confusing the heck out of you. How can it sort anything other than an > > > array of cells? Hmm? How? > > > > Okay, I found it. I glanced over Wil Baden's code and saw that it was very low-quality: > > 1.) He is limited to working with arrays of cells, but he doesn't support arrays of strcuts. > > Is that right? I only briefly looked at his code, but it looks like it's > built on the concept of a deferred word called PRECEDES that takes two > addresses and returns a Boolean. Actually, it returns a higher/equal/lower by using +ve/0/-ve as a return value; which is why - (minus) suffices for a signed integer compare. > That means that the *implementation* of > PRECEDES is free to do anything with those addresses. They might be the > addresses of two cells in an array, but they might be the addresses of two > structures that PRECEDES (and associated helper words) would examine and > compare. Heck, addr_1 could the be address of a structure on one machine, > and addr_2 the address of a structure on another machine that is interrogated > over a network connection. The sort algorithm doesn't care. It's only interested > in the *output* of PRECEDES. Bingo. That's what Hugh doesn't get, and he never has. > Of course, EXCHANGE would have to be changed > according to the datum being sorted. I'd argue it should also be a deferred > word to make that clearer. It's not in Wil's code. No, since the only thing being exchanged is a pair of pointers. > > Like I say I only really glanced at the code so I could be making a total > idiot of myself here. It wouldn't be the first time ;-) You've got the principles OK. Hugh on the other hand is a lost cause.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-09 00:46 -0800 |
| Message-ID | <af2c298d-1d96-47d8-8a96-d9a195731bfb@googlegroups.com> |
| In reply to | #55502 |
On Tuesday, March 7, 2017 at 9:07:23 AM UTC-7, Mark Wills wrote:
> On Tuesday, 7 March 2017 15:56:36 UTC, hughag...@gmail.com wrote:
> > On Monday, March 6, 2017 at 8:04:35 AM UTC-7, Alex wrote:
> > > On 3/6/2017 14:36, hughaguilar96@gmail.com wrote:
> > > > Anyway, I've never seen Wil Baden's much-touted SORT function. I
> > > > tried to download it but the webpage was kaput.
> > >
> > > http://www.wilbaden.com/neil_bawd/qsort.txt is still there, and still
> > > confusing the heck out of you. How can it sort anything other than an
> > > array of cells? Hmm? How?
> >
> > Okay, I found it. I glanced over Wil Baden's code and saw that it was very low-quality:
> > 1.) He is limited to working with arrays of cells, but he doesn't support arrays of structs.
>
> Is that right? I only briefly looked at his code, but it looks like it's
> built on the concept of a deferred word called PRECEDES that takes two
> addresses and returns a Boolean. That means that the *implementation* of
> PRECEDES is free to do anything with those addresses. They might be the
> addresses of two cells in an array, but they might be the addresses of two
> structures that PRECEDES (and associated helper words) would examine and
> compare. Heck, addr_1 could the be address of a structure on one machine,
> and addr_2 the address of a structure on another machine that is interrogated
> over a network connection. The sort algorithm doesn't care. It's only interested
> in the *output* of PRECEDES. Of course, EXCHANGE would have to be changed
> according to the datum being sorted. I'd argue it should also be a deferred
> word to make that clearer. It's not in Wil's code.
>
> Like I say I only really glanced at the code so I could be making a total
> idiot of myself here. It wouldn't be the first time ;-)
Well, he only supports arrays of cells --- those cells may contain pointers to structs, as you said --- I never said that the cells had to contain integers.
Changing EXCHANGE as you said above won't help --- Wil Baden's SORT is hard-coded to only support arrays of cells --- EXCHANGE isn't the only thing that needs to be changed. His SORT could be changed to be hard-coded to only support arrays of floats --- and then changed again to be hard-coded to only support arrays of doubles --- this is cut-and-paste-and-tweak programming, which Elizabeth Rather and her followers believe is the only way to have "general-purpose code."
My SORT supports arrays of any size elements --- it can support arrays of cells (use W as the element size) or arrays of structs (use the struct size as the element size).
My SORT is general-purpose because it can support any size array element --- the concept of general-purpose code is hated and feared by Elizabeth Rather and her sycophants --- this failure to support or even understand general-purpose code is the reason why ANS-Forth was a flop.
Sometimes the user may want an array of pointers (as you described), but sometimes the user may want an array of structs. It is inefficient to use an array of pointers when the structs are small. For example, you might have an array of floats (a struct with one field, which is a float). You might also have a struct like this:
0
w field .x
w field .y
constant pt
My array definer supports arrays of structs, and my SORT does too. I say that the ANS-Forth cult are making fools of themselves by attacking this because this is a feature --- what possible benefit could there be in limiting the arrays to cells? --- general-purpose code should support any size of datum.
Here is an array definer written by Elizabeth Rather (this is the only example of code that she has posted on clf that wasn't copied directly out of the "Starting Forth" book):
On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote:
> Here's [an array definer] presented in my Forth Application Techniques that I think is
> far more useful than the FSL version:
>
> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT
> DOES> ( n -- a) SWAP OVER @ OVER < OVER
> 1 < OR ABORT" Out of Range" CELLS + ;
Notice that it only supports arrays of cells (another problem is that it starts the index on 1 like in COBOL rather than on 0 like in modern languages).
Also, her employee Andrew Haley wrote an array definer for Iliff arrays that used CREATE DOES> and was also limited to arrays of cells. I upgraded this (my ARY array definer) for the novice-package to support arrays of any size element.
Elizabeth Rather and her cult members are obsessed with limiting what the Forth programmer is allowed to do. Why did Wil Baden write his code to only support arrays of cells? We can't ask him because he is dead --- most likely, it was just an expedient hack because he had an application program that needed an array of cells --- he never expected that the ANS-Forth cult members would be holding this up as standard Forth practice in the year 2017.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-09 12:39 +0000 |
| Message-ID | <o9ri93$13i$1@dont-email.me> |
| In reply to | #55568 |
On 3/9/2017 08:46, hughaguilar96@gmail.com wrote: > On Tuesday, March 7, 2017 at 9:07:23 AM UTC-7, Mark Wills wrote: >> On Tuesday, 7 March 2017 15:56:36 UTC, hughag...@gmail.com wrote: >>> On Monday, March 6, 2017 at 8:04:35 AM UTC-7, Alex wrote: >>>> On 3/6/2017 14:36, hughaguilar96@gmail.com wrote: >>>>> Anyway, I've never seen Wil Baden's much-touted SORT function. I >>>>> tried to download it but the webpage was kaput. >>>> >>>> http://www.wilbaden.com/neil_bawd/qsort.txt is still there, and still >>>> confusing the heck out of you. How can it sort anything other than an >>>> array of cells? Hmm? How? >>> >>> Okay, I found it. I glanced over Wil Baden's code and saw that it was very low-quality: >>> 1.) He is limited to working with arrays of cells, but he doesn't support arrays of structs. >> >> Is that right? I only briefly looked at his code, but it looks like it's >> built on the concept of a deferred word called PRECEDES that takes two >> addresses and returns a Boolean. That means that the *implementation* of >> PRECEDES is free to do anything with those addresses. They might be the >> addresses of two cells in an array, but they might be the addresses of two >> structures that PRECEDES (and associated helper words) would examine and >> compare. Heck, addr_1 could the be address of a structure on one machine, >> and addr_2 the address of a structure on another machine that is interrogated >> over a network connection. The sort algorithm doesn't care. It's only interested >> in the *output* of PRECEDES. Of course, EXCHANGE would have to be changed >> according to the datum being sorted. I'd argue it should also be a deferred >> word to make that clearer. It's not in Wil's code. >> >> Like I say I only really glanced at the code so I could be making a total >> idiot of myself here. It wouldn't be the first time ;-) > > Well, he only supports arrays of cells --- those cells may contain pointers to structs, as you said --- I never said that the cells had to contain integers. > > Changing EXCHANGE as you said above won't help --- Wil Baden's SORT is hard-coded to only support arrays of cells --- EXCHANGE isn't the only thing that needs to be changed. His SORT could be changed to be hard-coded to only support arrays of floats --- and then changed again to be hard-coded to only support arrays of doubles --- this is cut-and-paste-and-tweak programming, which Elizabeth Rather and her followers believe is the only way to have "general-purpose code." > > My SORT supports arrays of any size elements --- it can support arrays of cells (use W as the element size) or arrays of structs (use the struct size as the element size). > > My SORT is general-purpose because it can support any size array element --- the concept of general-purpose code is hated and feared by Elizabeth Rather and her sycophants --- this failure to support or even understand general-purpose code is the reason why ANS-Forth was a flop. > > Sometimes the user may want an array of pointers (as you described), but sometimes the user may want an array of structs. It is inefficient to use an array of pointers when the structs are small. For example, you might have an array of floats (a struct with one field, which is a float). You might also have a struct like this: > > 0 > w field .x > w field .y > constant pt > > My array definer supports arrays of structs, and my SORT does too. I say that the ANS-Forth cult are making fools of themselves by attacking this because this is a feature --- what possible benefit could there be in limiting the arrays to cells? --- general-purpose code should support any size of datum. > > Here is an array definer written by Elizabeth Rather (this is the only example of code that she has posted on clf that wasn't copied directly out of the "Starting Forth" book): > > On Sunday, August 9, 2015 at 7:30:10 PM UTC-7, Elizabeth D. Rather wrote: >> Here's [an array definer] presented in my Forth Application Techniques that I think is >> far more useful than the FSL version: >> >> : ARRAY ( n -- ) CREATE DUP , CELLS ALLOT >> DOES> ( n -- a) SWAP OVER @ OVER < OVER >> 1 < OR ABORT" Out of Range" CELLS + ; > > Notice that it only supports arrays of cells (another problem is that it starts the index on 1 like in COBOL rather than on 0 like in modern languages). > > Also, her employee Andrew Haley wrote an array definer for Iliff arrays that used CREATE DOES> and was also limited to arrays of cells. I upgraded this (my ARY array definer) for the novice-package to support arrays of any size element. > > Elizabeth Rather and her cult members are obsessed with limiting what the Forth programmer is allowed to do. Why did Wil Baden write his code to only support arrays of cells? We can't ask him because he is dead --- most likely, it was just an expedient hack because he had an application program that needed an array of cells --- he never expected that the ANS-Forth cult members would be holding this up as standard Forth practice in the year 2017. > -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-09 12:42 +0000 |
| Message-ID | <o9rif1$1pq$1@dont-email.me> |
| In reply to | #55568 |
On 3/9/2017 08:46, hughaguilar96@gmail.com wrote: > > Well, he only supports arrays of cells --- those cells may contain > pointers to structs, as you said --- I never said that the cells had > to contain integers. Maybe you forgot. You did. This is where the conversation started; https://groups.google.com/forum/message/raw?msg=comp.lang.forth/gGkYxHDqWzY/Ib-iPcNM5vYJ <quote> I think that it is is important that, when code is posted on c.l.f., it should meet basic requirements of quality. When code is posted for a SORT function that only works with integers, that just induces WJ to say that Forth is a "stone-age toy" only useful for programming toilet-flushers, etc., etc.. So long as the c.l.f. crowd continues to live in the stone-age, WJ will continue to say that all Forthers are living in the stone-age. </quote> Perhaps you're learning, but you're unable to admit it. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-09 23:13 -0800 |
| Message-ID | <868f7aee-7cf9-4722-8e7a-3a722d697903@googlegroups.com> |
| In reply to | #55571 |
On Thursday, March 9, 2017 at 5:42:51 AM UTC-7, Alex wrote: > On 3/9/2017 08:46, hughaguilar96@gmail.com wrote: > > > > > Well, he only supports arrays of cells --- those cells may contain > > pointers to structs, as you said --- I never said that the cells had > > to contain integers. > > Maybe you forgot. You did. This is where the conversation started; > > https://groups.google.com/forum/message/raw?msg=comp.lang.forth/gGkYxHDqWzY/Ib-iPcNM5vYJ > > <quote> > I think that it is is important that, when code is posted on c.l.f., it > should meet basic requirements of quality. When code is posted for a > SORT function that only works with integers, that just induces WJ to say > that Forth is a "stone-age toy" only useful for programming > toilet-flushers, etc., etc.. So long as the c.l.f. crowd continues to > live in the stone-age, WJ will continue to say that all Forthers are > living in the stone-age. > </quote> This is the thread: https://groups.google.com/forum/#!topic/comp.lang.forth/gGkYxHDqWzY%5B1-25%5D The SORT that Hans Bezemer posted only works for integers. This is how he defined PRECEEDS (the comparison function): On Wednesday, June 26, 2013 at 9:11:50 AM UTC-7, The Beez wrote: > : precedes < ; He is expecting the Forth programmer to do cut-and-paste-and-tweak programming --- copy the SORT function and rewrite PRECEEDS for a different data-type. Making PRECEEDS a deferred word, as Wil Baden did, is also bad programming. It is problematic to pass data between functions in a global variable, which is what a DEFER vector is. BTW: I'm amazed to note that this thread goes way back to 2013 --- you have been harping on this subject for almost four years now --- you want everybody to believe that I don't know that it is possible to have an array of pointers and that I have to learn this from you. LOL Get a life! You are making a complete fool out of yourself --- this is like trying to educate auto mechanics on how to replace brake pads in a car (anybody with a modicum of knowledge of cars knows how to do simple jobs like this) --- the fact that you are spending years harping on this simple subject implies that this is the limit of your own knowledge, and has been for quite some time.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-03-08 14:34 +0000 |
| Message-ID | <2017Mar8.153419@mips.complang.tuwien.ac.at> |
| In reply to | #55501 |
hughaguilar96@gmail.com writes:
>2.) His code is recursive, so all of those function calls take unneeded tim=
>e, and duplicating the lo and hi parameters on the data-stack with 2DUP tak=
>es time.
>
>#2 isn't so bad, because on a modern x86 with CALL/RET prediction CALL and =
>RET are pretty fast, but it was very bad in 1999 when he wrote it.
The DEC Alpha 21064a (1993), Intel Pentium Pro (1995), Cyrix 6x86
(1996), and AMD K6 (1997) had return stacks, so by 1999 they were
pretty common.
In my own experiments with quicksort in Forth
<2013Aug15.191549@mips.complang.tuwien.ac.at>, I found that the
single-recursive version had a better branch prediction accuracy than
an iterative version, essentially because the iterative version lost
information about whether an even or odd number of partitions remain
to be processed that the recursive version maintained in the state of
the return stack and the program counter.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-08 15:33 +0000 |
| Message-ID | <o9p83g$ujq$1@dont-email.me> |
| In reply to | #55501 |
On 3/7/2017 15:56, hughaguilar96@gmail.com wrote: > On Monday, March 6, 2017 at 8:04:35 AM UTC-7, Alex wrote: >> On 3/6/2017 14:36, hughaguilar96@gmail.com wrote: >>> Anyway, I've never seen Wil Baden's much-touted SORT function. I >>> tried to download it but the webpage was kaput. >> >> http://www.wilbaden.com/neil_bawd/qsort.txt is still there, and >> still confusing the heck out of you. How can it sort anything other >> than an array of cells? Hmm? How? > > Okay, I found it. I glanced over Wil Baden's code and saw that it was > very low-quality: 1.) He is limited to working with arrays of cells, This is so wrong. You still can't see it, can you? Look at Mark Willis' reply to you; he gets it. > but he doesn't support arrays of strcuts. 2.) His code is recursive, > so all of those function calls take unneeded time, and duplicating > the lo and hi parameters on the data-stack with 2DUP takes time. > > #2 isn't so bad, because on a modern x86 with CALL/RET prediction > CALL and RET are pretty fast, but it was very bad in 1999 when he > wrote it. > > #1 is the big problem. This is a pointless restriction! I am reminded > of how Andrew Haley recently wrote a array definer using Iliff > arrays, but weirdly he had the pointless restriction of only > supporting arrays of cells. I upgraded this to support arrays of > structs; this is my ARY in the novice-package. Groan... > > The ANS-Forth cult always fails to support arrays of structs, but > instead of just learning how to support arrays of structs, they claim > that their failure is a virtue and that supporting arrays of structs > is somehow bad. Weird! And stupid! > That's because you don't understand pointers or sorting. Read Mark's reply and my comments, and then -- write a sort or two using Wil Baden's code. Think about how you might take a singly linked list of strings and sort them WITHOUT MOVING ANY OF THE ENTRIES IN THE LIST OR THE STRINGS OR TURNING THEM INTO AN ARRAY OF STRUCTS. It is possible; in fact, it's trivial once you get your head out of the tarpits that are the big rectangular boxes of "arrays of structs". -- Alex
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-08 15:45 +0000 |
| Message-ID | <o9p8ov$1e6$1@dont-email.me> |
| In reply to | #55552 |
On 3/8/2017 15:33, Alex wrote: > > This is so wrong. You still can't see it, can you? Look at Mark Willis' Sorry Mark. Mark Wills' reply. (Yes, I get annoyed by MacDonald.) -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-08 22:48 -0800 |
| Message-ID | <9f7d4502-52d6-45b5-961f-eaad4ae508ea@googlegroups.com> |
| In reply to | #55552 |
On Wednesday, March 8, 2017 at 8:33:45 AM UTC-7, Alex wrote:
> On 3/7/2017 15:56, hughaguilar96@gmail.com wrote:
> > On Monday, March 6, 2017 at 8:04:35 AM UTC-7, Alex wrote:
> >> On 3/6/2017 14:36, hughaguilar96@gmail.com wrote:
> >>> Anyway, I've never seen Wil Baden's much-touted SORT function. I
> >>> tried to download it but the webpage was kaput.
> >>
> >> http://www.wilbaden.com/neil_bawd/qsort.txt is still there, and
> >> still confusing the heck out of you. How can it sort anything other
> >> than an array of cells? Hmm? How?
> >
> > Okay, I found it. I glanced over Wil Baden's code and saw that it was
> > very low-quality: 1.) He is limited to working with arrays of cells,
>
> This is so wrong. You still can't see it, can you? Look at Mark Willis'
> reply to you; he gets it.
>
> > but he doesn't support arrays of strcuts. 2.) His code is recursive,
> > so all of those function calls take unneeded time, and duplicating
> > the lo and hi parameters on the data-stack with 2DUP takes time.
> >
> > #2 isn't so bad, because on a modern x86 with CALL/RET prediction
> > CALL and RET are pretty fast, but it was very bad in 1999 when he
> > wrote it.
> >
> > #1 is the big problem. This is a pointless restriction! I am reminded
> > of how Andrew Haley recently wrote a array definer using Iliff
> > arrays, but weirdly he had the pointless restriction of only
> > supporting arrays of cells. I upgraded this to support arrays of
> > structs; this is my ARY in the novice-package.
>
> Groan...
>
> >
> > The ANS-Forth cult always fails to support arrays of structs, but
> > instead of just learning how to support arrays of structs, they claim
> > that their failure is a virtue and that supporting arrays of structs
> > is somehow bad. Weird! And stupid!
> >
>
> That's because you don't understand pointers or sorting. Read Mark's
> reply and my comments, and then -- write a sort or two using Wil Baden's
> code. Think about how you might take a singly linked list of strings and
> sort them WITHOUT MOVING ANY OF THE ENTRIES IN THE LIST OR THE STRINGS
> OR TURNING THEM INTO AN ARRAY OF STRUCTS.
>
> It is possible; in fact, it's trivial once you get your head out of the
> tarpits that are the big rectangular boxes of "arrays of structs".
>
> --
> Alex
By writing ANS-Forth code, I'm killing ANS-Forth --- all of Elizabeth Rather's sycophants attack my code and make complete fools of themselves --- I spend one day writing some code, and Elizabeth Rather's sycophants spend years making fools of themselves over it!
As I said, I have SORT available for sorting arrays. Rather than write MergeSort for linked lists, I converted the list into an array for SORT then converted the array back into a list. That was inefficient and awkward, so I now wrote SORT-LIST to use MergeSort internally which is much better.
Anyway, here is the the inefficient and awkward version that uses SORT internally:
: list>array ( head -- array elements ) \ the array is of pointers to the nodes \ it is allocated on the heap
dup length >r
r@ cells alloc tuck >r \ -- array head \r: -- length array
each[ over ! cell+ ]each drop
r> r> ;
: array>list ( array elements -- head ) \ array is assumed to be on the heap \ it is deallocated
1- cells over + \ -- array last
nil over @ .fore ! \ set last node's .FORE to NIL
over ?do \ -- array \ set the other nodes' .FORE to the next node
I cell+ @ I @ .fore ! w +loop
dup @ \ -- array head
swap dealloc ;
Here is an example of doing this for SEQ lists:
: <big-sort-seq> ( adrX adrY -- X>Y? )
>r @ .line @ count
r> @ .line @ count compare A>B = ;
: big-sort-seq ( head -- new-head ) \ more efficient for large arrays
list>array \ -- array elements
2dup w ['] <big-sort-seq> sort
array>list ;
Notice that the addresses given to the comparison function <BIG-SORT-SEQ> are doubly indirect. That is what I meant when I said that this was an "awkward" technique.
Here is the new code that uses SORT-LIST (that uses MergeSort internally) in which the addresses given to the comparison function <SORT-SEQ> are only singly indirect:
: <sort-seq> ( new-node node -- new-node flag )
.line @ count rover .line @ count compare A>B = ;
: sort-seq ( head -- new-head )
['] <sort-seq> sort-list ;
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-06 09:28 +0000 |
| Message-ID | <o9j9us$t1c$1@dont-email.me> |
| In reply to | #55436 |
On 3/6/2017 02:45, hughaguilar96@gmail.com wrote: > In Straight Forth, all work with strings is done on the string-stack > --- you never work with address and count on the data-stack like in > ANS-Forth --- a packed string (address and count packed into a cell) > can be held on the data-stack temporarily, and this is only done for > the purpose of storing it in a data-structure (where it takes up only > one cell, saving memory Why? On a modern system 64bit system, saving memory (which is scalable) & sacrificing CPU (where we're nearly at limit, hence not scalable) is the absolute reverse of what you should be pursuing. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-06 05:22 -0800 |
| Message-ID | <6c670837-c467-4144-a4a2-4c5d65589e5e@googlegroups.com> |
| In reply to | #55447 |
On Monday, March 6, 2017 at 2:28:37 AM UTC-7, Alex wrote: > On 3/6/2017 02:45, hughaguilar96@gmail.com wrote: > > In Straight Forth, all work with strings is done on the string-stack > > --- you never work with address and count on the data-stack like in > > ANS-Forth --- a packed string (address and count packed into a cell) > > can be held on the data-stack temporarily, and this is only done for > > the purpose of storing it in a data-structure (where it takes up only > > one cell, saving memory > > Why? On a modern system 64bit system, saving memory (which is scalable) > & sacrificing CPU (where we're nearly at limit, hence not scalable) is > the absolute reverse of what you should be pursuing. Data structures can be huge, so storing a string in one cell rather than two could save a lot of memory --- data-cache thrashing is a major speed sink, so saving memory is the same as improving speed. Straight Forth is a standard, so it describes behavior rather than implementation. As a practical matter though, it is worthwhile to design it in such a manner that implementation will be efficient on modern desktop-computers. My own implementation is ITC, and I expect that most implementations will be ITC for a while, although STC is possible. In an ITC system, it is worthwhile to make the string-stack be part of the standard. This allows all of the string-stack words to be primitives written in assembly-language. By comparison, ANS-Forth doesn't have a string-stack as part of the standard. I wrote STRING-STACK.4TH which is ANS-Forth --- in order for it to be ANS-Forth however, then it has to be written in Forth, and hence it has to depend upon the compiler's optimizer in order to be efficient (it is pretty efficient in VFX and is much less efficient in SwiftForth). Such a low-level and fundamental aspect of Forth as the string-stack should be part of the standard so it can be written in assembly-language for efficiency. Also, a lot of the Forth language (such as <# etc.) rely on having a string-stack, so if these words are going to be standard then the string-stack has to be standard also.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-06 14:25 +0000 |
| Message-ID | <o9jrbk$pse$1@dont-email.me> |
| In reply to | #55454 |
On 3/6/2017 13:22, hughaguilar96@gmail.com wrote: > On Monday, March 6, 2017 at 2:28:37 AM UTC-7, Alex wrote: >> On 3/6/2017 02:45, hughaguilar96@gmail.com wrote: >>> In Straight Forth, all work with strings is done on the >>> string-stack --- you never work with address and count on the >>> data-stack like in ANS-Forth --- a packed string (address and >>> count packed into a cell) can be held on the data-stack >>> temporarily, and this is only done for the purpose of storing it >>> in a data-structure (where it takes up only one cell, saving >>> memory >> >> Why? On a modern system 64bit system, saving memory (which is >> scalable) & sacrificing CPU (where we're nearly at limit, hence >> not scalable) is the absolute reverse of what you should be >> pursuing. > > Data structures can be huge, so storing a string in one cell rather > than two could save a lot of memory --- data-cache thrashing is a > major speed sink, so saving memory is the same as improving speed. Hugh, you're clueless here. Give up while you're behind. > > Straight Forth is a standard, so it describes behavior rather than > implementation. You've described an implementation with a one cell address/length thingy. Implementation. > > As a practical matter though, it is worthwhile to design it in such a > manner that implementation will be efficient on modern > desktop-computers. My own implementation is ITC, and I expect that > most implementations will be ITC for a while, although STC is > possible. > > In an ITC system, it is worthwhile to make the string-stack be part > of the standard. This allows all of the string-stack words to be > primitives written in assembly-language. By comparison, ANS-Forth > doesn't have a string-stack as part of the standard. I wrote > STRING-STACK.4TH which is ANS-Forth --- in order for it to be > ANS-Forth however, then it has to be written in Forth, and hence it > has to depend upon the compiler's optimizer in order to be efficient > (it is pretty efficient in VFX and is much less efficient in > SwiftForth). > > Such a low-level and fundamental aspect of Forth as the string-stack > should be part of the standard so it can be written in > assembly-language for efficiency. Also, a lot of the Forth language > (such as <# etc.) rely on having a string-stack, so if these words > are going to be standard then the string-stack has to be standard > also. > No, I disagree. It's more implementation & better suited to a library. But since your standard is dictatorial rather than collaborative, and you don't care for anyone's opinion except your own, you go for it. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-03-06 06:46 -0800 |
| Message-ID | <b8cc62ae-1611-418d-9290-f08569dd4edd@googlegroups.com> |
| In reply to | #55456 |
On Monday, March 6, 2017 at 7:25:33 AM UTC-7, Alex wrote: > On 3/6/2017 13:22, hughaguilar96@gmail.com wrote: > > Such a low-level and fundamental aspect of Forth as the string-stack > > should be part of the standard so it can be written in > > assembly-language for efficiency. Also, a lot of the Forth language > > (such as <# etc.) rely on having a string-stack, so if these words > > are going to be standard then the string-stack has to be standard > > also. > > No, I disagree. It's more implementation & better suited to a library. > But since your standard is dictatorial rather than collaborative, and > you don't care for anyone's opinion except your own, you go for it. Straight Forth is intended to be used for programs that work with numbers and programs that work with text. Because of this, numbers have to be defined, and strings have to be defined. I remember way back in the 1980s that Forth was compared to line-number BASIC and found to be lacking in regard to its support for strings. That was pretty pathetic! Now in the year 2017 we have ANS-Forth cult members arguing against Forth providing support for strings --- you do this because Elizabeth Rather requires you to do this --- such stupidity is why ANS-Forth failed, and also why Forth-200x will fail. Also, btw, I have said repeatedly that Straight Forth is collaborative --- the whole point of talking about it on comp.lang.forth is to solicit input from Forth programmers --- you are not a Forth programmer though; I don't want input from corporate shills who claim to: "do standards for a living."
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-03-06 15:43 +0000 |
| Message-ID | <o9jvuf$b8h$1@dont-email.me> |
| In reply to | #55459 |
On 3/6/2017 14:46, hughaguilar96@gmail.com wrote: > Also, btw, I have said repeatedly that Straight Forth is > collaborative That word does not mean what you think it means. -- Alex
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web