forsyde / forsyde-atom Goto Github PK

There seems to be a bug with the sampDE utility. When dumping an output signal there are two initial events, e.g

adIn = 
	0	0.0
 	0	0.0
	0.1	0.5877843706908867
	0.2	0.9510561226889965
	0.3	0.9510566668308958
	0.4	0.587785240141314

As new features will be implemented (see #23 and #24 ), the documentation becomes outdated. Most design decisions are not relevant any more, and this needs to be reflected in the documentation.

cabal haddock has problems with the figures on my machine:

...
21% ( 29 /141) in 'ForSyDe.Atom.MoC.SDF'
100% ( 3 / 3) in 'ForSyDe.Atom.Skeleton.Vector.Interface'
43% ( 75 /174) in 'ForSyDe.Atom.Skeleton.Vector'
100% ( 52 / 52) in 'ForSyDe.Atom'
Warning: ForSyDe.Atom.MoC.DE: could not find link destinations for:
event
Warning: ForSyDe.Atom.MoC.CT: could not find link destinations for:
event
Documentation created: dist/doc/html/forsyde-atom/index.html
cabal: filepath wildcard 'includes/figs/*.png' does not match any files.

Once the forsyde-tikz project is updated, I need to remove its source from the includes folder, and (probably) update the figures according to the new API.

ExB has the extend method which plays the role of pure in the Applicative class. Making ExB a superclass of Applicative might reduce the library code.

We need to formulate a disciplined way of extracting statistical information from the execution of ForSyDe models. Possible directions:

• describing a new layer, independent of the rest
• making use of or extending the ExB layer

Although a good numerical representation for (continuous) time, Rationals are resource-consuming, and sometimes the model might accept trade-offs in precision vs. performance. A better approach would be to make Time a type class. Clear semantics need to be defined. Special care needs to be taken when instantiating e.g. Float as time, because we lose comparison operations.

Based on the factorization theorem, all skeletons can be expressed as a reduce . map pattern, regardless of the categorical type they are applied on. Thus this type class should be instantiated by all the "structured types" associated with the Skeleton layer, and should implement the atoms with the functionality above.

The tuple application utility seems to have wrong infix for chaining operation (infixl 6), leading to redundant parentheses such as

SY.toDE <> (solve <> DE.toSY1 des)

Needs fixing. Check if it also works with point-free style.

There is a bug I've discovered when dealing with tupled output signals when redesigning the multi-output process constructors/patterns. WHY I needed to redesign them is described in this wiki log.

In short, if I want to respect the atom definition (i.e. atoms are completely independent entities, and constructors are just patterns of atoms), the revised implementation deadlocks when feeding back tupled signals into, for example, a multi-signal generator.

There are missing commands on the forsyde-tikz style files:

\mapSG
\combinator

There are also /composite keys/ issues I could not find.

One can read at the beginning of the documentation,

-- | Type synonym for a SY signal, i.e. "a signal of SY events"
type Signal a   = Stream (SDF a)

Which must be an artifact of using the SY Signal definition as a starting point for this piece of code.

@HWoidt : you said something that there might be a better way to define process constructors in terms of generating them. As you know, I define the constructors statically (comb12, mealy41, etc.), due to Haskell's strict type system, although they all have recursive definitions. Is there a method that would spare me of this huge amount of boilerplate? I prefer to avoid TemplateHaskell for now, but even if this is not possible, could we have a brainstorming session or could you point me to some documentation that might shed some light upon this matter? Are there any ideas in type-level that I can borrow?

Up till now timed MoCs fitted elegantly with the atom view due to their applicative style of operating on signals, thus I could cover them all as instances of a class MoC. With untimed MoCs things are a bit more complicated since the function applied takes vectors as arguments.
Instantiating for example SDF couldn't be that complicated, right? Just express the function arguments as type synonym families... well, not really. The type-level constraints are quite a pain to deal with.

Long story short : this compiles and behaves just fine:

import qualified Data.Param.FSVec as V
...
(-$-) :: (Nat rate) => (V.FSVec rate a -> b) -> Signal a -> Signal b
_ -$- NullS = NullS
f -$- sig   = let x  = (V.reallyUnsafeVector . take c . fromSignal) sig
                  xs = dropS c sig 
                  c  = V.length x
              in if c == length (V.fromVector x) then f x :- (f -$- xs) else NullS

I need though to express this as an instance of:

class MoC e where
  type Arg e a
  (-$-)  :: (Arg e a -> b) -> Signal (e (Value a)) -> Signal (e b)

The pain is described in a recent question on StackOverflow, where I did not get an answer yet.

@2opremio : sorry to tag you too, but since you implemented FSVec, do you know a way to either cheat the type system to express it as a type synonym (Rank2Types does not work with type families), or somehow extract the size so that I am correctly building x in the let binding?

P.S.: this fails miserably:

newtype ArgV a = ArgV (forall rate.Nat rate => FSVec rate (Value a))
instance MoC SDF where
  type Arg SDF a = ArgV a
  f -$- sig   = let x  = (V.reallyUnsafeVector . take c . fromSignal . fmap fromSDF) sig
                    xs = dropS c sig 
                    c  = V.length x
                in if c == length (V.fromVector x) then SDF (f (ArgV x)) :- (f -$- xs) else NullS

because for some reason x does not seem to have its size inferred as rate, but as an unknown s0.

As MoC atoms' type signature shows, there is a dependency that forces Behavior atoms to situate exactly under MoC atoms. While this is a natural way of viewing systems, this does not fit well with the "separation of concerns" that forsyde-atom is trying to promote. The possibility of complete decoupling these two layers needs to be studied.

According to the Bird-Merteens formalism, categorical types are exposing an inherent potential for parallel evaluation. They shall be used as promoters for the skeleton layer.

For forsyde-atom-0.1.1, at least one categorical type needs to be implemented, to demonstrate the potential of algorithmic skeletons + MoCs. Ideally, two types shall be implemented, to depict the completeness of the atom grammar for this layer.

Types considered:

• vectors (mandatory)
• arrays (optional)

The current MoC class is over-encumbered by type wrappers, which makes the atom implementation unreadable and the execution extremely slow, even if it should not be the case. This is due to an earlier decision to group all MoC atoms under the same interfaces, to demonstrate the independence of the atom semantics from their composition. This decision did not pay off due to the over-complicated programming model and the constant rely on wrappers and helper functions for instantiating even the simplest of processes.

While the theoretical framework still defines a generic formulation for all MoCs, the implementation should step away from this mindset due to limitations of the host language. In this sense, the forsyde-atom library shall implement timed and untimed MoCs as separate classes (i.e. having different type signatures, thus different pattern constructors).

An idea discussed with @joseedil suggested to represent CT tags as (t_0 + delta t) rather than global time. This way when delaying a signal, instead of altering all functions contained in events, only t0 is modified.

At least the Synchronization layer framework needs to be properly documented. Also code refactoring and proper library organization is welcome.

Possible candidates:

• for ExB layer

  • CAN (plausible, not sure if relevant)
  • value-extended boolean logic (not sure if relevant)
  • error rates or statistics (to be determined if part of ExB or its own layer)

• for MoC layer

  • CSDF (plausible)
  • LET (to be determined if possible)

• for Skeleton layer

  • trees (not sure if relevant/useful)
  • graphs (not sure if relevant/useful)

This issue collects some changes what might be implemented with the next major release:

• SY.toSDF change to SY.toSDF1 to fit woth the others
• Skeleton.farmXX might be changed with Skeleton.mapXX so far I am the only one who is using the term farm.
• add a SDF.delayn utility for convenience, which is simply SDF.delay . replicate n

Latex package is missing, can't find it anywhere.

• how to include the UI features in the architecture of the library?

• input formats

• output formats