siddhartha-gadgil / provingground Goto Github PK

I've noticed that the evolve function slows down for larger arguments. Is the pruning not yet implemented, because if it is, then the evolve function should take roughly a constant time to run.

Word(List(1,2,3,5)).maxgen should return 4. However it returns 5. Is this intended behaviour, or is it a bug?

What was the next thing we are supposed to do after we have a function from (M, FD[V]) -> FD[V]?

There are still many hash collision happening, either because of poor hashing, or too many objects. In the case of hash collisions, toSet and distinct are faster on parallel collections than serial; we should try changing things to parallel and see if they work better.

• partial derivative to be defined recursively.
• tan, x, sec etc inside FormalElemFunc, so imported as f.x, f.tan etc.
• Bounds for sin giving Some(empty set)
• unnecessary negative numbers in lower bounds.
• have type for Interval[Rational]=> Option[Interval[Rational]]]

• Recursion works fine for boolean types, but only formal application is done for the pattern on succ(n) for natural numbers.
• probably mistake in the pullback-recursion definition

It is semantically better to use classes, not case classes, for extractors, as we do not generally consider their equality. It also avoids collision of the unapply method of case classes with that of extractors.

One can then create instances using objects extending the class.

Need: A type family mere proposition (in terms of HoTT, but a separate object) and an axiomatic function propositional truncation

• If an existence theorem is mainly used as such, rather than its proof (e.g. prime decomposition), then there should be a greater weight attached to this.
• In particular, it may be combined with non-constructive arguments.
• One may even attempt to factorize results to use only the propositiona

Should generate static web page, save to file and view in browser. Also log in memory for many stages.

ACevolution.evolve isn't evolving the finite distribution as expected. It's just creating a uniform distribution on the atomic moves and never evolving it. Is this expected behavior?

Weights are freshly computed for each gradient term, needed quadratically many equality checks. Should memoize weights as lazy map.

Creation of a single finite distribution with size of pmf around 30000 is taking about half a minute at runtime. The pmf itself is created instantly. Should probably use value classes.

Presently various "extras", not important enough to be in the core but not yet exiled to digressions, lie in the jvm project. The jvm project should only contain play, akka and web lookups using play. This should eventually open up the option of using something more lightweight like akka-http, especially if akka-js becomes a reality.

Requirements:

• Scala should treat these as ordinary functions.
• When we wrap a function, we get a function, etc.

We need to determine whether:

1. Converting a sequence to a set can be done in parallel by the scala parallel collections.
2. Can groupby also be done in parallel by the parallel collections.

• Runs should be based on actors, controlled by messages.
• The messaging mechanism should be abstracted, allowing:
  • sbt console
  • play server
  • akka http for general signals, including command line.

As far I have understood, each vertex in the finite distribution for andrewscurtis will contain presentation and a sequence of moves. But the moves have been implemented as methods of the case class rather than functions in the companion object. If they were implemented as functions in the companion object, we could have represented a presentation and the associated moves in this manner

(Presentation(2, "a!ba", "b!ab"), List[Presentation => Presentation](<a list of moves>))

That way, to get the resultant presentation from the original, we just compose the functions in list of moves, and apply it on the original presentation. But if the moves are implemented as methods, this kind of representation might not be possible.

For different applications, representations other than a set are useful.

• For terms (or allowing learning of moves), it is good to have several sets sorted by type (e.g. a map), to avoid checking too many pairs where combinations do not apply.
• When we sample and apply moves, it is useful to have Vector as a representation as
  • we can efficiently pick an element given an index.
  • using this, we can choose random elements efficiently.
  • this is especially so if we memoize totals.
  • choosing random elements does not need folding.

There are moves such as Lft(0, 0) - a relation cannot be multiplied by itself.
I will correct this.

This may mean finite distributions are not considered equal, even if they should be. Sets may be better (but have their own dangers).

To incorporate an understanding of associations, we must associate to each term a vector with (a function of the) norm giving the probability of choosing the vector. The probability of choosing a pair for a combination becomes (a function of the) inner product.

This is particularly important for external mining from Wikipedia etc

The present collection of weights does not make much sense for fixed size presentations.

• Firstly, we replace these by just the product of weights of the relation.
• We choose wrdCntn parameter carefully so we learn presentations only if there is cancellation.
• A choice of wrdCntn as above works for a small test, but we should soon switch to a Nielsen move generated model, similar to generating terms and types.

Instead of parser combinators, we use Li Haoyi's FastParser, which has a flatMap method. In particular,

• For lambdas /\ x -> y, we can parse y in terms of x and previously defined terms.
• Text after a function definition/declaration can use the function being defined.

At present we can re-spawn actors given a directory, but the states are not recorded to restart. Easiest way to run over a network is transmit files. Os one should be able to

• create and save run states
• do this automatically while spawning actors.

Consider the presentation $\langle a; a \rangle$. This is AC stabilized, but applying the ACstabilized method on it returns false.

To be more specific, how are we defining addition and scalar multiplication in a probability distribution, or more specifically, a finite distribution?

Could either be an accidental change of behaviour in the actor runs or a consequence of weights dropping fast. Strangely the inverses of relations do not appear in the list sorted by entropy.

• Have a trait (say ScalaTerm[A}) which ScalaRep extends, with only the scala type as a type parameter.
• Using implicits, have combinators for such implicits.

• At present scala objects such as Long are bound to HoTT types using scala-rep (should describe in the wiki). This has a form of combinators, so that functions between types with scala representatives are represented by scala functions. This is useful in defining, for example, recursion and induction for natural numbers.
• In many situations, we would like several different scala types to bind to a HoTT type, with new cases mixed in later. For example this is useful for symbolic algebra.
• The weakness of the present structure is that we have a single case class ExtendedFunction that gives formal extensions, containing information about the scala representation. Instead we should have a more general FormalExtension case class, which gives a function depending on a sequence of objects of scalla type Term => Option[Term](or refinements of this). A scalarep should give a case class extending Term => Option[Term], with an attribute indicating from which scala term it came.

At present the whole run history is pickled and saved. Loading this, generating theorems, and saving this as csv takes far too long.
Instead, one should in parallel:

• save the full run
• save final state (just use write.over)
• map to theorems and save them: asynchronously.

Indeed the save function should have these as boolean options.

At present, the hack is to look for the text content of a particular element by id, and then run a corresponding script. A cleaner way would be to:
(1) Have a class "js-div", with all elements of this class having a corresponding div appended to their children.
(2) Which div is appended is determined by a "data-script" attribute, which can be obtained by _.getAttribute("data-script")

Instead of having ad hoc saving, tuning etc, make a learning system a source, and a sink for tuning etc.

In the present approach, as in the core, the recursion function for an inductive type has been defined, but not the induction function.

• Even if sum : A -> A -> A is a commutative associative operation, the terms below are distinct:
  • lambda(x)(lambda(y)(sum(x)(y)))
  • lambda(x)(lambda(y)(sum(y)(x)))
• This not only blows up the evolving state but gives wrong semantics for back-propagation and purging.
• One needs to represent such sums differently:
  • Have types MultiSet(A) parametrized by types A, represented by Map[A, Int].
  • Have types Big(A)(f: A -> A) for Sigma, Pi etc.
  • Rewrite results of commutative operations in terms of these.
• This makes sums definitionally equal if they are equal using commuting.
• Similar considerations apply for associative operations (with List(A) instead of MultiSet(A)).
• Distributive pairs of operations should have appropriate normal forms too.

Normalize so identity moves always come last.

• The present code using inner types and structural bounds needs a lot of casting and makes it hard to see what is happening.
• It is not clear what functions to call for recursion.

In Andrews-Curtis, action of each element in genCollection(allMoves(2)) maps any finite distribution to one with weights 0. This may be a bug in moveFn

Currently, the words describing the relators of a presentation are stored in a List, which makes the order important, hence Presentation(List(a,b), 2) is not the same as Presentation(List(b,a), 2), but both actually are the same presentation. I suggest replacing the List here with a multiset, so the order does not matter, only the multiplicities.

In addition to mongo storage, especially for batch jobs, one should store snapshots with a fast and efficient format, probably the binary format of scala pickle.

I noticed a test was failing, one which compared two finite distributions for equality. How is equality of finite distributions checked now, if it is checked at all?

Ideally, applying the reduce function on Word(List(1,2,-2,-1)) should return the empty word, but what it returns is the word a.a!. I'll fix this bug and send a pull request.

It is unnatural to have rank supplied while parsing etc. It is better to store this in an actor: more generally, * store parameters specific to the system.

• snapshots contain this as a field.
• AC elements have the rank as a field.

• The value definition is called every time, leading to new objects being created, hence errors.
• We need values to be lazy, not call by name, so they are calculated only once.
• Should change inheritance structure, example making LambdaLike a trait with val for variable, value.

I implemented the method to apply a single move M to FD[V] and that works just fine. However, if we want to implement the apply method also for FD[Presentation], then we will have problems because of type erasure. The compiler will think both the apply methods have the same type signature and throw an error because of the double definition. One way to get around this could be to wrap the FD[V] and FD[Pres] in different case classes, but that's not very elegant. What do you think I should do?

All presentations and Moves should be stored along with actor and number of loops in MongoDB collections. This allows one to directly see the history of a presentation, for example.

Running is absurdly slow, even when the population size is a few thousand.

Possible Diagnosis

This is caused by a combination of

• creating objects for differentiable functions (by itself this is fine)
• passing the methods that create such objects using call by name
• as a result, a whole bunch of new differentiable function objects are created every time the function is to be applied, i.e. for every element in the population.
• this is slow, and also creates garbage so rapidly that the system starts crawling.

Example

• suppose we have

  val f = ...
  val a : DiffbleFunction...

  def m = movefn(f)
  val b = vsum(a, m)

• Then vsum is an operation to which m is passed by name, i,e,, not computed and passed but passed as a definition.
• This definition involves creation of a new object every time a method (such as apply) of m is called, i.e., for every term.
• We can avoid some cases like this with a val, but as we have iterated sums, we will be passing defs, and so creating a lot of objects.

Solution

• Avoid the call by name recursion (which happens when we use the DiffbleFunction constructor).
• Instead have separate case classes for moves, sums etc, (or an eager constructor for Diffble Functions).
• Use some other method for islands, when we get to it - the problematic method was used for enough generality to easily include islands.

Addendum

Using repeated summing for a bigsum of differentiable functions is needlessly inefficient. There should just be a big sum case class.

It would be nice to have a unit testing framework in place. This will make sure that any modification to stable running code does not break stuff. Perhaps, we could use ScalaTest (http://scalatest.org/user_guide).

Required for both case classes and parser constructors. As a bonus can be used for pattern matching after wrapping in Try.

The feedback for presentations is calculated correctly, but pulls back to the trivial one.