Sunday, May 19, 2024

notes on status and near-term plans

status updates after ~30 hours of work over the course of 1 weekend.

I'm happy with the rewrite of the back-end since it makes the design more robust and flexible. 

I've learned enough Cypher to feel comfortable continuing with this path. I'm also somewhat confident (with no basis in experience) that switching to a different property graph is feasible without having to rewrite the front-end and controller).


Developer workflow

My "how do I develop the code" steps have evolved to include Black and mypy. 

After making changes to the code I format using Black and then use type hinting:
make black_out
docker run --rm -v`pwd`:/scratch --entrypoint='' -w /scratch/ property_graph_webserver mypy --check-untyped-defs webserver/app.py
To launch the web UI,
make black_out; docker ps | grep property | cut -d' ' -f1 | xargs docker kill; date; make up

I added Selenium tests to speed up the UI validation.


Near-term plans

There's a lot to do, so in roughly priority order (from most important near-term to will-get-to-later)
  1. Convert Latex expressions to Sympy
  2. Check the dimensionality and consistency of expressions using sympy
  3. Provide feedback to user on invalid inputs using dimensionality checks and symbol consistency
  4. Check steps using SymPy. Currently in the v7 code base the file "validate_steps_sympy.py" takes Latex as input, converts to SymPy, then validates step. I think the step validation should be done using pure SymPy? (rather than taking Latex as input).

Lean: Explorer how to include lean derivations per step. Can I get lean to run on my computer?

Add API support to enable curl interactions.
This would improve command line testability of workflows

Write more selenium tests.
This assumes the web UI is stable.

Make the HTML tables sortable (as already exists on https://derivationmap.net/)

Support rendering latex in HTML (as already exists on https://derivationmap.net/)

Migrating existing content into the new back end

Convert latex strings into PNG files for visualization (as already exists on https://derivationmap.net/)

Render derivations as PDF (as already exists on https://derivationmap.net/)

Saturday, May 18, 2024

distinguishing scalars, vectors, and matrices as operators or symbols

A Physics derivation has steps and expressions. Expressions are composed of symbols and operations. 

Symbols (e.g., x) can be constant or variable, real or complex. Symbols do not have arguments.

Operations are distinct from symbols because they require one or more symbols to operate upon. For example, +, ^, determinant(), etc.


Within the concept of symbols there are distinct categories: scalar, vector, matrix. The distinction is that they have different properties. A vector has a dimension, a matrix has 2 dimensions. 

Since vectors can contain variables (e.g., \vec{a} = [x,y,z] ) and matrices can contain scalars, then we need a new boolean property for symbols: is_composite, and a new numeric property for symbols: dimensions. 

When "dimension"=0, the symbol is a scalar. Then is_composite is false.
When "dimension"=1, the symbol is a vector. Then is_composite is either false or true. If true then the symbol has two or more edges with other (scalar) symbols.
When "dimension"=2, the symbol is a matrix. Then is_composite is either false or true. If true then the symbol has four or more edges with other (scalar) symbols.


However, this accommodation isn't sufficient. We can say "matrix A = matrix B" and consider the matrices as symbols. However, a quantum operator (e.g., bit flip) is a matrix that operates on a state -- an argument is required. There is an equivalence to the Hamiltonian ("H") and the matrix representation. Therefore the matrix is not a symbol as previously defined.


While the expression "matrix A = matrix B" is valid, " + = + " is not. The difference is that "+" is not a composite symbol.

"H = matrix B" is a valid expression even though "H" is an operator. 

Therefore the distinction between symbol and operators is misleading. The schema for symbols should be

  • latex
  • name_latex
  • description_latex
  • requires_arguments (boolean)
    • if requires_arguments=true (operator: +, /, ^, determinant), then 
      • argument_count (e.g., 1,2,3)
    • else requires_arguments=false (variable or constant or operator: a, x, H), then 
      • dimension (e.g., 0,1,2)
        • if dimension = 0 (aka scalar: "size=1x1" and "is_composite=false") then
          • dimension_length
          • dimension_time
          • dimension_luminosity
          • dimension_mass
        • if dimension = 1 (aka vector) then
          • is_composite = false or true
          • orientation is row xor column xor arbitrary
            • if row or column, 
              • size is arbitrary xor definite
                • if definite, "2x1" xor "1x2" xor "3x1" xor "1x3" ...
        • if dimension = 2 (aka matrix) then
          • is_composite = false or true
          • size arbitrary xor definite
            • if definite, "2x2" xor "2x3" xor "3x2" xor "3x3" xor ...

That means the major distinct subtypes of symbols are
  • symbol that requires arguments
  • symbol that does not require arguments, dimension 0
  • symbol that does not require arguments, dimension 1
  • symbol that does not require arguments, dimension 2