Reflections on
MinnowBrook 2013
  • 4th.CoSy
  • Planetary Temperature
  • CoSy/Life ; CoSy/Liberty 
  •  FaceBook ; Twitter YouTube  ; 

  • Bob Armstrong

    I Spoke on 2 topics : # PlanetTemp ; #4th.CoSy

    Morning Mist @ Minnowbrook

    Modeling the Planet in APL :
    How to Calculate the Temperature of a Colored Ping Pong Ball
    Heated by the Bright Mountain Sun

    Several people asked for copies of the slides in my power point presentation of the most basic physical computations of planetary temperature presented in an APL , specifically Arthur Whitney's K . While the complaint has been made that the APL was trivial , that is very much the point , and certainly there has been no more important technical issue on the world stage over the last couple of decades than the effect of CO2 on planetary temperature ; it has been a cause of the rise and fall of governments and economies .

    As it is , when I debuted the presentation with the Manhattan Libertarians , the chairwoman , playwright Janet Hopf , was intimidated by  
    Psb : {[ T ] sb * T ^ 4 } , that power ( energy density ) is proportional to the 4th power of temperature .

    Inner Product in APL
    However , it is quite important that the actual executable expressions to perform the computations are presented . And at the talented teen level so they can be experimentally confirmed and elaborated by students anywhere .

     This first presentation taught me a lot , including the fact that I was correct in not including the unfinished slide to the right which defines the most important computation involved in the temperature calculation and , indeed , one of the most important , period , particularly with Iverson's generalization .

    A quote I feel applicable from the greatest mathematician who ever bought me lunch :

    Technical skill is mastery of complexity, while creativity is mastery of simplicity
    Erik Christopher Zeeman

    APL's goal is to implement the simplicities needed to master complexities .  I find it not coincidental that someone who has spent his adult life in interactive APL based computational notebook environments , specifically constructed to "artificially aid his intelligence"  should be so frustrated by the appalling level of the most basic math and physics displayed on both sides of the anthropogenic , ie , CO2 caused , global warming debate that he finally implemented the handful of definitions needed to calculate temperatures from spectral data .

    The real surprise came when applying these classic equations to the extreme surface temperature of Venus .  They show the alarmist claim that Venus represents a runaway greenhouse effect which may happen to us if we don't mend our ways simply does not compute .

    This work is a pure use of APL as a Tool of Thought in the manner of a talk I particularly remember from APL89 :
    Astrophysical APL - Diamonds in the Sky , Schneider, Paluzzi, & Webb :
     Members of the Space Telescope group present the physics of carbon white
     dwarf stars in half a dozen short APL functions.
    David Dooner's non-circular gears designed in APL2
    My efforts here to present classical quantitative thoughts simply ain't in the same space with Stanley Jordan's multidimensional mapping of scales or David Dooner's  mind bending non- circular gears engineered in APL2 . Those works show what intellectual challenges APL is perhaps still uniquely capable of .
    The main "take-away" I'd like to get across is that a succinct , well factored and therefore understandable , rather detailed model of planetary temperature can be created in just a couple of pages of APL definitions as or more succinct than the equations in any physics text -- and unlike any text book , executable . Currently the field is entangled in million line models , all of which have proven to be wrong , and have obscured the fact that the typical journeyman "climate scientist" doesn't even understand these most essential , non-optional calculations of radiative balance which would have been homework assignments 80 years ago . Anyone interested in facilitating such a project , please contact me . It requires collaboration with those who know the data and the relevant physics in more detail .

     Here's the link to the evolving power point : . The main page for this work is here .

    Snapshot : Minnowbrook 2013 boat trippers on launch so old it needs an outboard
    Snapshot : Minnowbrook 2013 boat trippers on launch so old it needs an outboard

    Forth ?  Oh I love Forth
    Stanley Jordan , when I mentioned I was implementing APL concepts in Forth

    Here are the notes I had jotted down in my 4th.CoSy during the day of my talk :

    | ======================== | Sun.Sep,20130915 | ======================== |
     ... ... ...
       s"  \\/ " i( 60 )i take
    s"  \/  \/  \/  \/  \/  \/  \/  \/  \/  \/  \/  \/  \/  \/  \/ "

                                   IT'S ALIVE

                                   WHY FORTH
      lists of lists ; modulo indexing ;  f?
        i( 1 0 0 0 )i i( 3 3 )i take        |  CoSy object returning . Executed w F7
     1 0 0
     0 1 0
     0 0 1
      R0 DMP        | Direct Forth output .  Executed w F6 . 

    00313568 00 00 00 00  03 00 00 00  01 00 20 00  00 00 00 00 .......... .....
    00313578 90 C5 6F 02  C0 C5 6F 02  F0 C5 6F 02  2F 5C 20 22 ..o...o...o./\ "
     s"  /\\ " i( 60 )i take
    s"  /\  /\  /\  /\  /\  /\  /\  /\  /\  /\  /\  /\  /\  /\  /\ "

    Without question , the most consequential of the talking points is :


    I use it every day as my planner and log . It will be around , and evolve as I have time and motivation , as long as I am or as others incorporate the code .

    The next point differentiates the goal of 4th.CoSy from yet another APL in any of the modern versions of Fortran like C## or Java .

    Of all the the languages other than APL , the only one I consider to be of similar intellectual and practical importance is Forth . They are polar opposites in domain and goal .


    Both are essentially the creations of individual men : Ken Iverson in the case of APL , Charles Moore in the case of Forth .
    Both are considered esoteric languages that appeal only to an elite . Both require an ability to maintain a mental "map" of data structures being manipulated . Both provide interactively interpreted environments . Both compile a definition at a time .  Both are considered to be productivity amplifiers for highly talented individuals but inscrutable at best or potential disasters at worst in the hands of the untalented .

    Both are terse enough for the Twitterverse .

    Forths are written for new processors almost as soon as they are designed . In fact , designing processors is an avocation of a number of Forth geeks .  Forths have also been written in Java , C , ...  , but that misses the point . The issue is how to get directly from a particular chip language to an extensible interpretive environment . The canonical Forth machine has 2 stacks , a data stack and a return stack . When a function is called , the address from which it is called is pushed on the return stack . Parameters are taken from the top items on the data stack  and results simply left on the stack . See , eg , Koopman . In the ( x86 ) Reva Forth I've been creating 4th.CoSy in , the essential registers implementing these stacks are explained at Reva: Register usage  .

    With this direct mapping , there is minimal overhead in function calls . A function such as
    swap which exchanges the top 2 stack items , kind of like APL's commute , is simply

        see swap        | Executed using F6 which outputs any text to the result window .
                        | This has been copied from the res window into text using F5 .
    00427C32  89 C3                       mov ebx,eax
    00427C34  8B 06                       mov eax,[esi]
    00427C36  89 1E                       mov [esi],ebx
    00427C38  C3                          ret

    I left the non-interpretive Fortran style of programming when I met the APL workspace in the mid '70s and worked hard creating such an environment in K . While Forth , working at the absolute address level , requires scripts of definitions for permanence , even the most minimal provides an interactive interpretive environment . Here in a sort of pseudo-Reva.Forth is the basic text interpreter logic :

    : interp ( str -- ? )   | the bit in parentheses is a stack comment saying interp expects a
                            |  string and may return ... whatever .
       empty? ;;        | exit if empty
       parsews          | read a word defined as non-whiteSpace string of characters
       find             | find in dictionary
         found? if execute   | if found , do it .
                else number? if push      | if not , try to convert it to a number and push on
                             else error   |  data stack , else  signal "undefined" error ..
       dropWord again ;     | then , drop the parsed word and do it again .

    In a sentence , Forth parses a word delimited by white space , looks it up in the list of defined words , if found , call it ; If not , see if it parses as a number and if so , push on the data stack .  This results in a Reverse Polish syntax .

    The word  ( yes , just a colon ) says compile and append the following text up to a  to the dictionary rather than execute it immediately taking the first word after the colon as its name .  Here's a definition using the word  swap  shown above . Note that Reva just compiles short definitions like that of  swap  inline , and optimizes final calls to jumps rather than calls , if possible , which particularly optimizes tail recursion . There is very nuanced  control over the act of compiling  .

     : tst dup+ rho swap ,L ;    | define  test 
      see tst
    00634D80  E8 27 63 FF FF              call dup+
    00634D85  E8 62 6A FF FF              call rho
    00634D8A  89 C3                       mov ebx,eax
    00634D8C  8B 06                       mov eax,[esi]
    00634D8E  89 1E                       mov [esi],ebx
    00634D90  E9 F7 A3 FF FF              jmp ,L
      5 _i iota tst   | _i  takes the 5  off the data stack and converts it to a CoSy 1 item list
     0 1 2 3 4

    I was somewhat surprised by comments by several people that they didn't see any APL . One hint at how opaque my presentation apparently was is a comment about me writing stuff in one place and something happening up above . I never thought to describe the structure I have used since I moved to K's electric GUI around 2000 . Unlike other APL session managers , when a line in the ` text is interpreted , rather than messing with the text , the result is displayed in the ` res window above . Click the screen shot of my working environment to go to a further description and a full size image .

    Here's the main example I presented . I thought the creation of an identity matrix would be a sufficient example that 4th.CoSy really does implement very APLlike nouns and verbs . 

        i( 1 0 0 0 )i i( 3 3 )i take        |  CoSy object returning . Executed w F7 .
    | res , R0 , inserted \/ here \/ using  F5 .
     1 0 0
     0 1 0
     0 0 1

    The real point I wanted to get across , and perhaps get feedback on is the structure of the header of the created array . One of the themes informing CoSy is that The Code is the Theory .
    The structure of the header of an object defines the information available to verbs acting on the object .
    The header of the matrix above shows its lists of lists structure . The header is 4 cells ( 4 bytes ) long . As shown below , the 0th cell is the type with 0 being a generic list as
    R0 is . The next cell is split into reference count and bits per item . Before Minnowbrook2011 I had concluded that with K's 3 list ( symbols ;  values  ; metaData )  dictionary structure , getting from a value to its metaData was too cumbersome . So I added a fourth cell , a link to a meta object , which will generally be a dictionary . For Minnowbrook2013 , I modified the store and restore functions to linearize and restore these added objects .

      R0 DMP        | R0 holds last result DMP displays first 8 cells .  Executed w F6 .
    address     type      count ~ rho  refs | bits   meta_addr
    00313568 00 00 00 00  03 00 00 00  01 00|20 00  00 00 00 00 .......... .....
    00313578 90 C5 6F 02  C0 C5 6F 02  F0 C5 6F 02| 2F 5C 20 22 ..o...o...o./\ "
               item 0        item 1       item 2      junk

    After the header , for a generic list , come the addresses of the items , in this case , the 3 rows of the matrix .

    Since the conference , I've continued work on a number of issues . One of the most important is implementing tracking of all allocations and freeing of objects to check for errors in reference counting . I''m somewhat amazed that it works as well as it does because when first bootstrapping there wasn't really any way to make use of collected data if it were collected .  That's all changed with substantial APL capabilities .

    Here's what the code looks like . AT+> and FT+> are deferred verbs which I inserted early on in the allocate and free functions . Here I temporarily redefine them to record all allocations and freeings as addresses and their negatives .
    | Redefining allocation and freeing tracing fns .
      0 _i 32 K* _take refs+> value AFbuf
    variable AFptr

    : allocTraceON ( -- )
        | note not modulo . subject to overflow .
     { $.> cr dup AFbuf vbody AFptr @>+! c+ ! } >defer AT+>
     { negate AT+> negate } >defer FT+>  ;
    : allocTraceOFF ( -- ) undo AT+>  undo FT+> ;
    As it stands , 4th.CoSy allows a powerful melding of chip level ( X86 ) Forth with modulo indexed dynamic lists of lists . allocTraceON actually uses a "raw" Forth pointer to insert allocated addresses directly into the body of a CoSy integer list .  A couple of my first uses showed even a simple operation like searching the content of text by converting it to a list of lines can generate thousands allocates and frees . Almost instantly .

    A final observation : Working with any indexed object , for instance , a word in a dictionary , requires in a very natural way ,  3 verbs : one returning the address of the item sought , one to store to the item , and one to access the item . EG , the words to manipulate an item in a dictionary are vx , v! , v@ .
    For example , the root dictionary in 4th.CoSy is R .  Here's accessing the object  ` Tau :
      R ` Tau v@
    APL effectively has the store and fetch , ! and @ , and K has a rather complex syntax for in effect acting on addresses , but having all 3 related verbs much simplifies a lot of things .

    BTW : By coincidence the morning talk at the SVFIG - The Silicon Valley Forth Interest Group meeting September 28th was :
    10:00 --- Manipulating MIDI Files --- Chen Hanson Ting
    Ting would like to demonstrate ways to manipulate MIDI files: changing instruments, changing tempo, and changing pitches. He will show us how to decode a MIDI file to a Forth text file which can be compiled back to a MIDI file. The text can be edited to change features in the music.
    Blue Mountain Lake , Minnowbrook 2013

    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 /\ /\