
- maybe need to
    calculate hash when constructing surreal
    put the surreal into the cache during construction
      and thus avoid ever doubling up???


- put "values" into surreals in the same way as hashes,
     - but for surreals resulting from computations this should be easy 
     - only for arbitrarily created will it be harder
     - instead of "convert" (which should just read the value, create
       a "value" function to calculate
       
reverse direction of the arrows

"width" of DAG,
   where this is the max of the number of nodes at any generation in
   the DAG
         - so for each generation number less than g(x), we need to
           record the number of nodes at that generation

add code to test error conditions
   and check bounds on conversion routines make sense, e.g., how big a float can we convert

x y only involves multiplications of all of the elements of the DAGs
of x y, so the number of multiplications is quite constrained
   new algorithm
      1st compute multiplications for all the pieces from the ground up
      compose these into the pieces, and build up instead of recursing
          down (through times -- still recursing for add)
   current version cheats on DAGs
      prolly should have a structure DAG
            list of nodes
	    list of left and right edges
      but still current version of output to dot would require more
            because of nice printing of arrows
  
   could do an abbreviated DAG picture though, where we only do
   values and arrows, not subboxes

   surreal2dag
    - convert to a DAG data structure
    - then "print" outputs the dag structure in dot format

x + y is similar
   but x-y is not!
   

numbers in the expansion of xy, e.g., X_L is non singleton, the
numbers seem to have
   (i) the same generation XXXX (not always true for fractions)
   (ii) the same value
at least this is true for 2x3, which is the first place to see
repeated values
    check for other cases
 

box function from Conway

principle of caching results vs internal passing of results in DAG in function
   (1) if the result is a surreal, then cache it
   (2) if the result is, Bool, don't

   (3) if there isn't a good way to cache in the function then don't do it internally

   (4) binary operation, then cache, uniary recursion through tree, then don't?

   (5) cache negations???



sparsity measure, or rather density ...
   (edges+1) / nodes
      min value = 1,    max value = f(n) for n-n

topological ordering of nodes
   -- could put this into stats as the dictionary values
      -- ...

no. of DAGs, 1,3,25,543, ....
   so not all are surreals ...
   but also, surreals grow much faster ...
      so some (unlabelled DAGS are isomporphic)
      
 

simplification is 'transitive reduction'???
   i.e., the smallest DAG with the same reachability relation??? 

build a set-based alternative and compare performance ...
      - convert Alt to mainline
      - add "size" for Dict(Dict) -> [2,4,5, ...]
      - profile 2x5 to see what is still slow

consider use of globals, and or bootstrapping the code with some cases with known results  
	 - extend to cache results of many functions
	    - e.g. size, depth, size_u, ... 
         - because although we are using DAG in some sense, its still
	   stored as a tree
	     - could instead of a list of surreals in each, have a
  	       list of hash values, linking to array of existing surreals

                => new alt representation should be even faster 

             - avoid storing a surreal number more than once
		
make round(0.5) match julias behaviour, or better yet implement the different rounding types
       and then precision, which is a whole nother issue

could do an ALT implementation that
   (i) tracks stats of surreals when they are created to avoid
       overhead later 
   (ii) stores a hash value when created, again to avoid overhead
   (iii) creates a Dict of surreals, so we can convert the tree
       structure into a DAG using refs to the Dict, reusing components so that we don't have
       to recompute all of the pieces already computed 

transfinites and ordinals

rewrite README and
   add internal documentation 

division
	- can we do this natively - currently requires conversion to reals and back    
	- more testing needed

functions	
	better round, more consistent with julia standard round
	       - not trivial because can't just multiply and reuse
	div
	rem
	mod1
	gcd
	lcm

	math functions -- this is hard without cheating by converting to real, and finding canonical equivalent
	     log
	     exp
	     powers
	     trig
         require infinite series, so not valid for finite surreals 

add some automatically generated random tests

"Practically Surreal"

"The Graphical Structure of the Surreal Numbers Examined Through the
 Lens on an Implementation in Julia"

(1) one paper on CodeX, with general stuff on code and algorithms
(2) one recreational maths paper on the structure and nature of surreal arithmetic






