Little explorations with HP calculators (no Prime)

[DavidM]

To bring this back into the realm of calculator code, I offer the following SysRPL routine for exploration of various list configurations:

Code:

!NO CODE
!ASM
% standard extable doesn't include these, but they are listed as safe
DC %50_     2FF08
DC RROLL_   2644A
!RPL
::
   ( 1 argument required -- a list )
   CK1NOLASTWD
   CK&DISPATCH1
   list ::

      ( split the list into two 70-element parts )
      DUP
      BINT1 BINT70 SUBCOMP
      SWAP BINT71 140 SUBCOMP

      ( sum the first 70-element list )
      OVER >R
      %0
      BINT70 ZERO_DO
         RSWAP 'R RSWAP
         %+
      LOOP
      RDROP

      ( initial count: sum==50 => 1, otherwise 0 )
      %50_ OVER EQUAL ITE BINT1 BINT0

      ( place both lists on return stack for processing )
      SWAP 2SWAP
      >R >R

      ( update sum, incrementing count for each instance of sum==50 )
      BINT70 ZERO_DO
         BINT3 RROLL_ 'R
         BINT3 RROLL_ 'R
         BINT3 RROLL_
         %- %+
         %50_ OVER EQUAL IT ::
            SWAP #1+ SWAP
         ;
      LOOP
      2RDROP

      ( drop the sum )
      DROP

      ( convert the count from system binary to standard real )
      UNCOERCE
   ;
;
@

This compiles with the built-in compiler (256.06 MENU, execute "ASM"), provided you have the standard extable installed in a port. Store the resulting code into a variable (I named mine "mc" for "match count").

This program assesses a list of real (approximate) numbers where 1. represents blue balls and 0. represents white balls. The result is a count of the number of contiguous 70-ball segments in the list that meet the requirement of containing 50 blue and 20 white balls.

The program is written with the assumption that the list you give it is properly constructed (140 real/approximate numbers -- exact integers aren't allowed). Any other content in the list (different quantity or object type) may cause your calculator to crash.

Why would I create such a fragile program? Because I was more concerned with speed than robustness in this case. Checking the argument's contents is normally a requirement for SysRPL programs that are meant to be general-purpose tools, but I opted to forego the quantity and type-checking this time to make it faster, leaving that responsibility to other programs that may call this one.

This routine will check all 71 sublists in a properly-formatted list argument in less than 0.2s on my 50g, which makes checking a variety of list arrangements possible in a reasonable time period. An emulated 50g on my laptop executes the same code in about 0.0045s.