• 4th.CoSy
  • Planetary Temperature
  • CoSy/Life ; CoSy/Liberty
  • Forum 
  •  FaceBook ; Twitter

  • Bob Armstrong
    Please let me know by return mail if you want to be removed from my mail list .

    I trust you and yours are having
    a copacetic and productive
    solstice correlated holiday month

     See my Newsletter 201410 for my progress this year
     working towards restoring the classic quantitative analytical method of physics
    to the understanding of planetary temperature and climate including particularly
    my presentation of The Basic Basics at the Heartland Institute's Las Vagas Climate Conference

    This letter is almost exclusively about progress on and aspects of 4th.CoSy
    Expect a new upload the beginning of the Year .

    I got out to Forth Day at Stanford again this fall . Had some useful meetings and actually got 4th.CoSy up on a couple of pioneers' machines .

    Given that motivation , I'm getting some very basic and essential work done on CoSy . For instance , I have managed to get along all this time without having an actual insertion word ( I've decided to name  at! )  .   Here's it's current definition in Ron Aaron's Reva.Forth CoSy is built in :
    : at!  ( v0 i v -- v ) | insert elements of v0 at locations i in v
        >aux 2p ( L@ lst cr R@ lst cr aux@ lst cr )
        aux@ Type@ 0if L@ i# 0do L@ i i@ aux@ R@ i i@ ix rplc loop 2P aux> ;then
    .s ."  | simple " cr R@ i# 0do L@ i i@ aux@ R@ i i@ i! loop 2P aux> ;
    The  .s ."  | simple " cr   is in it for debugging .
    The slurping ( reading in ) of the source files in the example below in a comment on the Silicon Vally Forth Interest Group list took me most of a day to get working because of an excessively meandering path getting down to the core issue that I was splitting on  "lf rather than "nl and was leaving a trailing "cr the names which  slurp^ couldn't understand .

    -------- Forwarded Message --------
    Subject: Re: [svfig] <<NSF>> Smaller, faster, greener "high-rise" 3D chips are ready for Big Data
    Date: Fri, 19 Dec 2014 08:12:56 -0700
    From: Bob Armstrong <>
    To: Silicon Valley Forth Interest Group <>

    Intel is going heavily 3D , particularly in memory .  A good chunk of the afternoon at their recent Investor's Day was about the disruptive density and cost-reduction they see in flash .  They are doing like 32 layers ( I'm not sure of what ) .

    Irvine Sensors was doing stacked chip "retinas" more than a decade ago .  Heat becomes an issue .

    16 * 64   APL characters can express a LOT of algorithm .

    That's why I've been motivated to create an APL informed vocabulary of dynamic recursive lists in Forth .
    I wondered how many screens of Forth a screen of APL was worth , and I found what I've gotten done done is about 113 , simply counting characters :
       s" dir CoSy\\*.f /b /s "  shell> >t0     | get source file names ,
       t0 "nl toksplt  -1 _i cut >t0>     |  split on nl . drop empty last row
     s" C:\4thCoSy\CoSy\AltStackOps.f"
     s" C:\4thCoSy\CoSy\CoSy.f"
     s" C:\4thCoSy\CoSy\CSauxstack.f"
     s" C:\4thCoSy\CoSy\Derived.f"
     s" C:\4thCoSy\CoSy\FloatsPlus.f"
     s" C:\4thCoSy\CoSy\Furniture.f"
     s" C:\4thCoSy\CoSy\Head#change.f"
     s" C:\4thCoSy\CoSy\Job.f"
     s" C:\4thCoSy\CoSy\math.f"
     s" C:\4thCoSy\CoSy\RecurInterp.f"
     s" C:\4thCoSy\CoSy\SaveRestore.f"
     s" C:\4thCoSy\CoSy\SaveRestoreNew.f"
     s" C:\4thCoSy\CoSy\Tui.f"
     s" C:\4thCoSy\CoSy\util.f"
     s" C:\4thCoSy\CoSy\Danny\simple-button.f"
     s" C:\4thCoSy\CoSy\Danny\simple-button2.f"
       t0 { slurp^ rho } eachM> ,/    | read each file and return their lengths
    i( 1382 53293 2554 1046 4312 6431 1615 7112 1292 3758 4580 5310 9231 12157 819 1109 )i
       R0 +/                | add them up
       R0 i>f 64. _f %f     | divide result by 64
       R0 16. _f %f         | divide by 16

    But it would be fairer to count lines :
      t0 { ^slurp^ "lf toksplt rho } eachM> ,/ +/    | split each file into lines and count them
      R0 i>f 16. _f %f

    So , depending on whether you count total characters or actual lines as written , this bit of APLish takes about 110 or 240 screens to support , not counting Ron Aaron's Reva Forth they are built in .

    ( Sorry for the self-indulgence , but it was a useful exercise . )

    I remember when they placed big mylar balloons in orbit , as passive Echo satellites . We all went out to see them pass over as they were quite visible .  I see they managed to get the first satellite in Clarke , geostationary , orbit by 1964 .

    Bob A

    On 2014-12-18 11:35, David L. Jaffe wrote:
    IBM did some work in on stacked chips for the memory in the IBM 5100 in 1973 - that predated their PC products
    the neat thing for me is that you could literally switch from BASIC to APL
    via a front-panel toggle
    ----- Original Message -----
    Sent: Thursday, December 18, 2014 9:44 AM
    Subject: [svfig] <<NSF>> Smaller, faster, greener "high-rise" 3D chips are ready for Big Data

    This from Stanford, our gracious hosts.  :^)

    Sorta reminds me of Green Arrays.


    neither public nor private,
    this membership of correspondence
    neither public nor private,
    this membership of correspondence

    Comments from a couple of emails concerning speed

    Speed has never been a particular interest to me . It's a nice , and comes with the APL structure .  But my central interest is the ability to express and play with logically parallel algorithms .  AND very much the personal interface so I can take care of the business of life as I have phrased it , and work effectively thru problems of interest to me , such as a planetary model .

    Q2. Can we eliminate the database, especially relational, structured database and use some thing else? Kdb is array based and it not only maintains but delivers additional speed, will it help? Any suggestions? B-trees, Quad-trees, combination of Vec and Ravel, shard technology?
    The first speed advantage of Kdb is , like a lot of properly structured DBs in APL , its columnar structure back when other people were using "horizontal" records . They used to call the columnar structure "inverted" .

    The big speed advantage of Kdb over SQL is that SQL is a step too academic and suppresses order . It's based on the notions of unordered sets . Kdb does not suppress order so if you select some subset of data you know it will be returned in the order of the original data . I mentioned this in one of our conversations .  This is why Kdb concentrates so much on time series analytics which are very clumsy to specify in SQL lacking a concept of order .

    I played with the Kdb vocabulary built on top of K but found it clumsier than making my own functionally similar vocabulary . I ran into a link on to my whole vocabulary I forgot I had posted at .  All the database functions are prefixed with DT for DictionaryTable .  All my ledgers are kept in such tables .

    I'm sure Jim [ Brown ] knows a lot more about this stuff , especially performance , than I do .

    Q3. What is the underlying database of CoSy? Emails do not utilize file technology: how does email get organized and preserved?
    The closest thing to a "database" in CoSy is the dictionary structure modified from Arthur's dictionaries . They are essentially just paired lists of symbols and values .  Arthur added a third column of attributes or meta data which I understand was influenced by similar designs in some Lisps .  I have found metadata to be so important that I have restructured the headers of all CoSy objects to allow a link to metadata , which in general will itself be a dictionary .

    The standard email file structure strikes me as a mess .  I spent a bunch of time doing various things with email and spam filter logic in K but haven't touched it since turning to work on 4th.CoSy .

    I will keep you in the loop and as soon as possible I will provide further details. How fast is FORTH? How fast is CoSy? How fast is K? How do they handle DNA stuff?
    I read an article long ago titled something like "Why Forth is not slow" . It had an analysis that the path to the machine was generally quite shallow , sort of a log of the number of words called . sort of thing . But the general approach of Forthers is that if something really is speed critical , it is defined in assembler -- which can simply be inlined with defined Forth .  This is made very easy in Reva Forth .  Here's an example you will find in the  4thCoSy/CoSy/util.f  file :
    | \/ |  Iverson logic | \/ |
    : =I ( n1 n2 -- flag )    | Original : =I =if 1 else 0 then ;
        inline{ 3b 06 ad 0f 94 c0 0f be c0 } ;

     | from Jukka ,
     | the assembly:
     | cmp eax,[esi]   ; standard stuff
     | lodsd           ; ditto
     | sete al         ; sets al to 1 if zero flag set otherwise sets it to 0
     | movsx eax,al    ; expands al to eax filling the rest with zeros
     | was inline{ 3b 06 ad b8 0 0 0 0 75 01 40 } ;   
     | from Ron ,
     | Annotated assembler from Cellarguy :
     | asm{
     |  cmp eax,[esi]    ; compare TOS,NOS to set the zero clear flag
     |  lodsd            ; poor-man's drop, or:
     |                  ; 'I don't care what I pull into tos...  ( = drop )
     |  mov eax,00000000    ; ...because I'm over-writing it anyway'  ( with 0 ).
     |  jnz .done       ; now we check that flag we set.
     |  inc eax            ; if flag was set add 1 to the 0 and leave that ( -- 1)
     | .done:            ; else just leave the 0 ( -- 0 )
     | } ;
     | was : =I =if 1 ;; then 0 ; | Helmar     2005-10-15 13:19:28
    Several of the real x86 machine language guys who contributed to Reva when it was being fleshed out would simply post the hex sequences . Several times I had to ask for translations to the actual assembly so I could have a clue . This is a result returning equals . Ron originally only had the conditionals like  =f  until I asked for an actual result returning function .  It shows how far from "functional" thought the Forth world can be .

    One further point I should mention .  Each of those dictionary items , eg ,  Date , is has an attribute ( meta ) dictionary associated with it .  In  K , as I've said , this is kept in a third column in the dictionary . In 4th.CoSy I have changed this structure by adding one cell to object headers so each object can have an associated meta dictionary .

    In the example here ,  the attribute on each of the items , eg , Date , is a function to sort the table on the heading clicked . On the whole table ,  QW , it's and entire dictionary of functions to be executed  for such things as copying  and inserting , and information like date of last modification , associated account numbers , etc .
    I felt I wasn't as clear about the structure of K databases as I might have been .  ( CoSy's essentially the same . )

    A dictionary is a pair of lists  ( names ;  values )

    A database is a dictionary where all the values are lists of the same length .  Here's a little one that happens to be sitting around open on my machine right now .

    It's a dictionary of 5 items the values of each of which are lists of 6 items .

    All for now  | 20141223.154847 |

    See related   4th.CoSy Download & Disqusion 

    comments powered by Disqus

    Whole CoSy
    Locations of visitors to this page
     I reserve the right to post all communications I receive or generate to CoSy website for further reflection .
    Contact : Bob Armstrong ; About this page : Feedback ; 719-337-2733
    Coherent Systems / 28124 Highway 67 / Woodland Park , Colorado / 80863-9711 
    /\ /\ Top /\ /\