Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #52738 > unrolled thread
| Started by | humptydumpty <ouatubi@gmail.com> |
|---|---|
| First post | 2016-11-19 13:34 -0800 |
| Last post | 2017-04-11 06:41 -0700 |
| Articles | 20 on this page of 159 — 26 participants |
Back to article view | Back to comp.lang.forth
Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-19 13:34 -0800
Re: Yet another draw of rectangle "Robert L." <No_spamming@noWhere_7073.org> - 2016-11-20 00:53 +0000
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-20 14:46 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-19 20:01 -0800
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-20 20:10 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 01:18 -0800
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 01:36 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 02:16 -0800
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 02:36 -0800
Re: Yet another draw of rectangle Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-20 07:48 -0500
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-22 23:36 -0500
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 02:03 -0800
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-20 21:49 +1100
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-20 03:33 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 08:52 -0800
Re: Yet another draw of rectangle Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-20 12:05 -0600
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-21 10:43 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-20 16:25 -0800
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-21 15:20 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-22 00:02 -0800
Re: Yet another draw of rectangle Mark Wills <markwills1970@gmail.com> - 2016-11-22 01:00 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-22 01:13 -0800
Re: Yet another draw of rectangle "Robert L." <No_spamming@noWhere_7073.org> - 2016-11-22 20:54 +0000
Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-11-27 13:32 +1100
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-26 18:52 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-11-28 15:00 +1100
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-27 18:32 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-27 20:44 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-11-29 15:22 +1100
Re: Yet another language ( was Yet another draw of rectangle) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-29 00:42 -0500
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-28 22:20 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-29 17:18 -0800
Re: Yet another language ( was Yet another draw of rectangle) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-11-29 23:15 -0500
Re: Yet another language ( was Yet another draw of rectangle) Ron Aaron <rambamist@gmail.com> - 2016-11-30 07:08 +0200
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-29 21:51 -1000
Re: Yet another language ( was Yet another draw of rectangle) Ron Aaron <rambamist@gmail.com> - 2016-11-30 12:09 +0200
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 09:43 -1000
Re: Yet another language ( was Yet another draw of rectangle) Cecil Bayona <cbayona@cbayona.com> - 2016-11-30 17:36 -0600
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-30 14:31 -1000
Re: Yet another language ( was Yet another draw of rectangle) Ron Aaron <rambamist@gmail.com> - 2016-12-01 07:02 +0200
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-01 08:58 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-01 16:44 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-05 21:28 +1100
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-05 07:41 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-06 18:13 +1100
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-05 21:36 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 00:05 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-08 10:09 +1100
Re: Yet another language ( was Yet another draw of rectangle) Paul Rubin <no.email@nospam.invalid> - 2016-12-07 15:27 -0800
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-08 04:22 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-08 17:05 -0800
Re: Yet another language ( was Yet another draw of rectangle) Mark Wills <markwills1970@gmail.com> - 2016-12-09 01:47 -0800
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-09 04:01 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-09 06:49 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-10 10:15 +1100
Re: Yet another language ( was Yet another draw of rectangle) josv@planet.nl - 2017-04-12 04:47 -0700
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-12-07 14:34 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-07 18:39 -0800
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-10 09:38 +1100
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-09 16:25 -0800
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 00:14 -0800
Re: Yet another language ( was Yet another draw of rectangle) stephen@mpeforth.com (Stephen Pelc) - 2016-12-06 12:01 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 10:21 -0800
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-09 16:27 -0800
Re: Yet another language ( was Yet another draw of rectangle) Rob Sciuk <rob@controlq.com> - 2017-04-08 21:05 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-08 18:57 -0700
Re: Yet another language ( was Yet another draw of rectangle) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-09 05:28 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-09 06:45 -0700
Re: Yet another language ( was Yet another draw of rectangle) Rob Sciuk <rob@controlq.com> - 2017-04-10 16:54 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-10 17:21 -0700
Re: Yet another language ( was Yet another draw of rectangle) Jan Coombs <jenfhaomndgfwutc@murmic.plus.com> - 2017-04-11 08:03 +0100
Re: Yet another language ( was Yet another draw of rectangle) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-11 07:50 +0000
Re: Yet another language ( was Yet another draw of rectangle) Rob Sciuk <rob@controlq.com> - 2017-04-11 11:43 -0400
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-11 10:16 -0700
Re: Yet another language ( was Yet another draw of rectangle) Paul Rubin <no.email@nospam.invalid> - 2017-04-11 10:21 -0700
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-11 10:48 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-11 23:58 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 03:07 -0400
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 00:29 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 00:55 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 04:07 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 13:29 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 16:51 -0400
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 03:50 -0700
Re: Yet another language ( was Yet another draw of rectangle) Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-12 12:55 +0200
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 04:17 -0700
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-12 06:03 -0500
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 04:30 -0700
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-12 08:44 -0500
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 13:01 -0400
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 13:33 -0700
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 12:59 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 17:05 -0400
Re: Yet another language ( was Yet another draw of rectangle) Ilya Tarasov <ilya74.tarasov@gmail.com> - 2017-04-11 10:27 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-11 14:02 -0400
Re: Yet another language ( was Yet another draw of rectangle) Julian Fondren <julian.fondren@gmail.com> - 2017-04-08 20:10 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-13 13:16 -0400
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-05 12:01 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-05 10:39 -0800
Re: Yet another language ( was Yet another draw of rectangle) Alex <alex@rivadpm.com> - 2016-12-05 18:53 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-05 11:33 -0800
Re: Yet another language ( was Yet another draw of rectangle) Alex <alex@rivadpm.com> - 2016-12-05 22:22 +0000
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-06 04:29 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 11:32 -0800
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-07 19:06 -0800
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-06 04:27 -0600
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-06 10:24 -0800
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-11-30 13:41 +0000
Re: Yet another language ( was Yet another draw of rectangle) stephen@mpeforth.com (Stephen Pelc) - 2016-11-30 15:15 +0000
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-12-01 09:54 +0000
Re: Yet another language ( was Yet another draw of rectangle) Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-12-01 04:42 -0600
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 13:09 -0400
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 13:14 -0400
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 08:32 -1000
Re: Yet another language ( was Yet another draw of rectangle) lehs <skydda.barnen@gmail.com> - 2017-04-12 12:42 -0700
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 10:36 -1000
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 16:41 -0400
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2017-04-12 13:25 -1000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2017-04-12 14:13 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-12 17:45 -0400
Re: Yet another language ( was Yet another draw of rectangle) Mark Wills <markwills1970@gmail.com> - 2017-04-13 05:53 -0700
Re: Yet another language ( was Yet another draw of rectangle) rickman <gnuarm@gmail.com> - 2017-04-13 13:34 -0400
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-11-29 11:48 +0000
Re: Yet another language ( was Yet another draw of rectangle) stephen@mpeforth.com (Stephen Pelc) - 2016-11-29 14:24 +0000
Re: Yet another language ( was Yet another draw of rectangle) john <anon@example.com> - 2016-11-29 21:27 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-11-29 18:15 -0800
Re: Yet another language ( was Yet another draw of rectangle) Alex <alex@rivadpm.com> - 2016-11-30 10:03 +0000
Re: Yet another language ( was Yet another draw of rectangle) hughaguilar96@gmail.com - 2016-12-01 16:14 -0800
Re: Yet another language ( was Yet another draw of rectangle) "Elizabeth D. Rather" <erather@forth.com> - 2016-11-29 12:22 -1000
Re: Yet another language ( was Yet another draw of rectangle) albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-29 14:31 +0100
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-02 23:05 +1100
Re: Yet another language ( was Yet another draw of rectangle) Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-12-03 01:58 -0500
Re: Yet another language ( was Yet another draw of rectangle) "HAA" <someone@microsoft.com> - 2016-12-03 22:00 +1100
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-23 10:11 +1100
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-23 00:01 -0800
Re: Yet another draw of rectangle albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-23 13:49 +0100
Re: Yet another draw of rectangle foxaudioresearch@gmail.com - 2016-11-23 10:51 -0800
Re: Yet another draw of rectangle "Elizabeth D. Rather" <erather@forth.com> - 2016-11-24 09:26 -1000
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-23 12:28 -0800
Re: Yet another draw of rectangle hughaguilar96@gmail.com - 2016-11-24 16:54 -0800
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-25 02:20 -0500
Re: Yet another draw of rectangle albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-11-25 10:39 +0100
Re: Yet another draw of rectangle Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-11-22 04:17 -0600
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-22 10:38 -0800
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-23 13:05 -0800
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-29 15:23 -0800
Re: Yet another draw of rectangle Ron Aaron <rambamist@gmail.com> - 2016-11-24 07:46 +0200
Re: Yet another draw of rectangle Paul Rubin <no.email@nospam.invalid> - 2016-11-23 21:59 -0800
Re: Yet another draw of rectangle Ron Aaron <rambamist@gmail.com> - 2016-11-24 08:12 +0200
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-23 22:22 -0500
Re: Yet another draw of rectangle humptydumpty <ouatubi@gmail.com> - 2016-11-23 21:14 -0800
Re: Yet another draw of rectangle rickman <gnuarm@gmail.com> - 2016-11-24 01:06 -0500
Re: Yet another draw of rectangle "HAA" <someone@microsoft.com> - 2016-11-25 11:56 +1100
Re: Yet another draw of rectangle hughaguilar96@gmail.com - 2016-11-19 23:14 -0800
Re: Yet another draw of rectangle hughaguilar96@gmail.com - 2016-11-24 18:11 -0800
Re: Yet another draw of rectangle luser droog <mijoryx@yahoo.com> - 2016-11-24 18:58 -0800
Re: Yet another draw of rectangle luser droog <mijoryx@yahoo.com> - 2016-11-24 20:01 -0800
Re: Yet another draw of rectangle Ilya Tarasov <ilya74.tarasov@gmail.com> - 2016-11-20 14:08 -0800
Re: Yet another draw of rectangle lehs <skydda.barnen@gmail.com> - 2017-04-11 06:41 -0700
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-12-01 08:58 -1000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <6JqdnfpQOeUh793FnZ2dnUU7-VvNnZ2d@supernews.com> |
| In reply to | #53006 |
On 11/30/16 7:02 PM, Ron Aaron wrote:
> On 30/11/2016 21:43, Elizabeth D. Rather wrote:
>> On 11/30/16 12:09 AM, Ron Aaron wrote:
>
>>> As you well know, I'm not an ANS Forth user, so my input on a standard
>>> ANS-compatible library would not be particularly useful.
>>
>> I'm merely pointing out the hypocrisy of decrying the lack of libraries
>> while making no efforts to contribute to one.
>
> "Hypocrisy", really?
>
> As Cecil pointed out in another reply, 8th has a lot of libraries and
> more are added with each release, whether because of user-requests or my
> own reasons.
>
> So better rethink the use of that term, it doesn't apply in any manner.
It isn't intended to apply to those who are actively working to provide
Forth libraries, but to those who complain about the lack of
standardized libraries and take no steps toward defining them.
>> Well, Forth2012 has:
>>
>> 6.2.0825 BUFFER: “buffer-colon” CORE EXT
>> ( u “hspacesiname” – – )
> ...
>> So that, at least, is standardized. It's a bit-wise array.
>
> If that is what an 'array' is in your mind, then I'm not sure what
> profit there is in further discussion on this topic. It's even named
> 'BUFFER:' -- to indicate that it holds a bunch of bytes. Yes, it
> *could* be used as an array. So could a simple CREATE 100 ALLOT.
>
> And while an 'array' of this nature is certainly simple to implement,
> one which accommodates increasing amounts of data is not. Nor is a
> "map" simple to implement correctly, let alone other common data structures.
>
> By all means, continue thinking that rolling your own array (or
> whatever) every single time you need one is a profitable use of your
> programmers' time and your money.
If you prefer a cell-wise array, Forth2012 provides this:
D.2.3 Addressing memory
A related problem is that of addressing an array of cells in an
arbitrary order. This standard provides a portable scaling operator
named CELLS. Given a number n, CELLS returns the number of address units
needed to hold n cells. Using CELLS, we can make a portable definition
of an ARRAY defining word:
: ARRAY ( u -- ) CREATE CELLS ALLOT
DOES> ( u -- addr ) SWAP CELLS + ;
Would it make you happy for the next release of the standard made this
definition of ARRAY required?
Clearly one of the first steps is for a number of Forth programmers and
system providers to agree on a definition of "array", because to many of
us, it's just a dedicated region of data storage that is index-able.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-01 16:44 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <f4ac177e-a7b2-4cd0-bb33-d0f1a9cdd7db@googlegroups.com> |
| In reply to | #53021 |
On Thursday, December 1, 2016 at 11:58:11 AM UTC-7, Elizabeth D. Rather wrote:
> On 11/30/16 7:02 PM, Ron Aaron wrote:
> >> Well, Forth2012 has:
> >>
> >> 6.2.0825 BUFFER: “buffer-colon” CORE EXT
> >> ( u “hspacesiname” – – )
> > ...
> >> So that, at least, is standardized. It's a bit-wise array.
> >
> > If that is what an 'array' is in your mind, then I'm not sure what
> > profit there is in further discussion on this topic. It's even named
> > 'BUFFER:' -- to indicate that it holds a bunch of bytes. Yes, it
> > *could* be used as an array. So could a simple CREATE 100 ALLOT.
> >
> > And while an 'array' of this nature is certainly simple to implement,
> > one which accommodates increasing amounts of data is not. Nor is a
> > "map" simple to implement correctly, let alone other common data structures.
BUFFER is useless. It doesn't do anything for you that
CREATE 100 ALLOT
doesn't do.
As for data-structures that accomodates increasing amounts of data, my novice package has: LIST.4TH and ASSOCIATION.4TH
> > By all means, continue thinking that rolling your own array (or
> > whatever) every single time you need one is a profitable use of your
> > programmers' time and your money.
>
> If you prefer a cell-wise array, Forth2012 provides this:
>
> D.2.3 Addressing memory
>
> A related problem is that of addressing an array of cells in an
> arbitrary order. This standard provides a portable scaling operator
> named CELLS. Given a number n, CELLS returns the number of address units
> needed to hold n cells. Using CELLS, we can make a portable definition
> of an ARRAY defining word:
>
> : ARRAY ( u -- ) CREATE CELLS ALLOT
> DOES> ( u -- addr ) SWAP CELLS + ;
>
> Would it make you happy for the next release of the standard made this
> definition of ARRAY required?
>
> Clearly one of the first steps is for a number of Forth programmers and
> system providers to agree on a definition of "array", because to many of
> us, it's just a dedicated region of data storage that is index-able.
Your ARRAY is copied directly out of "Starting Forth" --- all of the code that you have posted on comp.lang.forth has been copied directly out of "Starting Forth" --- every Forth programmer has read that book; the cartoons were cute; it was pretty light on technical information though.
What is the point of having an ARRAY definer that is limited to one dimension and is limited to cell-sized elements? That is not a general-purpose data-structure.
This has been discussed at length previously:
https://groups.google.com/forum/#!topic/comp.lang.forth/kH8lPSKdW30%5B26-50%5D
Here Andrew Haley wrote an array definer using CREATE DOES> that did allow any number of dimensions, but was restricted to cell-sized elements. I upgraded this so that it didn't use CREATE DOES> and hence was faster (because it doesn't have to fetch constant values out of memory at run-time, but compiles them as literals at compile-time) --- my upgrade also allows the elements to be any size, so you can have arrays of structs.
It is pointless to limit the users to only having cell-sized elements in the array. With my arrays, the user can have an array of pointers if that is what he needs, but can also have an array of structs --- the user is in full control --- a general-purpose data-structure should allow the user to get whatever he wants.
This is from the novice-package:
----------------------------------------------------------------------------
macro: [] ( adr index - element-adr )
cells + ;
macro: -> ( adr index -- element )
[] @ ;
: ,rows ( size 0 dims... -- size 0 dims... ) \ size is the size of the element; all elements get zero'd out
here locals| array dim | \ ARRAY is the adr and DIM is the largest dimension
dup if w else over then \ -- element-size \ all but the last level are pointers (size W)
dim * zallot
dup if
dim 0 do here array I [] ! dup >r recurse r> loop
then ;
\ Any alignment to the dictionary pointer should be done *before* ,ROWS is called.
\ This is in <ARY> prior to the DIMENSIONS.
\ This isn't necessary in ,ROWS prior to the RECURSE because we have only been compiling words.
\ Don't align the HERE at the beginning of ,ROWS as this has to be the same HERE that was obtained prior to calling ,ROWS.
: dimensions ( size 0 dims... size ) \ size is the size of the element
,rows
begin 0= until ; \ discard the dimensions and the zero terminator
: <ary> ( size 0 dims... name -- )
>r
non-zeros >r r@ 0 = abort" *** ARY needs some dimensions ***"
align here >r dimensions >r
r> r> r> r> { siz adr cnt name -- }
name get-current :name \ runtime: indices... -- element-adr
adr lit,
cnt 1 ?do swap, postpone -> loop
swap, siz lit*, +, ;,
c" <" name get-current :2name \ runtime: -- base-adr
adr lit, ;,
name c" >" get-current :2name \ runtime: adr index -- element-adr
siz lit*, +, ;,
;
: ary ( size 0 dims... -- )
bl word hstr dup >r <ary> r> dealloc ;
\ You can define a two-dimensional array of words in either of these ways:
\ W 0 3 5 C" TEST" <ARY>
\ W 0 3 5 ARY TEST
\ Assuming that I and J are indexes, an element can be accessed like this:
\ I J TEST \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the same order as the dimensions were.
\ It is also possible to access the element like this:
\ <TEST J -> I TEST> \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the opposite order as the dimensions were.
\ The [] only works for word-sized elements.
\ You should always use the xxx> word (even for words) because it takes into account the size of the element.
\ Arrays of dimensions other than two are defined the same --- you can have as many dimensions as you want.
\ <ARY> figures out how many dimensions there are by looking for the 0 under the non-zero dimensions.
\ This is a classic example of the problem with CREATE DOES> words being limited to *one* action per data type.
\ The CREATE DOES> version of the Iliff vectors relied on [] for resolving the final level, which had to be word elements.
\ There is no way to do this with CREATE DOES> because you can't have a type-specific version of [] (such as my xxx> word).
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-05 21:28 +1100 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o23fg2$1b9q$1@gioia.aioe.org> |
| In reply to | #53026 |
hughaguilar96@gmail.com wrote: > ... > Here Andrew Haley wrote an array definer using CREATE DOES> that did allow any number > of dimensions, but was restricted to cell-sized elements. I upgraded this so that it > didn't use CREATE DOES> and hence was faster (because it doesn't have to fetch constant > values out of memory at run-time, but compiles them as literals at compile-time) --- my > upgrade also allows the elements to be any size, so you can have arrays of structs. Fetching is relatively fast. It's the multiply used in simple multidim arrays that slows it down. An array that lays down pointers need only execute CELLS + @ for each index. Nothing comes free and memory is traded for speed. Each case on its merits.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-05 07:41 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <789f262c-a161-4f5d-9151-dc0a4f85e61c@googlegroups.com> |
| In reply to | #53080 |
On Monday, December 5, 2016 at 3:28:21 AM UTC-7, HAA wrote:
> hughaguilar96@gmail.com wrote:
> > ...
> > Here Andrew Haley wrote an array definer using CREATE DOES> that did allow any number
> > of dimensions, but was restricted to cell-sized elements. I upgraded this so that it
> > didn't use CREATE DOES> and hence was faster (because it doesn't have to fetch constant
> > values out of memory at run-time, but compiles them as literals at compile-time) --- my
> > upgrade also allows the elements to be any size, so you can have arrays of structs.
>
> Fetching is relatively fast. It's the multiply used in simple multidim arrays that slows
> it down. An array that lays down pointers need only execute CELLS + @ for each
> index. Nothing comes free and memory is traded for speed. Each case on its merits.
You don't know what you are talking about. This is my code from the novice package:
------------------------------------------------------------------------
macro: [] ( adr index - element-adr )
cells + ;
macro: -> ( adr index -- element )
[] @ ;
: ,rows ( size 0 dims... -- size 0 dims... ) \ size is the size of the element; all elements get zero'd out
here locals| array dim | \ ARRAY is the adr and DIM is the largest dimension
dup if w else over then \ -- element-size \ all but the last level are pointers (size W)
dim * zallot
dup if
dim 0 do here array I [] ! dup >r recurse r> loop
then ;
\ Any alignment to the dictionary pointer should be done *before* ,ROWS is called.
\ This is in <ARY> prior to the DIMENSIONS.
\ This isn't necessary in ,ROWS prior to the RECURSE because we have only been compiling words.
\ Don't align the HERE at the beginning of ,ROWS as this has to be the same HERE that was obtained prior to calling ,ROWS.
: dimensions ( size 0 dims... size ) \ size is the size of the element
,rows
begin 0= until ; \ discard the dimensions and the zero terminator
: <ary> ( size 0 dims... name -- )
>r
non-zeros >r r@ 0 = abort" *** ARY needs some dimensions ***"
align here >r dimensions >r
r> r> r> r> { siz adr cnt name -- }
name get-current :name \ runtime: indices... -- element-adr
adr lit,
cnt 1 ?do swap, postpone -> loop
swap, siz lit*, +, ;,
c" <" name get-current :2name \ runtime: -- base-adr
adr lit, ;,
name c" >" get-current :2name \ runtime: adr index -- element-adr
siz lit*, +, ;,
;
: ary ( size 0 dims... -- )
bl word hstr dup >r <ary> r> dealloc ;
\ You can define a two-dimensional array of words in either of these ways:
\ W 0 3 5 C" TEST" <ARY>
\ W 0 3 5 ARY TEST
\ Assuming that I and J are indexes, an element can be accessed like this:
\ I J TEST \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the same order as the dimensions were.
\ It is also possible to access the element like this:
\ <TEST J -> I TEST> \ this provides the element address, which you can @ or ! to.
\ In the above, I is in the range [0,3) and J is in the range [0,5). They are in the opposite order as the dimensions were.
\ The [] only works for word-sized elements.
\ You should always use the xxx> word (even for words) because it takes into account the size of the element.
\ Arrays of dimensions other than two are defined the same --- you can have as many dimensions as you want.
\ <ARY> figures out how many dimensions there are by looking for the 0 under the non-zero dimensions.
\ This is a classic example of the problem with CREATE DOES> words being limited to *one* action per data type.
\ The CREATE DOES> version of the Iliff vectors relied on [] for resolving the final level, which had to be word elements.
\ There is no way to do this with CREATE DOES> because you can't have a type-specific version of [] (such as my xxx> word).
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-06 18:13 +1100 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o25odl$ucj$1@gioia.aioe.org> |
| In reply to | #53083 |
hughaguilar96@gmail.com wrote:
> ...
> I think it was an honest mistake for HAA to assume that I'm multiplying --- that is how
> 1ARRAY 2ARRAY etc. work (although if the dimension is a power of two then it is just a
> shift because LIT*, optimizes internally) --- by ARY doesn't use multiply.
Perhaps you misread. The "multiply used in simple multidim arrays" was referencing
the CREATE DOES> arrays generally promoted by Forth. An example from
'Programming Forth':
: 2Array \ n1 n2 -- ; [child] n1 n2 -- addr ; 2-D array
Create \ create data word
Over , \ save width for run-time
cell * * \ calculate size
Here over erase \ clear memory
allot \ reserve n cells
Does> \ run time gives address of data
Dup @ Rot * Rot + 1+
cell *
+
;
Ignoring the CELL * in the run-time (use CELLS), it still leaves a multiply that needs
to be performed for each dimension in the array. Multidim arrays based on multiply
aren't always bad (I've used them myself) but they seem to be the only thing offered
when newbies ask 'Why doesn't Forth have arrays?'. Array run-time in other
languages I've seen go to length to avoid the multiply. It wouldn't hurt for Forth to
have more than CREATE DOES> up its sleeve when newbies come calling.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-12-05 21:36 -1000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <qomdnd__J8Qa99vFnZ2dnUU7-IfNnZ2d@supernews.com> |
| In reply to | #53103 |
On 12/5/16 9:13 PM, HAA wrote: > hughaguilar96@gmail.com wrote: >> ... >> I think it was an honest mistake for HAA to assume that I'm multiplying --- that is how >> 1ARRAY 2ARRAY etc. work (although if the dimension is a power of two then it is just a >> shift because LIT*, optimizes internally) --- by ARY doesn't use multiply. > > Perhaps you misread. The "multiply used in simple multidim arrays" was referencing > the CREATE DOES> arrays generally promoted by Forth. An example from > 'Programming Forth': > > : 2Array \ n1 n2 -- ; [child] n1 n2 -- addr ; 2-D array > Create \ create data word > Over , \ save width for run-time > cell * * \ calculate size > Here over erase \ clear memory > allot \ reserve n cells > Does> \ run time gives address of data > Dup @ Rot * Rot + 1+ > cell * > + > ; > > Ignoring the CELL * in the run-time (use CELLS), it still leaves a multiply that needs > to be performed for each dimension in the array. Multidim arrays based on multiply > aren't always bad (I've used them myself) but they seem to be the only thing offered > when newbies ask 'Why doesn't Forth have arrays?'. Array run-time in other > languages I've seen go to length to avoid the multiply. It wouldn't hurt for Forth to > have more than CREATE DOES> up its sleeve when newbies come calling. Fine. What did you have in mind? Got a spec? Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-06 00:05 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <30ecf8cc-dde1-48bd-bf4e-610492b9922c@googlegroups.com> |
| In reply to | #53104 |
On Tuesday, December 6, 2016 at 12:36:45 AM UTC-7, Elizabeth D. Rather wrote: > On 12/5/16 9:13 PM, HAA wrote: > > Multidim arrays based on multiply > > aren't always bad (I've used them myself) but they seem to be the only thing offered > > when newbies ask 'Why doesn't Forth have arrays?'. Array run-time in other > > languages I've seen go to length to avoid the multiply. It wouldn't hurt for Forth to > > have more than CREATE DOES> up its sleeve when newbies come calling. > > Fine. What did you have in mind? Got a spec? I already posted code for <ARY> and ARY --- I wrote that in 2010. I've written quite a lot of code, most of which will go into Straight Forth --- I can't contribute to FFL or any other code-library managed by Stephen Pelc --- that is why I'm now designing Straight Forth as my "spec."
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-08 10:09 +1100 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o2a522$3ik$1@gioia.aioe.org> |
| In reply to | #53104 |
Elizabeth D. Rather wrote: > On 12/5/16 9:13 PM, HAA wrote: > > hughaguilar96@gmail.com wrote: > >> ... > >> I think it was an honest mistake for HAA to assume that I'm multiplying --- that is > >> how 1ARRAY 2ARRAY etc. work (although if the dimension is a power of two then it is > >> just a shift because LIT*, optimizes internally) --- by ARY doesn't use multiply. > > > > Perhaps you misread. The "multiply used in simple multidim arrays" was referencing > > the CREATE DOES> arrays generally promoted by Forth. An example from > > 'Programming Forth': > > > > : 2Array \ n1 n2 -- ; [child] n1 n2 -- addr ; 2-D array > > Create \ create data word > > Over , \ save width for run-time > > cell * * \ calculate size > > Here over erase \ clear memory > > allot \ reserve n cells > > Does> \ run time gives address of data > > Dup @ Rot * Rot + 1+ > > cell * > > + > > ; > > > > Ignoring the CELL * in the run-time (use CELLS), it still leaves a multiply that needs > > to be performed for each dimension in the array. Multidim arrays based on multiply > > aren't always bad (I've used them myself) but they seem to be the only thing offered > > when newbies ask 'Why doesn't Forth have arrays?'. Array run-time in other > > languages I've seen go to length to avoid the multiply. It wouldn't hurt for Forth to > > have more than CREATE DOES> up its sleeve when newbies come calling. > > Fine. What did you have in mind? Got a spec? > > Cheers, > Elizabeth No spec but don't you think the topic of arrays in Forth has been underwhelming? We've touched on issues of speed and multidimension arrays. In every language but Forth a programmer knows how to create an array of any dimension. Here, if lucky, you're told how to build a two-dimension array. But what if you needed three or four? I'm in favor of Forth programmers working things out for themselves when there's gain to be had but for common things like this? Arrays-of-arrays offer speedup through simple shifts and fetches instead of multiply, or irregular shaped arrays, but would you know how to create them or where to find code? Simple one dimension arrays may be the basis of everything but unfortunately that's where the journey stops in Forth literature.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-12-07 15:27 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <87eg1j5ngg.fsf@nightsong.com> |
| In reply to | #53174 |
"HAA" <someone@microsoft.com> writes: > Here, if lucky, you're told how to build a two-dimension array. But > what if you needed three or four? Have you ever needed a 3 or 4 dimensional array in a Forth program?
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-08 04:22 -0600 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <gP2dnTjII-37qdTFnZ2dnUU78IPNnZ2d@supernews.com> |
| In reply to | #53176 |
Paul Rubin <no.email@nospam.invalid> wrote: > "HAA" <someone@microsoft.com> writes: >> Here, if lucky, you're told how to build a two-dimension array. But >> what if you needed three or four? > > Have you ever needed a 3 or 4 dimensional array in a Forth program? Indeed. The point is that if you find yourself needing a higher- dimensional array in any language it's likely to be a fairly special- purpose structure, may well be sparse, and it's possible that each row will not need to be the same length. So, you're not going to be using the language's own arrays anyway. It is possible that somebody somewhere really does want to fill 400 or so megabytes with a 100x100x100x100 array, but if they do then writing the code to handle that array is extremely unlikely to be a significant part of the cost of the application. The time it takes to write that code is well spent. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-08 17:05 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <6de88d4a-480b-4b17-8e80-e5f72d5f58b2@googlegroups.com> |
| In reply to | #53193 |
On Thursday, December 8, 2016 at 3:22:32 AM UTC-7, Andrew Haley wrote: > Paul Rubin <no.email@nospam.invalid> wrote: > > "HAA" <someone@microsoft.com> writes: > >> Here, if lucky, you're told how to build a two-dimension array. But > >> what if you needed three or four? > > > > Have you ever needed a 3 or 4 dimensional array in a Forth program? > > Indeed. The point is that if you find yourself needing a higher- > dimensional array in any language it's likely to be a fairly special- > purpose structure, may well be sparse, and it's possible that each row > will not need to be the same length. So, you're not going to be using > the language's own arrays anyway. It is possible that somebody > somewhere really does want to fill 400 or so megabytes with a > 100x100x100x100 array, but if they do then writing the code to handle > that array is extremely unlikely to be a significant part of the cost > of the application. The time it takes to write that code is well > spent. > > Andrew. My <ARY> and ARY don't require every dimension to be the same length. I'm not aware of any array definer that does require this. You are just parroting Elizabeth Rather's opinion (actually, obsession) that all data-structures have to be custom-written for the application --- this is nonsense --- custom coding an array definer for an application is not time well spent. One of the first programs I ever wrote in Forth needed a 6-dimensional array. This was pseudo-AI that I got from a book (most likely one of those TAB books) --- I ported the program from line-number BASIC over to HES-Forth on the Commodore Vic-20 and got a huge increase in speed --- implementing the array was a significant portion of the work involved. By pseudo-AI I mean that the array represented the game creatures' memory. Each dimension was one parameter in its environment, so each element in the array represented one situation that the creature could find itself in; the element contained either a zero (if this situation had never been encountered before) or a response that worked in the past. There were two kinds of creatures being simulated, which were predators and prey. Each kind had their own array. If a prey creature encountered a situation and lived through it, then all of its fellows would do the same thing in the future. If a predator encountered a situation and got a meal out of it, then all of its fellows would do the same thing in the future. Over time the predators and prey would learn at approximately the same rate, and so they would reach a balance in their populations --- sometimes the prey would learn faster though, and the predators would starve out before they could reproduce, and sometimes the predators would learn faster though, and the prey would get killed off before they could reproduce --- if either predator or prey went extinct, the other would soon go extinct too due to lack of food (the prey can't grow exponentially because the plants they eat are growing linearly). I was 18 when I wrote that program, which is quite a long time ago. Nowadays, most 18 year olds are not going to implement their own 6-dimensional array --- if the language doesn't have arrays, they will just switch to another language that does have arrays --- people expect programming languages to provide basic features needed for programming.
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-12-09 01:47 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <04225b7f-f354-40fb-811c-9369ea32a207@googlegroups.com> |
| In reply to | #53213 |
On Friday, 9 December 2016 01:05:39 UTC, hughag...@gmail.com wrote: > On Thursday, December 8, 2016 at 3:22:32 AM UTC-7, Andrew Haley wrote: > > Paul Rubin <no.email@nospam.invalid> wrote: > > > "HAA" <someone@microsoft.com> writes: > > >> Here, if lucky, you're told how to build a two-dimension array. But > > >> what if you needed three or four? > > > > > > Have you ever needed a 3 or 4 dimensional array in a Forth program? > > > > Indeed. The point is that if you find yourself needing a higher- > > dimensional array in any language it's likely to be a fairly special- > > purpose structure, may well be sparse, and it's possible that each row > > will not need to be the same length. So, you're not going to be using > > the language's own arrays anyway. It is possible that somebody > > somewhere really does want to fill 400 or so megabytes with a > > 100x100x100x100 array, but if they do then writing the code to handle > > that array is extremely unlikely to be a significant part of the cost > > of the application. The time it takes to write that code is well > > spent. > > > > Andrew. > > My <ARY> and ARY don't require every dimension to be the same length. I'm not aware of any array definer that does require this. > > You are just parroting Elizabeth Rather's opinion (actually, obsession) that all data-structures have to be custom-written for the application --- this is nonsense --- custom coding an array definer for an application is not time well spent. > > One of the first programs I ever wrote in Forth needed a 6-dimensional array. This was pseudo-AI that I got from a book (most likely one of those TAB books) --- I ported the program from line-number BASIC over to HES-Forth on the Commodore Vic-20 and got a huge increase in speed --- implementing the array was a significant portion of the work involved. > > By pseudo-AI I mean that the array represented the game creatures' memory. Each dimension was one parameter in its environment, so each element in the array represented one situation that the creature could find itself in; the element contained either a zero (if this situation had never been encountered before) or a response that worked in the past. There were two kinds of creatures being simulated, which were predators and prey. Each kind had their own array. If a prey creature encountered a situation and lived through it, then all of its fellows would do the same thing in the future. If a predator encountered a situation and got a meal out of it, then all of its fellows would do the same thing in the future. Over time the predators and prey would learn at approximately the same rate, and so they would reach a balance in their populations --- sometimes the prey would learn faster though, and the predators would starve out before they could reproduce, and sometimes the predators would learn faster though, and the prey would get killed off before they could reproduce --- if either predator or prey went extinct, the other would soon go extinct too due to lack of food (the prey can't grow exponentially because the plants they eat are growing linearly). > > I was 18 when I wrote that program, which is quite a long time ago. Nowadays, most 18 year olds are not going to implement their own 6-dimensional array --- if the language doesn't have arrays, they will just switch to another language that does have arrays --- people expect programming languages to provide basic features needed for programming. That sounds like great fun! I think it's time you did a new version in ANS using the Novice Pack. That would be great! M
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-12-09 04:01 -0600 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <MIadnQt_vZ-UHNfFnZ2dnUU78TudnZ2d@supernews.com> |
| In reply to | #53219 |
Mark Wills <markwills1970@gmail.com> wrote: > On Friday, 9 December 2016 01:05:39 UTC, hughag...@gmail.com wrote: >> > >> > Indeed. The point is that if you find yourself needing a higher- >> > dimensional array in any language it's likely to be a fairly special- >> > purpose structure, may well be sparse, and it's possible that each row >> > will not need to be the same length. So, you're not going to be using >> > the language's own arrays anyway. It is possible that somebody >> > somewhere really does want to fill 400 or so megabytes with a >> > 100x100x100x100 array, but if they do then writing the code to handle >> > that array is extremely unlikely to be a significant part of the cost >> > of the application. The time it takes to write that code is well >> > spent. >> >> My <ARY> and ARY don't require every dimension to be the same length. I didn't say each dimension, I said each *row*. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-09 06:49 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <2a8becab-0774-4128-993a-3c029a6dd54d@googlegroups.com> |
| In reply to | #53219 |
On Friday, December 9, 2016 at 2:47:52 AM UTC-7, Mark Wills wrote: > On Friday, 9 December 2016 01:05:39 UTC, hughag...@gmail.com wrote: > > On Thursday, December 8, 2016 at 3:22:32 AM UTC-7, Andrew Haley wrote: > > > Paul Rubin <no.email@nospam.invalid> wrote: > > > > "HAA" <someone@microsoft.com> writes: > > > >> Here, if lucky, you're told how to build a two-dimension array. But > > > >> what if you needed three or four? > > > > > > > > Have you ever needed a 3 or 4 dimensional array in a Forth program? > > > > > > Indeed. The point is that if you find yourself needing a higher- > > > dimensional array in any language it's likely to be a fairly special- > > > purpose structure, may well be sparse, and it's possible that each row > > > will not need to be the same length. So, you're not going to be using > > > the language's own arrays anyway. It is possible that somebody > > > somewhere really does want to fill 400 or so megabytes with a > > > 100x100x100x100 array, but if they do then writing the code to handle > > > that array is extremely unlikely to be a significant part of the cost > > > of the application. The time it takes to write that code is well > > > spent. > > > > > > Andrew. > > > > My <ARY> and ARY don't require every dimension to be the same length. I'm not aware of any array definer that does require this. > > > > You are just parroting Elizabeth Rather's opinion (actually, obsession) that all data-structures have to be custom-written for the application --- this is nonsense --- custom coding an array definer for an application is not time well spent. > > > > One of the first programs I ever wrote in Forth needed a 6-dimensional array. This was pseudo-AI that I got from a book (most likely one of those TAB books) --- I ported the program from line-number BASIC over to HES-Forth on the Commodore Vic-20 and got a huge increase in speed --- implementing the array was a significant portion of the work involved. > > > > By pseudo-AI I mean that the array represented the game creatures' memory. Each dimension was one parameter in its environment, so each element in the array represented one situation that the creature could find itself in; the element contained either a zero (if this situation had never been encountered before) or a response that worked in the past. There were two kinds of creatures being simulated, which were predators and prey. Each kind had their own array. If a prey creature encountered a situation and lived through it, then all of its fellows would do the same thing in the future. If a predator encountered a situation and got a meal out of it, then all of its fellows would do the same thing in the future. Over time the predators and prey would learn at approximately the same rate, and so they would reach a balance in their populations --- sometimes the prey would learn faster though, and the predators would starve out before they could reproduce, and sometimes the predators would learn faster though, and the prey would get killed off before they could reproduce --- if either predator or prey went extinct, the other would soon go extinct too due to lack of food (the prey can't grow exponentially because the plants they eat are growing linearly). > > > > I was 18 when I wrote that program, which is quite a long time ago. Nowadays, most 18 year olds are not going to implement their own 6-dimensional array --- if the language doesn't have arrays, they will just switch to another language that does have arrays --- people expect programming languages to provide basic features needed for programming. > > That sounds like great fun! I think it's time you did a new version in ANS > using the Novice Pack. That would be great! > > M Computer programming really was fun when I was 18 --- it still is fun for me. Maybe I will write some fun programs like that and add them to the novice package --- realistically though, there are no Forth programmers under the age of 40, and only a handful under the age of 50 --- with a few exceptions, people become quite boring and ossified at that age. :-( The predator/prey program was somewhat fun, but it would mostly just be interesting as a screen saver (watch the predators chase the prey around on the screen). After I gave up on the Vic-20 and upgraded to a C64, I wrote another program. This was turtle-graphics in a 6-dimensional universe. There were 6 spatial dimensions: U V W X Y Z. The program generated an image that was a 3-dimensional projection of the object drawn (somewhat like a shadow is a 2-dimensional projetion of a 3-dimensional object). I figured out perspective (that was actually the hard part) so the lines would be angled toward a vanishing point on the "horizon" (there is no actual horizon in outer space though). The user could move his turtle around the object and view it from different angles, not necessarily from the X Y Z world that we are familiar with. That program was actually the most fun program I've ever written. This was in SuperForth. Unfortunately, it was rather computation heavy and it ran too slow on the C64. If I were to write a fun program nowadays, it would be that one (except downgraded to 4 spatial dimensions) --- on our modern computers it would be fast enough to be fun to experiment with --- with a big desktop computer it would be possible to simulate an entire planet (a small planet, such as Mercury or Pluto). Each point being, lets say, a 10-mile cube of some material such as iron, with density and heat. The planet would be a 4-dimensional object complete with gravity and rotation in the 3-dimensional plane. That would be pretty fun! I think that reality does have at least 4 spatial dimensions --- a planet such as Earth actually exists in hyperspace and what we see is only a 3-dimensional projection of this hyperspace object. I'm still fascinated by the concept of hyperspace. Just two days ago I was at the Goodwill store and I found a book for only $3.49 called: "Hyperspace: A Scientific Odyssey Through Parallel Universes, Time Warps, and the 10th Dimension" (Michio Kaku). What a find! Of course I bought it! Right now I'm reading it voraciously --- I got distracted a little bit with that MergeSort nonsense --- but mostly right now what I'm focusing my mind on is reading that book and thinking about hyperspace. I have said before that Straight Forth's "killer app" would be CAM, which involves generating gcode for CNC machines. I also want to resurrect my hyperspace turtle though! Also, I've been thinking that a new approach to CAM would be to use turtle graphics (limited to 3-dimensions, of course) --- I don't think anybody has ever done that before --- it might be easier for the user though. All of this fun programing will have to wait until Straight Forth is up and running --- I'm not going to waste time programing in ANS-Forth --- I don't want to turn into another Andrew Haley: a buffoon who goes around telling people that they are jealous of him (all ANS-Forth programmers are like that).
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-10 10:15 +1100 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o2fe05$2hi$3@gioia.aioe.org> |
| In reply to | #53176 |
Paul Rubin wrote: > "HAA" <someone@microsoft.com> writes: > > Here, if lucky, you're told how to build a two-dimension array. But > > what if you needed three or four? > > Have you ever needed a 3 or 4 dimensional array in a Forth program? Why would Forth's needs be any different? Multidim arrays are used because they conveniently express a situation. I don't recall when I've personally needed them (not the type of program I usually write) but I've certainly translated programs that used them. That's what started me on this :)
[toc] | [prev] | [next] | [standalone]
| From | josv@planet.nl |
|---|---|
| Date | 2017-04-12 04:47 -0700 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <e96879fa-6e11-4ecb-9471-b1d1691377e9@googlegroups.com> |
| In reply to | #53176 |
Hi, Yes, See: http://bit.ly/2oorBMZ Jos On 8 december 2016 00:28:00 UTC+1 Paul Rubin wrote: > "HAA" <so...rosoft.com> writes: > > Here, if lucky, you're told how to build a two-dimension array. But > > what if you needed three or four? > > Have you ever needed a 3 or 4 dimensional array in a Forth program?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-12-07 14:34 -1000 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o4CdndKpGvofN9XFnZ2dnUU7-KHNnZ2d@supernews.com> |
| In reply to | #53174 |
On 12/7/16 1:09 PM, HAA wrote: > Elizabeth D. Rather wrote: >> On 12/5/16 9:13 PM, HAA wrote: >>> hughaguilar96@gmail.com wrote: >>>> ... >>>> I think it was an honest mistake for HAA to assume that I'm multiplying --- that is >>>> how 1ARRAY 2ARRAY etc. work (although if the dimension is a power of two then it is >>>> just a shift because LIT*, optimizes internally) --- by ARY doesn't use multiply. >>> >>> Perhaps you misread. The "multiply used in simple multidim arrays" was referencing >>> the CREATE DOES> arrays generally promoted by Forth. An example from >>> 'Programming Forth': >>> >>> : 2Array \ n1 n2 -- ; [child] n1 n2 -- addr ; 2-D array >>> Create \ create data word >>> Over , \ save width for run-time >>> cell * * \ calculate size >>> Here over erase \ clear memory >>> allot \ reserve n cells >>> Does> \ run time gives address of data >>> Dup @ Rot * Rot + 1+ >>> cell * >>> + >>> ; >>> >>> Ignoring the CELL * in the run-time (use CELLS), it still leaves a multiply that needs >>> to be performed for each dimension in the array. Multidim arrays based on multiply >>> aren't always bad (I've used them myself) but they seem to be the only thing offered >>> when newbies ask 'Why doesn't Forth have arrays?'. Array run-time in other >>> languages I've seen go to length to avoid the multiply. It wouldn't hurt for Forth to >>> have more than CREATE DOES> up its sleeve when newbies come calling. >> >> Fine. What did you have in mind? Got a spec? >> >> Cheers, >> Elizabeth > > No spec but don't you think the topic of arrays in Forth has been underwhelming? > We've touched on issues of speed and multidimension arrays. In every language > but Forth a programmer knows how to create an array of any dimension. Here, > if lucky, you're told how to build a two-dimension array. But what if you needed > three or four? I'm in favor of Forth programmers working things out for themselves > when there's gain to be had but for common things like this? Arrays-of-arrays > offer speedup through simple shifts and fetches instead of multiply, or irregular > shaped arrays, but would you know how to create them or where to find code? > Simple one dimension arrays may be the basis of everything but unfortunately > that's where the journey stops in Forth literature. Every Forth programmer I know knows how to create an array of any dimension. My beginning Forth class includes that as an exercise, and a 2-D array is included as an exercise in Forth Application Techniques (for which there's an answer sheet available). The "gain to be had" by a DIY approach is that you get exactly the features you want and need, with no overhead for things you don't need. Perhaps what we need is more examples posted on a repository such as Stephen's. Will you contribute? Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-07 18:39 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <ad630317-f90a-4bc5-a1ed-fb7c9555cdbe@googlegroups.com> |
| In reply to | #53178 |
On Wednesday, December 7, 2016 at 5:34:16 PM UTC-7, Elizabeth D. Rather wrote: > On 12/7/16 1:09 PM, HAA wrote: > > Elizabeth D. Rather wrote: > >> On 12/5/16 9:13 PM, HAA wrote: > >>> hughaguilar96@gmail.com wrote: > >>>> ... > >>>> I think it was an honest mistake for HAA to assume that I'm multiplying --- that is > >>>> how 1ARRAY 2ARRAY etc. work (although if the dimension is a power of two then it is > >>>> just a shift because LIT*, optimizes internally) --- by ARY doesn't use multiply. > >>> > >>> Perhaps you misread. The "multiply used in simple multidim arrays" was referencing > >>> the CREATE DOES> arrays generally promoted by Forth. An example from > >>> 'Programming Forth': > >>> > >>> : 2Array \ n1 n2 -- ; [child] n1 n2 -- addr ; 2-D array > >>> Create \ create data word > >>> Over , \ save width for run-time > >>> cell * * \ calculate size > >>> Here over erase \ clear memory > >>> allot \ reserve n cells > >>> Does> \ run time gives address of data > >>> Dup @ Rot * Rot + 1+ > >>> cell * > >>> + > >>> ; > >>> > >>> Ignoring the CELL * in the run-time (use CELLS), it still leaves a multiply that needs > >>> to be performed for each dimension in the array. Multidim arrays based on multiply > >>> aren't always bad (I've used them myself) but they seem to be the only thing offered > >>> when newbies ask 'Why doesn't Forth have arrays?'. Array run-time in other > >>> languages I've seen go to length to avoid the multiply. It wouldn't hurt for Forth to > >>> have more than CREATE DOES> up its sleeve when newbies come calling. > >> > >> Fine. What did you have in mind? Got a spec? > >> > >> Cheers, > >> Elizabeth > > > > No spec but don't you think the topic of arrays in Forth has been underwhelming? > > We've touched on issues of speed and multidimension arrays. In every language > > but Forth a programmer knows how to create an array of any dimension. Here, > > if lucky, you're told how to build a two-dimension array. But what if you needed > > three or four? I'm in favor of Forth programmers working things out for themselves > > when there's gain to be had but for common things like this? Arrays-of-arrays > > offer speedup through simple shifts and fetches instead of multiply, or irregular > > shaped arrays, but would you know how to create them or where to find code? > > Simple one dimension arrays may be the basis of everything but unfortunately > > that's where the journey stops in Forth literature. > > Every Forth programmer I know knows how to create an array of any > dimension. My beginning Forth class includes that as an exercise, and a > 2-D array is included as an exercise in Forth Application Techniques > (for which there's an answer sheet available). The "gain to be had" by a > DIY approach is that you get exactly the features you want and need, > with no overhead for things you don't need. > > Perhaps what we need is more examples posted on a repository such as > Stephen's. Will you contribute? You will contribute an example of a 2D array of cells, which you apparently know how to implement because you teach it in your class (IIRC, this was an example code snippet from the Starting Forth" book). Another noble soul will contribute an example of a 2D array of floats, which would require different code. Then another noble soul will contribute a 2D array of structs which are size 16, which would require different code. Etc. etc.. But we still haven't begun with 3D arrays, so we will need examples of those too. Pretty soon Stephen's repository will have dozens of examples of array definers of different dimensions with different sized elements. If the Forth student can find an example with the same number of dimensions and same sized elements as the array that he needs, then he can "get exactly the features he wants and needs, with no overhead for things he doesn't need." Otherwise though, he will have to do cut-and-paste-and-tweak of one of the code in one of the examples that is close to what he needs --- this of course is error-prone, and a waste of time, and it bloats out his application program's source-code with low-level code (an array definer is pretty low-level) mixed together with the high-level application code that he is writing. I'm sure our student is going to be very impressed! He will be anxious to begin work on another application program that needs an array, so he can begin searching the repository for another solution that allows him to "get exactly the features he wants and needs, with no overhead for things he doesn't need." If the student is a noble soul himself, then he will contribute his own unique array definer that he just wrote to Stephen's repository, so now the repository has yet one more entry --- this is how Stephen's repository grows over the years, and as it grows it becomes increasingly difficult to find any particular array definer because the repository doesn't have an index. The only noble soul who can't contribute an array definer would be myself with my <ARY> and ARY that, by itself, will anybody (any number of dimensions and any size element) to "get exactly the features he wants and needs, with no overhead for things he doesn't need."
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-12-10 09:38 +1100 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <o2fdvv$2hi$1@gioia.aioe.org> |
| In reply to | #53178 |
Elizabeth D. Rather wrote: > ... > Every Forth programmer I know knows how to create an array of any > dimension. Reading the c.l.f. comments it's not clear to me they do :) > My beginning Forth class includes that as an exercise, and a > 2-D array is included as an exercise in Forth Application Techniques > (for which there's an answer sheet available). The "gain to be had" by a > DIY approach is that you get exactly the features you want and need, > with no overhead for things you don't need. > > Perhaps what we need is more examples posted on a repository such as > Stephen's. Will you contribute? > > Cheers, > Elizabeth Something on those lines. In the meantime mlg's article in FD 18/4 may be of interest.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-12-09 16:25 -0800 |
| Subject | Re: Yet another language ( was Yet another draw of rectangle) |
| Message-ID | <9e3349e4-01d1-497e-81d2-074c07a0a4cc@googlegroups.com> |
| In reply to | #53178 |
On Wednesday, December 7, 2016 at 5:34:16 PM UTC-7, Elizabeth D. Rather wrote: > Every Forth programmer I know knows how to create an array of any > dimension. Andrew Haley doesn' know how to implement a multi-dimensional array that allows the elements to be any size --- his effort forces the elements to be cell-sized --- by comparison, my <ARY> and ARY support multi-dimensional arrays with the elements of any size. It is obvious to me that you appoint the Forth-200x members based on their loyalty to you --- programming skill is irrelevent to you (because you don't have any programming skill either) --- it is really pathetic that in the year 2016 ANS-Forth still lacks a general-purpose array definer (other than my <ARY> and ARY that you reject). Andrew Haley now says that I'm jealous of his awesome programming skill. That was really the stupidest thing that anybody has ever said on c.l.f. --- you really picked a winner there! LOL Anyway, it is a gross violation of the Forth-200x rules that we have employees on the committee. Andrew Haley is your employee, Peter Knaggs is Stephen Pelc's employee, etc. (maybe next you can appoint Barto Gillespie to the committee too). Forth-200x is astro-turf --- a corporate project faked up to appear to be a grassroots project. ANS-Forth has been a total failure --- this is your fault, personally --- this was really the most retarded language design since COBOL (which is not surprising, considering that your only programming experience was in COBOL). This is how you describe yourself on your website: ----------------------------------------------------------------------------------- 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. ----------------------------------------------------------------------------------- So, who else are we to blame for ANS-Forth's failure?
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web