cadcad-org / cadcad-ri Goto Github PK

enables pursuer/enabler

"undo #61"

AC:

• Points can be specialized by the Space type it conforms to

https://github.com/danlessa/cadcad-ri/blob/7081398361c41cc6c60d1755e7269c456c4064c7/docs/examples/alice_extended.ipynb#L1-L2

Presentation: given at blockscience seminar; should be about 45-60 min + discussions with team; this will help tie our GDS/cadCAD work in with our broader research arcs on protocols, ecosystems and the role of representations of systems are part of those systems.

Write-up: intended audience is a potential contributor, who needs to see something they can get excited about contributing to. we don't need to reach everyone, we want to reach people who are aware of the limitations of existing paradigms and are interested to contribute to a new one.

Content:

• why cadCAD (GDS programming paradigm, systems engineering concepts around software and non-software systems integration, limits on controllability and observability, ecosystems of human and software agents interacting, and more)
• what: data centric computing model; spaces, blocks, wiring rules; system "dynamics" versus system "state"; estimation and decision in heterogenous networks where we only "control" a peice of the puzzle, and need to "model" the other actors and environment, in order to design, maintain and govern our software.
• how: more details on exactly what we are building (past stages: legacy verions, then: research/gds/experimental implementations for space-block focused cadCAD, current milestone is MIMO version of the reference implementation in python; next stage focus refining the user experience for declaring spaces, blocks, wirings, executing simulations; next next stage splits into inward and outward; outward is tooling for advanced workflows eg PSuU, and inward is performance improvements, primarily by unbinding from the python engine and using rust or julia under the hood (based on interpreting the python instructions)

AC:

• Spaces can be compared with =
• Spaces can be compared for equivalence (same schema)

• handles MIMO blocks
• list of blocks

from cadcad.compose import series

myblock = series([block1, block2])

asserts

block1.codomain == block2.domain

expects

myblock.domain == block1.domain
myblock.codomain == block2.codomain

Specifically:

• dimensions
• name
• is_empty

AC

• lists of blocks

we need to set expectations around strong typing with an example of integers vs floats

• Respond to #50
• Supply documentation

AC:

• We have a precise mathematical definition for the builtin blocks

To be broken down into small stories

AC:

• We have a set of experiment and simulation tools that increase users productivity.

AC:

• We have blocks that support multiple inputs on the domain
• decorator handles fx that take multiple args

Issue 36

requires:

• #56
• #57
• #59
• lists of blocks

domain and codomains of blocks are typed lists of space

domain and codomains methods of blocks return spaces not points

block signatures don't change

depends on #69

AC:

• We have blocks that accept parameters as input

AC:

• We have a clear decision on the signature of the block function

AC:

• We have metrics implemented for spaces

AC:

• Spaces are types and produce new types when operated on

Pull request here

AC:

• We have points as a class that holds data
• We have points as specializable class

I would like the following to be a valid block

@space
class CartesianPlane:
    x:float
    y:float

@space
class Particle:
    pos:CartesianPlane
    vel:CartesianPlane

@block
def particleIntegrator(state: Point[Particle], input: Point[CartesianPlane])-> Point[Particle]:
    #input is acceleration
    #output is the new particle state
    output = deepcopy(state)

    output['pos']['x']  += state['particle']['vel']['x']
    output['pos']['y']  += state['particle']['vel']['y']

    output['vel']['x']  += input['x']
    output['vel']['y']  += input['y']

    return output

Additional context
I am working on the Cat & Laser pointer demo, and aiming to make the model as simple as possible. The most natural view of the systems is the below, which requires particle integrator (twice!) which requires 2 inputs to make sense.

• what each symbol from the DSL means
• based on syntax developed in #40

proposing we add a method that can be applied to any space that will create a new space without one of its dimensions.

suppose

@space
class MySpace:
     a: int
     b: int

but then i did

MySpace = MySpace.drop_dimension('a')

the resulting space would be as if i had declared

@space
class MySpace:
     b: int

duplicated by: #67

AC:

• We have a proper pipeline for automated testing that integrates new contributions automatically.

tests for #68

AC

• aligns modeler expectations of block attributes and code
• fixtures for spaces
• fixtures for block using those space
• check signatures
• check domains, and codomains types

bad domain type notation

• execute random walk
• reqs:
  • #56
  • #57
  • #58
  • #59

built in names for:

• empty space
• point in empty space
• point in empty space type

Tasks

• research on usability and consequence
• implementation

Stemming from #54

notes

• class of that shape
• instance of that shape
• set of instances of that shape

enables pursuer/ evader

enables pursuer/evader

To be broken down into small stories.

AC:

• We have a full featured reusable compiler that lowers the DSL into block calls

AC:

• We know exactly the rules of composition for DSL
• GDS pt 2 part
  • how GDS relates to typed lamda calculus
• Could move foward on defining #49

proposing we add a method that can be applied to any space that will create a new space from exactly one of its dimensions.

suppose

@space
class CartesianPlane:
    x: float
    y: float

@space
class MySpace:
     pos: CartesianPlane
     vel: CartesianPlane

but then i did

MySubSpace = MySpace.subspace('pos')

the resulting space would be as if i had declared

@space
class MySubSpace:
     pos: CartesianPlane

also open to just returning

CartesianPlane

if we think that is better UX

• empty space
• point in empty space
• point in empty space type

Is your feature request related to a problem? Please describe.

Deepcopy's cause problems with speed and can invariably be avoided.

Describe the solution you'd like

An implementation of @mzargham latest experiment that does not use deepcopy.

• comp rules
  • not full DSL req'd
• random walk
• ideally, composition
  • swap out random walk for other policy

AC:

• It is a decorator that accepts Callables of a certain signature

Creating a general issue for figuring out how we want to create a shared documentation between the two libraries as related to definitions of things like blocks and spaces.

Issue is resolved with us coming up with a process/space to contribute to.

last week of july

AC:

• We have built-in blocks that obey their formal specification
  #56

AC:

• Spaces are formalized in terms of an algebra

AC:

• We have projections implemented for spaces

pass in a space and non-negative integer

domain: space
co-domain: same space, n copies

• deadend
  • 0: empty
  • bookkeeps a nothing
• identity
  • 1: itself
• splitter
  • 2
• broadcast
  • 3: n

AC:

• We have constraints implemented for spaces

as a space is printed, a point of space is printed in same behavior pattern

Providing int values will generate an Schema Mismatch on this case even though they're subset of the float type.:

data = {"x": -5, "y": 7}

@space
class CartesianPlane:
    x:float
    y:float

my_point = Point(CartesianPlane, data)

CartesianPlaneDot = CartesianPlane.rename_dims({'x':'dx', 'y':'dy'})