Modified | DDT |>| FRI.FEB,010216,20:47-4 | CoSy/Home ; CoSy/Current         ?Wha?  CoSy Comment Comments         BobA-In-Y2K.org © Bob Armstrong .

CoSy/Language/Booleans971222
Continued from CoSy/Language/Booleans
Tru Bools APL vs FORTH . Was : Re: STSC "Boolean techniques" booklet?
  Best read in fixed width font :
  ============================: TUE.DEC,971216 :============================
 Sorry I`m on a more or less weekly cycle responding to these posts .

 I`d like to keep all this thread visable on both news groups .
 Anton Ertl`s challenge really gets things interesting .

>    From: Olivier Lefevre  Mon 13:50
> You are confused about K. As has been pointed out many times in this
> forum, K doesn't have true arrays: only lists (and list of lists etc).
> That makes a big difference.           -- O.L.

 Vectors ( not to be confused with LISPs Lists ) of Vectors are
 the generic data structure .
 Whether rectangular arrays are worth special casing is a parochial issue .

  -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -

>    From:      wtanksle@sdcc10.ucsd.edu (William Tanksley)    97/12/15 18:45
> Subject:      Re: STSC "Boolean techniques" booklet?
>
>In article <34954ADD.A2A7071D@cosy.com> bob@cosy.com writes:
>
>>  Let me deal with some of the responses in a pedagogical  order :
>  More didactic than pedagogical, I would hope :).
>
>> I figured if I rubbed the 2 languages together I might generate a little
>> light .
> I think you will -- I'm enjoying the warmth, at least.  :)
>
>>   (Reuben Thomas) writes :
>>> I think it's easier to make a case for APL being fundamentally doomed to
>>> inefficiency by having arrays as a basic type, without having sufficiently
>>> strong datatyping to regain efficiency.
>> Rubbish . I`ll leave it to others on the ArrayPL side to affirm that this
>> is just plain wrong .
> Although I agree with you I have trouble with your willingness to flame.
> Moderate your tone or be killfiled in spite of your important contributions.
 I apologize , I didn`t need to reflect the R- word .

> On another topic, you're right.  APL does not lose efficiency by using
> vector operations.  I'm baffled by the idea that type checking would
> somehow improve speed :).
>
>> Arthur Whitney after demonstrating almost instant
>> operations on 10+8 ( 10E8 ) record data bases ( on Suns ) , replied to the
>> question of efficiency relative to C that you might match K if you had
>> perfect C programmers .
> K is like 0: nobody I've ever talked to has given me any useful info.  I'd
> love to know about either language.  And "almost instant" isn't even close
> to useful.
 AlanGraham spent the weekend at PeckSlip after his BigAPL talk . We have
 remarkably similar views on language , tho I pounded on him the necessity of
 whitespace as the fundamental delimiter .

>> and the many tentative unfocused reinventions of the truths of APL I have
>> seen around the FORTH community .
> I'd love to see some examples of these, and even more I'd love to see some
> focussing of them.  I agree that APL has much to show Forth, and vice
> versa.
 Julian Noble`s work recapitulates much of the ontogeny of APL .

>>> Forth defines TRUE as all bits set, not -1.
>> Yep , but it`s been a long time since I worked on a 1s complement machine
> The distinction is critical when dealing with logical bitmaps -- if you
> KNOW that TRUE is all bits set you can deal with 32 bits at a time
> without branching, whereas if you don't know that (if you only know that
> it's -1, and haven't thought that through) you can't.
 I`ll never try to be cute again .

>>> ( 0 or TRUE ) 5  AND
>> Returns 5 or 0 . Thanks for giving me the rational . I`m not arguing that
>> having " all 1s " around as a constant isn`t useful ( I think that must be
>> TEAM_DOLPHIN `s point ) , even that this scalar vocabulary isn`t useful ,
>> but the mindset it induces must be exceeded .
> I had to read this several times before I figured out what you meant.
> First of all, Sam is the leader of Team Dolphin, a project to produce and
> market a common-sense general purpose operating system with advanced
> technology and careful design.  (BOY, I'm good at getting those plugs in,
> aren't I?)  Anyhow, his name isn't TEAM_DOLPHIN.  :)
 Sam? didn`t mention his name .

> Second, the point isn't that there's a constant somewhere with all ones
> -- I could generate such a constant with a simple while loop.
 Huh , can`t you just say  -1  ? or to define it :
  |(  1 negate constant -1  )| . ( note : you can`t in J or APL , you have
 to type  _1 or "1  or some such because they don`t respect whitespace . )

> The point is that all the logical operations return either all ones or
> all zeros. This is VERY much in line with the APL notion of vector
> processing: essentially, every return from every boolean operation is a
> 32-element array rather than a scalar.
 This gets to the crux .  FORTH runs out of steam at  1 CELL .
 The number of characters in this |(|  JOB |>|
  CoSy/Language/Booleans971222  |)| is  |(|  shape MV TEXT |>| 15066  |)|
 That`s  |(| ceiling r % 32  |>| 471  |)|  Win32Forth CELLs .

> There's a dyadic APL operator which selects all the elements in an array
> based upon whether the corresponding element in another array is true or
> false.  It's rather like Lisp's reduce function.
 In APL : |(|  Bool / V  |  ( shape Bool ) match  shape V  |)| where the
 elements of V may be bits , characters , numbers , or Vectors .

> This is Forth:
> [32 bits of logical flags] [one scalar logical operation] AND   TOS !
 Sorry , I don`t get it . My FORTH is minimal . What are you doing with
  TOS ?  What is being selected ?

> This is almost the same thing in APL (except that the APL is more flexible
> and slower, of course):
> TOS {assign} ([one scalar logical operation]) {reduce} (any
> number of flags)
> Of course, for fairness I'm not using either language's combinators
> properly -- in Forth I should use the stack, and in APL I should use the
> line.
 Sorry , you lost me .

> P.S. Dolphin will be built for Unicode, and will support UTF-8 from the
> ground up.

>>> "all bits set" in a one-bit-long quantity is TRUE by the Forth definition.
>> Exactly . but a "cell" in , eg : Win32Forth ,  is a word  is 32 bits .
>> 1 bit suffices for the logic , the other 31 should be available for the
>> next 31 dimensions of the problem . And you need words for general use
>> which extend to arbitrary length objects .
> We could use those words, BUT the problem is that they don't fit the field
> of Forth.  I'd like to have them in my Forth, but I wouldn't want to
> require them for any other Forths -- especially since Forth can already do
> a limited version of that in FAR less space and time.
 I`m not interested in  YAFORTH or YAAPL .  I want language which is
 coherent , well factored , and efficient for both the human and the silicon
 at all scales .
 To be practical for an ordinary Manhattanite , it must express things at
 the APL level of generality .
 To be real , its roots must tikle the bits ( legs ) of the chip ( toggle
 the registers of the processor ) .

>>   "ElizabethD.Rather" writes :
>>> We have frequently used defining words to name individual bits to be used
>>> as flags, a technique that this convention enables.
>> Have you created any vocabulary which extends to arbitary length vectors
>> so you can efficiently do the equivalent of  | + / Space = TEXT |  to
>> count the number of words in what you are writing ?
>> In APL , Larry Breed solved these problems in the `60s -- and they
>> have been optimized long since .
> You've only named one problem -- I hardly see the need to switch languages
> or write language extensions so that I can count in my source code.  :-)
 I want to do all sorts of things , any old time .
 Sometimes I want to know , e.g. , the numbers of word in this web page I`m
 mirroring this on :  |(|  1 + + / SP = DRB SP MV TEXT |>| 2930  |)|

> Seriously, though, Forth isn't built for that sort of thing.  APL is.
> This makes Forth more efficient than APL for Forth's field.  Forth doesn't
> do a good job at trying to be APL.  Believe me, APL would do a poor job at
> trying to be Forth (grin -- this brings to mind Chuck's 6-bit character
> set).
 From CoSy`s perspective , FORTH`s use is to be a foundation for an APL .

> -Billy
> Interests: Dolphin, Forth, learning J (sorry, APL folks -- I just can't
> learn APL.  J is easy to learn)
 How can you stand (
       J`s throwing away half the visual bandwidth with all those single and
        double dots )
       compared to  FORTH`s freedom to create any nonblank name  ?

  -    -    -    -    -    -    -    -    -    -    -    -    -    -    -

>       From: anton@mips.complang.tuwien.ac.at (Anton Ertl) 10:23
>    Subject: Re: STSC "Boolean techniques" booklet?
> Newsgroups: comp.lang.apl, comp.lang.forth
>In article <34954ADD.A2A7071D@cosy.com>, Bob Armstrong 
> writes:
>>   In article <348D7030.21B2963@cosy.com>  I ( bob@cosy.com ) wrote:
>> Have you created any vocabulary which extends to arbitary length vectors so
>> you can efficiently do the equivalent of | + / Space = TEXT |  to count the
>> number of words in what you are writing ?
> Counting the number of spaces is something different from counting the
> number of words.

 A more exact statement of the counting of words is :
  |(    { 1 + +/ SP = DRB w } TEXT                                  )|
 Where  DeleteRedudantBlanks  may be defined as :
  |(    { ( T0 or 1 rotate T0 > <\ T0 is w ne SP) / w }             )|
  from RexfordSmith , QuoteQuad 10 1 19 ; circa 1983 .
 ( In CoSy , showing the influence of FORTH , I can write the above as :
  |(      ( P or 1 rotate T > <\ D w ne SP ) / w                    )|

> Anyway, a Forth program for counting spaces may not be as elegant, but
> efficiency is another thing, and one that can be measured. So I
> challenge you to give me some input text, a reference machine, and a
> timing of the code above for your favourite APL implementation, and I
> will measure how Forth fares.
> The machines I have available are i486 @ 66MHz, R3000 @ 25MHz, an
> R4000 @ 100MHz, R10000 @ 195MHz , 21064A @ 300MHz, 21164A @ 600MHz,
> SPARC ELC. It would make comparison easier if your reference machine
> was comparable to one of those.
> - anton
>--
> M. Anton Ertl                Some things have to be seen to be believed
> anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
> http://www.complang.tuwien.ac.at/anton/home.html

 Great challenge !  Does anyone in the APL community have time to respond ?
 It would be nice to get a few points of time versus lenth of TEXT .

  -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
>     From:      Jonah Thomas        Tue 12:34
>  Subject:      Re: STSC "Boolean techniques" booklet?
> In article <6766da$b6e@news.tuwien.ac.at>,
>         anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> >In article <34954ADD.A2A7071D@cosy.com>, Bob Armstrong 
> writes:
> >>    In article <348D7030.21B2963@cosy.com>  I ( bob@cosy.com ) wrote:
> >>  Have you created any vocabulary which extends to arbitary length
> >> vectors so you can efficiently do the equivalent of  | + / Space = TEXT |
> >> to count the number of words in what you are writing ?
> >Anyway, a Forth program for counting spaces may not be as elegant, but
> >efficiency is another thing, and one that can be measured. So I
> >challenge you to give me some input text, a reference machine, and a
> >timing of the code above for your favourite APL implementation, and I
> >will measure how Forth fares.
>
> Let's not go by what we can measure, just because we can measure it.  I'm
> guessing that for this particular problem, in most of the contexts where
> it might be used with APL, timing will be irrelevant.  And for the ones
 Yes . Timing IS irrelevant . On this text , its  almost instantanious  .

> where timing isn't irrelevant, where the user has to wait more than 1/20
> of a second, disk access will swamp other efficiencies.  If your Forth
> gives more efficient disk access than his APL that can be very important,
> but it doesn't have a lot to do with Forth or APL or programming.
> We have traditionally argued the elegance and sheer programmability of
> Forth relative to, say, C, claiming that this overshadows C's typically
> faster speed on benchmarks.  Compare the best C compiler to an average
> Forth, and the C program will run faster than the same algorithm in
> Forth, but the Forth programmer is faster and also faster to find a
> better algorithm.
> Now Bob is proposing that for some set of problems APL is more Forthlike
> than Forth.  The obvious implications are:
> 1.  Find out how to link Forth and APL so we can use APL for the problems
> it solves well.
 I`m looking to create 1 language informed by both traditions .

> 2.  Notice the particular elegances of APL and build Forth add-ons that
> achieve similar results.
> 3.  Check whether there might be a market for an APL written in Forth.
 My concern here is the simplification and optimization of the foundations of
 FORTH by incorporating the insights of APL creating a single thing to learn .

> Probably most of the APL primitives would still be primitives.  If
> there's a PD APL those might just be used as is.  It should be simple to
> build an APL parser in Forth.  Then APL programmers could get everything
> they're used to, and could also use Forth for all the things APL doesn't
> give them.
> Any of these would be more useful than arguing which is better for simple
> benchmarks.  Though it might be interesting to look at which problem
> domains are better solved by Forth or APL, and for which it's a toss-up.
> Ideally we'd look at:
> 1.  Total cost of production
> 2.  Cost of maintenance
> 3.  Time required for production
> 4.  Time required to implement user-suggested modifications
> 5.  Speed of product
> 6.  Size of product
> And I have the sense I left out some, what did I miss?
  -     -     -     -     -     -     -     -     -     -     -     -     -

>     From:        anton@mips.complang.tuwien.ac.at (Anton Ertl)     Wed 10:15
>  Subject:        Re: STSC "Boolean techniques" booklet?
> In article <676dp1$g00@dfw-ixnews11.ix.netcom.com>, Jonah Thomas
>  writes:
>> In article <6766da$b6e@news.tuwien.ac.at>,
>>       anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> >Anyway, a Forth program for counting spaces may not be as elegant, but
>> >efficiency is another thing, and one that can be measured. So I
>> >challenge you to give me some input text, a reference machine, and a
>> >timing of the code above for your favourite APL implementation, and I
>> >will measure how Forth fares.
>>
>> Let's not go by what we can measure, just because we can measure it.

> The original flame bait (Message-ID: <348D7030.21B2963@cosy.com>) made
> claims about efficiency, that's why I proposed measuring efficiency.

> > 2.  Notice the particular elegances of APL and build Forth add-ons that
> > achieve similar results.

> One interesting aspect of Forth is that you can build a map/reduce
> definition that takes xts with a whole range of stack effects. E.g., a
> plain map-vector would have the following stack effect:
>
> map-vector ( ... addr u xt -- ... )
>  where both "..."s are equally deep and xt has the following stack
>  effect:
>
> ( ... w -- ... )
>
> E.g., you could use
>
> ['] . map-vector
>
> to print every element of the vector
>
> 0 rot rot ['] + map-vector ( n )             | 'map-' added by BobA
>
> to add up all elements in the vector etc.
>
> - anton
> M. Anton Ertl                    Some things have to be seen to be believed
> anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
> http://www.complang.tuwien.ac.at/anton/home.html

 Pretty , informative .  But getting off the issue of efficient Booleans .

 I get your general idea even tho I can`t interpret the whole consistantly .
 I would see the general form of an APL operator ( taking 1 function ) being
  : map-vector  ( a0 a1 xt  --  a3 )  ... ;
 where the length and other attributes are essentially queried by
 map-vector .

 Incedentally , having different vocabularies for interactive mode versus
 compulation , e.g. :  [']  versus  '  ,  has got to go .

-- BobA--   http://CoSy.com

 CoSy NoteComputing Environment & Language ;
CoSy The
NoteComputer
 Current , WallSt , MotorBoard , Art
Feedback :
bob@cosy.com
NB : I reserve the right to post all communications I receive or generate to CoSy website for further reflection .