Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #60476 > unrolled thread
| Started by | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| First post | 2017-06-08 23:21 -0700 |
| Last post | 2017-06-16 19:35 -0700 |
| Articles | 20 on this page of 69 — 16 participants |
Back to article view | Back to comp.lang.forth
Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-08 23:21 -0700
Re: Heap's algorithm Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-09 00:27 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-09 01:40 -0700
Re: Heap's algorithm Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-09 02:15 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-09 03:04 -0700
Re: Heap's algorithm Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-06-09 03:50 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-09 07:37 -0700
Re: Heap's algorithm Coos Haak <htrofhc@gmail.com> - 2017-06-09 19:50 +0200
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-09 11:32 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-09 07:54 -0700
Re: Heap's algorithm Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-06-09 10:11 -0500
Re: Heap's algorithm Alex <alex@rivadpm.com> - 2017-06-09 18:43 +0100
Re: Heap's algorithm rickman <gnuarm@gmail.com> - 2017-06-09 11:18 -0400
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-09 08:42 -0700
Re: Heap's algorithm rickman <gnuarm@gmail.com> - 2017-06-09 13:43 -0400
Re: Heap's algorithm Lars Brinkhoff <lars.spam@nocrew.org> - 2017-06-09 13:08 +0200
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-09 09:35 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-09 23:31 -0700
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-10 14:28 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-10 14:44 -0700
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-10 18:56 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-10 19:19 -0700
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-10 21:04 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-10 21:08 -0700
Re: Heap's algorithm Ron Aaron <rambamist@gmail.com> - 2017-06-11 07:19 +0300
Re: Heap's algorithm Alex <alex@rivadpm.com> - 2017-06-11 09:43 +0100
Re: Heap's algorithm minforth@arcor.de - 2017-06-11 02:35 -0700
Re: Heap's algorithm Alex <alex@rivadpm.com> - 2017-06-11 10:45 +0100
Re: Heap's algorithm rickman <gnuarm@gmail.com> - 2017-06-11 12:32 -0400
Re: Heap's algorithm Alex <alex@rivadpm.com> - 2017-06-11 17:52 +0100
Re: Heap's algorithm rickman <gnuarm@gmail.com> - 2017-06-12 23:26 -0400
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-12 19:55 -0700
Re: Heap's algorithm krishna.myneni@ccreweb.org - 2017-06-11 14:40 -0700
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-12 09:02 -0700
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-10 21:30 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-10 21:51 -0700
Re: Heap's algorithm "Robert L." <No_spamming@noWhere_7073.org> - 2017-06-12 02:24 +0000
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-11 19:28 -0700
Re: Heap's algorithm Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-12 03:41 +0000
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-14 22:15 -0700
Re: Heap's algorithm Ron Aaron <rambamist@gmail.com> - 2017-06-15 08:29 +0300
Re: Heap's algorithm Alex <alex@rivadpm.com> - 2017-06-15 12:24 +0100
Re: Heap's algorithm Ron Aaron <rambamist@gmail.com> - 2017-06-15 15:59 +0300
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-16 01:25 -0700
Re: Heap's algorithm awegel@arcor.de (Alexander Wegel) - 2017-06-15 14:08 +0200
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-16 10:46 -0700
Re: Heap's algorithm awegel@arcor.de (Alexander Wegel) - 2017-06-17 02:47 +0200
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-09 00:31 -0700
Re: Heap's algorithm Coos Haak <htrofhc@gmail.com> - 2017-06-09 12:32 +0200
Re: Heap's algorithm hum9 <obi65537@gmail.com> - 2017-06-09 10:03 -0700
Re: Heap's algorithm hum9 <obi65537@gmail.com> - 2017-06-09 22:28 -0700
Re: Heap's algorithm hum9 <obi65537@gmail.com> - 2017-06-10 03:07 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-10 05:41 -0700
Re: Heap's algorithm hum9 <obi65537@gmail.com> - 2017-06-10 18:05 +0300
Re: Heap's algorithm "Robert L." <No_spamming@noWhere_7073.org> - 2017-06-12 03:32 +0000
Re: Heap's algorithm "Robert L." <No_spamming@noWhere_7073.org> - 2017-06-12 03:35 +0000
Re: Heap's algorithm "Robert L." <No_spamming@noWhere_7073.org> - 2017-06-12 04:01 +0000
Re: Heap's algorithm "Robert L." <No_spamming@noWhere_7073.org> - 2017-06-12 11:01 +0000
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-11 21:14 -0700
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-11 22:00 -0700
Re: Heap's algorithm Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-12 07:54 +0000
Re: Heap's algorithm Julian Fondren <julian.fondren@gmail.com> - 2017-06-12 01:13 -0700
Re: Heap's algorithm Melzzzzz <Melzzzzz@zzzzz.com> - 2017-06-12 08:20 +0000
Re: Heap's algorithm Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-14 20:17 +0100
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-16 01:16 -0700
Re: Heap's algorithm Alex <alex@rivadpm.com> - 2017-06-16 15:14 +0100
Re: Heap's algorithm Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-16 20:15 +0100
Re: Heap's algorithm Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2017-06-16 20:14 +0100
Re: Heap's algorithm hughaguilar96@gmail.com - 2017-06-16 19:35 -0700
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-10 18:56 -0700 |
| Message-ID | <7d60e303-f62f-4e11-af11-d294e2f1c53a@googlegroups.com> |
| In reply to | #60581 |
On Saturday, June 10, 2017 at 2:44:07 PM UTC-7, Julian Fondren wrote: > On Saturday, June 10, 2017 at 4:28:59 PM UTC-5, hughag...@gmail.com wrote: > > On Friday, June 9, 2017 at 11:31:45 PM UTC-7, Julian Fondren wrote: > > > On Friday, June 9, 2017 at 11:35:35 AM UTC-5, hughag...@gmail.com wrote: > > > > Also, I support arrays of structs --- the ANS-Forth crowd seems to be obsessed with forcing everybody to use arrays of cells. > > > > > > cells: 3.475 seconds elapsed. > > > structs: 21.650 seconds elapsed. > > > > > > cells: 3.672 seconds elapsed. > > > structs: 22.101 seconds elapsed. > > > > > > cells: 3.680 seconds elapsed. > > > structs: 22.145 seconds elapsed. ok > > > > > > It's just malice I guess. > > > > > > 'cells' is a permutation benchmark using code above. > > > > > > 'structs' is the same but MOVEing 10 cells: > > > > > > : structs 10 cells * ; > > > 1 structs buffer: pad > > > : switch ( a1 a2 -- ) > > dup pad 1 structs move > > > 2dup 1 structs move > > > drop pad swap 1 structs move ; > > > : next-permute ( c-addr u permute-state -- c-addr u permute-state f ) > > > over 0 do > > > dup i structs + @ i < if > > > i 2 mod 0= if > > > third dup i structs + switch > > > else > > > third dup i structs + swap > > > third i structs + @ cells + switch > > > then > > > 1 over i structs + +! > > > true unloop exit > > > then > > > 0 over i structs + ! loop false ( no more permutations ) ; > > > > This is not my code. > > No, that's QUITE OBVIOUSLY my code, seeing as it's almost identical to > the cell-permuting code that I claimed as my own in the very first > post of the thread. What's your point? Do you think you have code > that shows that moving more data is faster than moving less data? > > It's actually possible for that to be the case, since contiguous > access to memory is faster than random access to it, but you would > still need an apples-to-oranges comparison somewhere. Where's your > struct-sorter that's faster than the equivalent cell-sorter? Alex McDonald has spent four years (it will be four years in June) bashing my array SORT in the novice package. Now Julien Fondren has begun, and will presumably continue for another four years. ANS-Forth is a cult! They just continue with this utterly stupid nonsense year after year --- they think they are beating me down, and convincing the world that I don't know what pointers are --- they are just making the ANS-Forth cult look stupid, which is why nobody is volunteering to become an ANS-Forth programmer. I never actually said: "moving more data is faster than moving less data." I've said dozens of times already that my array definers and my array SORT support elements of any size (they have to be a multiple of the cell size for SORT to work, but FIELD assures this anyway). It is possible to have an array of pointers to structs, and it is also possible to have an array of structs. My novice-package is general-purpose code! This is not like Wil Baden's code that forces the user to have an array of cells. I support, for example, an array of floats. With Wil Baden's code, what you would likely do is cut-and-paste-and-modify the array of cells so that it is an array of floats --- cut-and-paste-and-modify is typical Forth Inc. programming style --- afaik, Wil Baden was a Forth Inc. employee. The novice-package user can decide if he wants to have an array of pointers to structs or an array of structs. It never occurred to me when I wrote the code that I should take this choice away from the user --- I would assume that anybody using the novice-package must be reasonably smart and capable of making choices such as this --- there are a lot of choices involved in the design of application programs, and this is one of them. If you have an array of pointers to structs, then where are the structs? If they are in the heap, then the cost of ALLOCATE and FREE is going to be significant. This is an argument for having an array of structs. Sometimes you may have a lot of structs in an array, and want it sorted by various keys. In this case, you would have various arrays of pointers to these structs each sorted by a different key. I don't actually care whether people have an array of pointers to structs or an array of structs.. As for myself, I almost never use arrays --- I would use LIST.4TH or ASSOCIATION.4TH generally.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-06-10 19:19 -0700 |
| Message-ID | <e99b7134-4f43-45d8-b125-d53344aade2d@googlegroups.com> |
| In reply to | #60590 |
On Saturday, June 10, 2017 at 8:56:25 PM UTC-5, hughag...@gmail.com wrote: Timeline: > On Saturday, June 10, 2017 at 2:44:07 PM UTC-7, Julian Fondren wrote: > > On Saturday, June 10, 2017 at 4:28:59 PM UTC-5, hughag...@gmail.com wrote: > > > On Friday, June 9, 2017 at 11:31:45 PM UTC-7, Julian Fondren wrote: > > > > On Friday, June 9, 2017 at 11:35:35 AM UTC-5, hughag...@gmail.com wrote: > > > > > Also, I support arrays of structs --- the ANS-Forth crowd seems to be obsessed with forcing everybody to use arrays of cells. Hugh: these idiots like arrays of cells for some reason. > > > > > > > > cells: 3.475 seconds elapsed. > > > > structs: 21.650 seconds elapsed. > > > > > > > > cells: 3.672 seconds elapsed. > > > > structs: 22.101 seconds elapsed. > > > > > > > > cells: 3.680 seconds elapsed. > > > > structs: 22.145 seconds elapsed. ok > > > > Me: gosh, I wonder why. > Alex McDonald has spent four years [blah blah blah] Hugh: I made a claim and somebody responded to it. That person is CULTISH and OBSESSED for responding to topics that I brought up completely on my own! > > I support, for example, an array of floats. With Wil Baden's code, what you would likely do is cut-and-paste-and-modify the array of cells so that it is an array of floats What I'd prefer to do for stuff like floats is have conditional code generation at compile time, and then you would load the library multiple times to get multiple sorts for multiple types. Manually doing the kind of type specialization that you see in some other languages. That's certanly better than writing a struct-sorter that's always significantly slower than the cell or float specializations, even when given 1 CELLS or 1 FLOATS as the length. But if your defense is, "this is 'generic', I know it's slower", you could at least stop pretending that people are insane or filled with evil for wanting code that's like 7x faster. > If you have an array of pointers to structs, then where are the structs? If they are in the heap, then the cost of ALLOCATE and FREE is going to be significant. This is an argument for having an array of structs. Having an array of pointers to structs doesn't require that you not also have an array of structs. You just use the array of pointers when you want to sort, permute, etc. Especially if you'll be doing that a lot. This is a pretty weird thing for you to say. > Sometimes you may have a lot of structs in an array, and want it sorted by various keys. In this case, you would have various arrays of pointers to these structs each sorted by a different key. > > I don't actually care whether people have an array of pointers to structs or an array of structs.. As for myself, I almost never use arrays --- I would use LIST.4TH or ASSOCIATION.4TH generally. OK. How would you sort a list? If you wanted to walk the keys of an association in an ordered way, how would you do that? One way is, generate an array of addresses into either, sort that, and then iterate over it.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-10 21:04 -0700 |
| Message-ID | <57d6da0e-bdf3-4c9c-93b4-e8b62a13dae5@googlegroups.com> |
| In reply to | #60592 |
On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote: > But if your defense is, "this is 'generic', I know it's slower", you > could at least stop pretending that people are insane or filled with > evil for wanting code that's like 7x faster. ANS-Forth is a cult --- Elizabeth Rather claims to be the "leading expert" of Forth, which is just a gross insult to Forthers such as myself --- all of her sycophants make wild claims about how their code is "like 7x faster" than anybody else's. Why claim that your code is only 7x faster than mine? Why not claim that it is 700x faster? Go big or go home! LOL
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-06-10 21:08 -0700 |
| Message-ID | <8c4833b9-35c0-4ed7-8d86-4e728d9002a3@googlegroups.com> |
| In reply to | #60593 |
On Saturday, June 10, 2017 at 11:04:30 PM UTC-5, hughag...@gmail.com wrote: > On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote: > > But if your defense is, "this is 'generic', I know it's slower", you > > could at least stop pretending that people are insane or filled with > > evil for wanting code that's like 7x faster. > > Why claim that your code is only 7x faster than mine? Because of the benchmark above. >Why not claim that it is 700x faster? Go big or go home! LOL Since moving more data is slower than moving less that, a benchmark like this is probably possible. A near 7x difference was seen with just 10-cell structs.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2017-06-11 07:19 +0300 |
| Message-ID | <ohig6t$del$1@dont-email.me> |
| In reply to | #60594 |
On 06/11/17 07:08, Julian Fondren wrote: > On Saturday, June 10, 2017 at 11:04:30 PM UTC-5, hughag...@gmail.com wrote: >> On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote: >>> But if your defense is, "this is 'generic', I know it's slower", you >>> could at least stop pretending that people are insane or filled with >>> evil for wanting code that's like 7x faster. >> >> Why claim that your code is only 7x faster than mine? > > Because of the benchmark above. > >> Why not claim that it is 700x faster? Go big or go home! LOL > > Since moving more data is slower than moving less that, a benchmark > like this is probably possible. A near 7x difference was seen with > just 10-cell structs. He doesn't believe in measuring or (apparently) empirical data. Don't waste your time
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-11 09:43 +0100 |
| Message-ID | <ohivk5$m6g$1@dont-email.me> |
| In reply to | #60595 |
On 6/11/2017 05:19, Ron Aaron wrote: > > > On 06/11/17 07:08, Julian Fondren wrote: >> On Saturday, June 10, 2017 at 11:04:30 PM UTC-5, hughag...@gmail.com wrote: >>> On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote: >>>> But if your defense is, "this is 'generic', I know it's slower", you >>>> could at least stop pretending that people are insane or filled with >>>> evil for wanting code that's like 7x faster. >>> >>> Why claim that your code is only 7x faster than mine? >> >> Because of the benchmark above. >> >>> Why not claim that it is 700x faster? Go big or go home! LOL >> >> Since moving more data is slower than moving less that, a benchmark >> like this is probably possible. A near 7x difference was seen with >> just 10-cell structs. > > He doesn't believe in measuring or (apparently) empirical data. Don't > waste your time > The list of things Hugh doesn't understand is very large, and as I've said before, it includes pointers and sorting. He keeps repeating this nonsense about sorting arrays by moving the contents. He's never going to understand. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-06-11 02:35 -0700 |
| Message-ID | <eb466ef1-520d-4f2a-97a3-4782bbbe72c1@googlegroups.com> |
| In reply to | #60602 |
Am Sonntag, 11. Juni 2017 10:43:10 UTC+2 schrieb Alex: > On 6/11/2017 05:19, Ron Aaron wrote: > > > > > > On 06/11/17 07:08, Julian Fondren wrote: > >> On Saturday, June 10, 2017 at 11:04:30 PM UTC-5, hughag...@gmail.com wrote: > >>> On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote: > >>>> But if your defense is, "this is 'generic', I know it's slower", you > >>>> could at least stop pretending that people are insane or filled with > >>>> evil for wanting code that's like 7x faster. > >>> > >>> Why claim that your code is only 7x faster than mine? > >> > >> Because of the benchmark above. > >> > >>> Why not claim that it is 700x faster? Go big or go home! LOL > >> > >> Since moving more data is slower than moving less that, a benchmark > >> like this is probably possible. A near 7x difference was seen with > >> just 10-cell structs. > > > > He doesn't believe in measuring or (apparently) empirical data. Don't > > waste your time > > > > The list of things Hugh doesn't understand is very large, and as I've > said before, it includes pointers and sorting. He keeps repeating this > nonsense about sorting arrays by moving the contents. He's never going > to understand. > > -- > Alex Well I try to never pronounce sentence over someone who is honestly trying, but comes up with a not yet optimal solution. I don't read his posts because he had been unpolite too often, not because he hasn't got a science degree.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-11 10:45 +0100 |
| Message-ID | <ohj38q$sr$1@dont-email.me> |
| In reply to | #60603 |
On 6/11/2017 10:35, minforth@arcor.de wrote: > Am Sonntag, 11. Juni 2017 10:43:10 UTC+2 schrieb Alex: >> On 6/11/2017 05:19, Ron Aaron wrote: >>> >>> >>> On 06/11/17 07:08, Julian Fondren wrote: >>>> On Saturday, June 10, 2017 at 11:04:30 PM UTC-5, hughag...@gmail.com wrote: >>>>> On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote: >>>>>> But if your defense is, "this is 'generic', I know it's slower", you >>>>>> could at least stop pretending that people are insane or filled with >>>>>> evil for wanting code that's like 7x faster. >>>>> >>>>> Why claim that your code is only 7x faster than mine? >>>> >>>> Because of the benchmark above. >>>> >>>>> Why not claim that it is 700x faster? Go big or go home! LOL >>>> >>>> Since moving more data is slower than moving less that, a benchmark >>>> like this is probably possible. A near 7x difference was seen with >>>> just 10-cell structs. >>> >>> He doesn't believe in measuring or (apparently) empirical data. Don't >>> waste your time >>> >> >> The list of things Hugh doesn't understand is very large, and as I've >> said before, it includes pointers and sorting. He keeps repeating this >> nonsense about sorting arrays by moving the contents. He's never going >> to understand. >> >> -- >> Alex > > Well I try to never pronounce sentence over someone who is honestly > trying, but comes up with a not yet optimal solution. Good on you. But I do. There's no honesty. It's Hugh's way or the highway. And this isn't about trying; it's about... > > I don't read his posts because he had been unpolite too often, not > because he hasn't got a science degree. > ... this. He is fine as long as you don't disagree with him. Then he is, to be frank, not someone you would ever want to be in the same room with. I don't have a science degree either, but I read & listen to others who have. Hugh doesn't do any of the latter, by his own admission. The combination of the two toxic behaviours is getting him this; you can't blame me (or others here) for Hugh's stupidity on these counts, nor our reaction to his technically incompetent and near insane posts. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-11 12:32 -0400 |
| Message-ID | <ohjr3o$d03$1@dont-email.me> |
| In reply to | #60604 |
Alex wrote on 6/11/2017 5:45 AM: > On 6/11/2017 10:35, minforth@arcor.de wrote: >> Am Sonntag, 11. Juni 2017 10:43:10 UTC+2 schrieb Alex: >>> On 6/11/2017 05:19, Ron Aaron wrote: >>>> >>>> >>>> On 06/11/17 07:08, Julian Fondren wrote: >>>>> On Saturday, June 10, 2017 at 11:04:30 PM UTC-5, hughag...@gmail.com >>>>> wrote: >>>>>> On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote: >>>>>>> But if your defense is, "this is 'generic', I know it's slower", you >>>>>>> could at least stop pretending that people are insane or filled with >>>>>>> evil for wanting code that's like 7x faster. >>>>>> >>>>>> Why claim that your code is only 7x faster than mine? >>>>> >>>>> Because of the benchmark above. >>>>> >>>>>> Why not claim that it is 700x faster? Go big or go home! LOL >>>>> >>>>> Since moving more data is slower than moving less that, a benchmark >>>>> like this is probably possible. A near 7x difference was seen with >>>>> just 10-cell structs. >>>> >>>> He doesn't believe in measuring or (apparently) empirical data. Don't >>>> waste your time >>>> >>> >>> The list of things Hugh doesn't understand is very large, and as I've >>> said before, it includes pointers and sorting. He keeps repeating this >>> nonsense about sorting arrays by moving the contents. He's never going >>> to understand. >>> >>> -- >>> Alex >> >> Well I try to never pronounce sentence over someone who is honestly >> trying, but comes up with a not yet optimal solution. > > Good on you. > > But I do. There's no honesty. It's Hugh's way or the highway. And this isn't > about trying; it's about... > >> >> I don't read his posts because he had been unpolite too often, not >> because he hasn't got a science degree. >> > > ... this. He is fine as long as you don't disagree with him. Then he is, to > be frank, not someone you would ever want to be in the same room with. > > I don't have a science degree either, but I read & listen to others who > have. Hugh doesn't do any of the latter, by his own admission. Formal education is rather overrated and this is from someone with a masters degree, so I have some basis for knowing what I'm talking about. Even with a masters degree I only left school with a basic education in engineering and learned much more on the job than I came to work with. When I started as an engineer a degree was not required, good thing as my BS was in Biochemistry. I worked on my degree while working as an associate engineer and when I graduated I was told there would be no raise for obtaining the degree... so I found another job where the MS degree was valued. The MS degree has been a profitable flag to have on my resume ever since. I'm not saying I didn't learn anything in graduate school, just the opposite. I think I learned much more quickly than I would have on the job. But for the most part I didn't gain much that I wouldn't or couldn't have picked up in a few years of working in the field. Mostly I learned an appreciation for doing the work in a structured manner which was only promoted by employers some 10 or more years later. > The combination of the two toxic behaviours is getting him this; you can't > blame me (or others here) for Hugh's stupidity on these counts, nor our > reaction to his technically incompetent and near insane posts. I'm pretty over trying to have any useful communication with people like that. There are far too many of them on the Internet and far too little time. I want to try to spend some time on useful projects. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-06-11 17:52 +0100 |
| Message-ID | <ohjs9e$gpi$1@dont-email.me> |
| In reply to | #60612 |
On 6/11/2017 17:32, rickman wrote: > > Formal education is rather overrated and this is from someone with a > masters degree, so I have some basis for knowing what I'm talking > about. Even with a masters degree I only left school with a basic > education in engineering and learned much more on the job than I came to > work with. I've been in this industry for (jeez I'm old) over 40 years. I learned on the job, but what I learned was important; there are smarter people out there than me, but I can be as smart as them if I listen, read and use what they know. >> The combination of the two toxic behaviours is getting him this; you >> can't >> blame me (or others here) for Hugh's stupidity on these counts, nor our >> reaction to his technically incompetent and near insane posts. > > I'm pretty over trying to have any useful communication with people like > that. There are far too many of them on the Internet and far too little > time. I want to try to spend some time on useful projects. The disinformation they spread is toxic. It's like green slime; it gets everywhere. I'm afraid I sometimes can't stop myself from pointing out how it gunges up everything, including brains. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-06-12 23:26 -0400 |
| Message-ID | <ohnlr4$jkr$1@dont-email.me> |
| In reply to | #60616 |
Alex wrote on 6/11/2017 12:52 PM: > On 6/11/2017 17:32, rickman wrote: > >> >> Formal education is rather overrated and this is from someone with a >> masters degree, so I have some basis for knowing what I'm talking about. >> Even with a masters degree I only left school with a basic education in >> engineering and learned much more on the job than I came to work with. > > I've been in this industry for (jeez I'm old) over 40 years. I learned on > the job, but what I learned was important; there are smarter people out > there than me, but I can be as smart as them if I listen, read and use what > they know. > >>> The combination of the two toxic behaviours is getting him this; you can't >>> blame me (or others here) for Hugh's stupidity on these counts, nor our >>> reaction to his technically incompetent and near insane posts. >> >> I'm pretty over trying to have any useful communication with people like >> that. There are far too many of them on the Internet and far too little >> time. I want to try to spend some time on useful projects. > > The disinformation they spread is toxic. It's like green slime; it gets > everywhere. I'm afraid I sometimes can't stop myself from pointing out how > it gunges up everything, including brains. But in doing so, you also spread some of the green slime as well. I recently saw a photo of a Roomba that encountered a fresh dog pile and spread it around the room rather than picking it up. Some things are best left untouched. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-12 19:55 -0700 |
| Message-ID | <b5860b29-e5ec-4535-88e2-1f91395f3243@googlegroups.com> |
| In reply to | #60612 |
On Sunday, June 11, 2017 at 9:32:17 AM UTC-7, rickman wrote: > Alex wrote on 6/11/2017 5:45 AM: > > ...you can't > > blame me (or others here) for Hugh's stupidity on these counts, nor our > > reaction to his technically incompetent and near insane posts. > > I'm pretty over trying to have any useful communication with people like > that. There are far too many of them on the Internet and far too little > time. I want to try to spend some time on useful projects. Alex McDonald and Julien Fondren are obviously attacking me for the purpose of impressing Elizabeth Rather with their loyalty, in the hope that she will appoint them to the Forth-200x committee. I don't think this is going to work. She already has the Forth-200x committee packed with sycophants. What would be the point of adding two more sycophants --- she already controls every vote on the committee. Rickman has never done any programming in Forth --- he can't get appointed to the Forth-200x committee because he doesn't understand even the most basic aspects of Forth --- he is just attacking me because he enjoys it. He says: On Monday, May 13, 2013 at 8:07:20 PM UTC-7, rickman wrote: > He doesn't bother me so much as others. But I realize I have been > feeding him again. It's just that he's so *cute* when you give him a > cookie and he does the little dance. Does this post of mine count as a "little dance" in Rickman's world? Maybe so --- he is hoping for an emotional response, and this post was wasn't --- he is presumably happy with any kind of response though...
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-06-11 14:40 -0700 |
| Message-ID | <cc16dd0c-9648-4cba-9aa0-814ebd03457f@googlegroups.com> |
| In reply to | #60603 |
On Sunday, June 11, 2017 at 4:36:00 AM UTC-5, minf...@arcor.de wrote: ... > I don't read his posts because he had been unpolite too often, not > because he hasn't got a science degree. Having a science degree is certainly not a basis for judging whether someone's contribution is useful or not -- what's required is a willingness to experiment, to learn from others, and to communicate in a socially acceptable way. Krishna
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-12 09:02 -0700 |
| Message-ID | <dac85523-961d-4d2d-9ac7-8de701f93488@googlegroups.com> |
| In reply to | #60603 |
On Sunday, June 11, 2017 at 2:36:00 AM UTC-7, minf...@arcor.de wrote: > Am Sonntag, 11. Juni 2017 10:43:10 UTC+2 schrieb Alex: > > On 6/11/2017 05:19, Ron Aaron wrote: > > > > > > > > > On 06/11/17 07:08, Julian Fondren wrote: > > >> On Saturday, June 10, 2017 at 11:04:30 PM UTC-5, hughag...@gmail.com wrote: > > >>> On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote: > > >>>> But if your defense is, "this is 'generic', I know it's slower", you > > >>>> could at least stop pretending that people are insane or filled with > > >>>> evil for wanting code that's like 7x faster. > > >>> > > >>> Why claim that your code is only 7x faster than mine? > > >> > > >> Because of the benchmark above. > > >> > > >>> Why not claim that it is 700x faster? Go big or go home! LOL > > >> > > >> Since moving more data is slower than moving less that, a benchmark > > >> like this is probably possible. A near 7x difference was seen with > > >> just 10-cell structs. > > > > > > He doesn't believe in measuring or (apparently) empirical data. Don't > > > waste your time > > > > > > > The list of things Hugh doesn't understand is very large, and as I've > > said before, it includes pointers and sorting. He keeps repeating this > > nonsense about sorting arrays by moving the contents. He's never going > > to understand. > > > > -- > > Alex > > Well I try to never pronounce sentence over someone who is honestly > trying, but comes up with a not yet optimal solution. > > I don't read his posts because he had been unpolite too often, not > because he hasn't got a science degree. You're Marcel Hendrix, aren't you? This was my first-ever contact with Marcel Hendrix: https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D You seem to be concealing your name now --- you have a different username that doesn't include your real name.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-10 21:30 -0700 |
| Message-ID | <3cf7581a-1478-4665-a091-0f15fb072821@googlegroups.com> |
| In reply to | #60592 |
On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote: > OK. How would you sort a list? I have merge-sort now. If you wanted to walk the keys of an > association in an ordered way, how would you do that? ASSOCIATION.4TH is a binary-tree, dumb-ass! You are criticizing my ASSOCIATION.4TH without having ever looked at it, and without knowing anything about it --- I wrote this way back in 2010 --- you've had time to look at it. > One way is, generate an array of addresses into either, sort that, > and then iterate over it. I had BIG-SORT in LIST.4TH that did this --- that was also written in 2010 --- I used that prior to writing merge-sort last year. I still have LIST>ARRAY and ARRAY>LIST for converting a list into an array and back again, although they aren't really needed anymore. The advantage of merge-sort over BIG-SORT is primarily that the comparer function is simpler because the pointers are only one level of indirection rather than two --- this isn't a big deal though --- there is actually no practical difference in speed between the insertion-sort of a list, heap-sort of an array and merge-sort of a list. All of this talk about how your code is 7x faster than my code, is baloney. You don't actually have any code (I suppose you could trot out Wil Baden's SORT function that he wrote in the 1980s, but it is not general-purpose and it is not fast). I have multiple versions, using various algorithms, and all of them are pretty close in speed. If there was some whiz-bang algorithm that provided a 7x boost in speed, or even a 2x boost in speed, I would use it --- but there isn't --- your gigantic leaps in performance, due to your supposedly superior knowledge, are just fantasy.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-06-10 21:51 -0700 |
| Message-ID | <46469ecc-b943-485a-8fac-3178c08e714d@googlegroups.com> |
| In reply to | #60596 |
On Saturday, June 10, 2017 at 11:30:34 PM UTC-5, hughag...@gmail.com wrote: > If you wanted to walk the keys of an > > association in an ordered way, how would you do that? > > ASSOCIATION.4TH is a binary-tree, dumb-ass! OK, now walk over it according to an arbitrary, user-supplied order. > You are criticizing my ASSOCIATION.4TH Quote the criticism. What did I say about it? > I still have LIST>ARRAY and ARRAY>LIST for converting a list into an array and back again, although they aren't really needed anymore. Convert? As in, the array's its own independent data structure? I'm talking about creating temporary arrays as views into other data structures. > All of this talk about how your code is 7x faster than my code, is baloney. You don't actually have any code Both NEXT-PERMUTEs are in the thread. Remember when you said "this isn't my code"? That was one of the NEXT-PERMUTEs. You've anyway already agreed that moving more data is obviously slower than moving less data. You just have too much of a grudge against Alex I guess to take that thought to its conclusions. > If there was some whiz-bang algorithm that provided a 7x boost in speed, or even a 2x boost in speed, The whole point is that IT IS THE SAME ALGORITHM. JUST USING CELLS INSTEAD OF LARGER SPANS OF DATA. The *same* algorithm with @/! cells is enormously faster than the *same* algorithm MOVEing 10-cell structs. Operating on cells is so much faster that even if your aim was to sort structs, you could probably do that faster by sorting cells and then rebuilding the array of structs according to the sorted array of cells.
[toc] | [prev] | [next] | [standalone]
| From | "Robert L." <No_spamming@noWhere_7073.org> |
|---|---|
| Date | 2017-06-12 02:24 +0000 |
| Message-ID | <ohku0f$6e6$1@gioia.aioe.org> |
| In reply to | #60592 |
On 6/10/2017, Julian Fondren wrote: > If you wanted to walk the keys of an > association in an ordered way, how would you do that? That makes as much sense as saying "If you wanted to taste a color, how would you do that?" By definition, an associative array is unordered. It merely associates keys with values. -- [E]verything that happens in the world is for the benefit of the Jewish People.... G-D ... created the world for the sake of the Jewish People, and it is our responsibility to implement the Torah---absolute morality and the blueprint of creation---in it. www.IsraelNationalNews.com/Articles/Article.aspx/2125#.UUnBZxx4xn8
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2017-06-11 19:28 -0700 |
| Message-ID | <1fc39e92-ae85-4aa2-beb8-b638eba46b23@googlegroups.com> |
| In reply to | #60631 |
On Sunday, June 11, 2017 at 9:24:20 PM UTC-5, Robert L. wrote: > On 6/10/2017, Julian Fondren wrote: > > > If you wanted to walk the keys of an > > association in an ordered way, how would you do that? > > That makes as much sense as saying "If you wanted to > taste a color, how would you do that?" > > By definition, an associative array is unordered. > > It merely associates keys with values. > Wow. You really do no other programming than what you post here.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2017-06-12 03:41 +0000 |
| Message-ID | <ohl2gh$lh9$3@news.albasani.net> |
| In reply to | #60632 |
On 2017-06-12, Julian Fondren <julian.fondren@gmail.com> wrote: > On Sunday, June 11, 2017 at 9:24:20 PM UTC-5, Robert L. wrote: >> On 6/10/2017, Julian Fondren wrote: >> >> > If you wanted to walk the keys of an >> > association in an ordered way, how would you do that? >> >> That makes as much sense as saying "If you wanted to >> taste a color, how would you do that?" >> >> By definition, an associative array is unordered. >> >> It merely associates keys with values. >> > > Wow. You really do no other programming than what you post here. He haven't used languages where `associative array` is called `map`, represented by tree ;) -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2017-06-14 22:15 -0700 |
| Message-ID | <d2559cc0-b41a-4d35-ad78-52aace17fb26@googlegroups.com> |
| In reply to | #60592 |
On Saturday, June 10, 2017 at 7:19:44 PM UTC-7, Julian Fondren wrote:
> But if your defense is, "this is 'generic', I know it's slower", you
> could at least stop pretending that people are insane or filled with
> evil for wanting code that's like 7x faster.
My array sort is getting attacked pretty hard! Why the array sort, rather than some other aspect of the novice-package? The array sort is very basic code, so it seems an unlikely target for attack.
I think the reason why it is targeted in particular is because EXCHANGE shows up the weakness of SwiftForth.
Here is the EXCHANGE code:
-----------------------------------------------------------------------
SwiftForth? [if] \ SwiftForth's optimization is so bad that no Forth version is any good
icode exchange ( adrX adrY size -- ) \ the size of the record must be a multiple of W
0 [ebp] edx mov w [ebp] ecx mov \ EDX<>ECX, with EBX being the size
begin non-zero? while
0 [ecx] eax mov
0 [edx] eax xor eax 0 [edx] xor 0 [edx] eax xor
eax 0 [ecx] mov
w # edx add w # ecx add
w # ebx sub repeat
w 2 * [ebp] ebx mov
w 3 * # ebp add ret end-code
[else]
macro: exchange ( adrX adrY size -- ) \ the size of the record must be a multiple of W
begin dup while \ -- adrX adrY remaining
-rot \ -- remaining adrX adrY
dup @ rover @ \ -- remaining adrX adrY Y X
rover ! rover ! \ -- remaining adrX adrY
w + swap w + rot w - \ -- adrY adrX remaining \ adrY and adrX change places
repeat
3drop ;
[then]
-----------------------------------------------------------------------
Is SwiftForth's optimization bad?
Well, here is EXCHANGE in VFX:
: test exchange ; ok
see test
TEST
( 004E0A20 85DB ) TEST EBX, EBX
( 004E0A22 0F8425000000 ) JZ/E 004E0A4D
( 004E0A28 8B5500 ) MOV EDX, [EBP]
( 004E0A2B 8B0A ) MOV ECX, 0 [EDX]
( 004E0A2D 8B4504 ) MOV EAX, [EBP+04]
( 004E0A30 8B00 ) MOV EAX, 0 [EAX]
( 004E0A32 8902 ) MOV 0 [EDX], EAX
( 004E0A34 8B4504 ) MOV EAX, [EBP+04]
( 004E0A37 8908 ) MOV 0 [EAX], ECX
( 004E0A39 83C204 ) ADD EDX, 04
( 004E0A3C 8B4D04 ) MOV ECX, [EBP+04]
( 004E0A3F 83C104 ) ADD ECX, 04
( 004E0A42 83C3FC ) ADD EBX, -04
( 004E0A45 894D00 ) MOV [EBP], ECX
( 004E0A48 895504 ) MOV [EBP+04], EDX
( 004E0A4B EBD3 ) JMP 004E0A20 TEST
( 004E0A4D 8B5D08 ) MOV EBX, [EBP+08]
( 004E0A50 8D6D0C ) LEA EBP, [EBP+0C]
( 004E0A53 C3 ) NEXT,
( 52 bytes, 19 instructions )
ok
Here is EXCHANGE in SwiftForth (name changed to FORTH-EXCHANGE to distinguish it from my ICODE version):
see forth-exchange
4908CF EBX EBX OR 09DB
4908D1 490944 JZ 0F846D000000
4908D7 EBX ECX MOV 8BCB
4908D9 4 [EBP] EAX MOV 8B4504
4908DC 0 [EBP] EBX MOV 8B5D00
4908DF EAX 0 [EBP] MOV 894500
4908E2 ECX 4 [EBP] MOV 894D04
4908E5 4 # EBP SUB 83ED04
4908E8 EBX 0 [EBP] MOV 895D00
4908EB 0 [EBX] EBX MOV 8B1B
4908ED 4 # EBP SUB 83ED04
4908F0 EBX 0 [EBP] MOV 895D00
4908F3 8 [EBP] EBX MOV 8B5D08
4908F6 0 [EBX] EBX MOV 8B1B
4908F8 4 # EBP SUB 83ED04
4908FB EBX 0 [EBP] MOV 895D00
4908FE 8 [EBP] EBX MOV 8B5D08
490901 0 [EBP] EAX MOV 8B4500
490904 EAX 0 [EBX] MOV 8903
490906 4 [EBP] EBX MOV 8B5D04
490909 8 # EBP ADD 83C508
49090C 4 # EBP SUB 83ED04
49090F EBX 0 [EBP] MOV 895D00
490912 8 [EBP] EBX MOV 8B5D08
490915 0 [EBP] EAX MOV 8B4500
490918 EAX 0 [EBX] MOV 8903
49091A 4 [EBP] EBX MOV 8B5D04
49091D 8 # EBP ADD 83C508
490920 4 # EBX ADD 83C304
490923 0 [EBP] EAX MOV 8B4500
490926 EBX 0 [EBP] MOV 895D00
490929 EAX EBX MOV 8BD8
49092B 4 # EBX ADD 83C304
49092E EBX ECX MOV 8BCB
490930 4 [EBP] EBX MOV 8B5D04
490933 0 [EBP] EAX MOV 8B4500
490936 EAX 4 [EBP] MOV 894504
490939 ECX 0 [EBP] MOV 894D00
49093C 4 # EBX SUB 83EB04
49093F 4908CF JMP E98BFFFFFF
490944 48369F ( 3drop ) JMP E9562DFFFF ok
SwiftForth optimization is pretty bad! This is why I have so much SwiftForth-specific assembly-language in the novice-package. This is my hand-written version:
see exchange
48689F 0 [EBP] EDX MOV 8B5500
4868A2 4 [EBP] ECX MOV 8B4D04
4868A5 EBX EBX OR 09DB
4868A7 4868BE JZ 7415
4868A9 0 [ECX] EAX MOV 8B01
4868AB 0 [EDX] EAX XOR 3302
4868AD EAX 0 [EDX] XOR 3102
4868AF 0 [EDX] EAX XOR 3302
4868B1 EAX 0 [ECX] MOV 8901
4868B3 4 # EDX ADD 83C204
4868B6 4 # ECX ADD 83C104
4868B9 4 # EBX SUB 83EB04
4868BC 4868A5 JMP EBE7
4868BE 8 [EBP] EBX MOV 8B5D08
4868C1 C # EBP ADD 83C50C
4868C4 RET C3 ok
EXCHANGE shines a spotlight on the poor code quality of SwiftForth. This is why Elizabeth Rather's sycophants say that I know my code is 7x slower than their code. They want to ban EXCHANGE so nobody sees what a bad job SwiftForth does of compiling it. They want me to stop writing Forth code --- it is Elizabeth Rather's way or the highway!
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web