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 The
NoteComputer  | |
Feedback : bob@cosy.com
NB : I reserve the right to post all communications I receive or generate to CoSy website for further reflection .
BobA-In-Y2K.org