feat (report): Progress on report.

doc/remarques.typ

@@ -0,0 +1,228 @@
+La phrase "it is less computationally intensive... the compiler". est mal dite;
+tu peux dire que c'est la methode classique, par exemple, implementee pour
+simulink et aussi Zelus.
+
+Rmq:
+
+- Les methodes numeriques (centralisees) les premieres ont ete faites
+  pour resoudre un probleme initial. dx/dt = f (x(t)) t et x(0) = x0 ou x est un
+  vecteur. 
+
+- La "simulation distribuee" (cad faisant intervenir plusieurs solveurs)
+  existe aussi mais pose d'autres problemes: efficacite, convergence. Elle est
+  plus difficile a implementer.
+
+- Sundials CVODE a une methode centralisee mais avec une implementation de
+  manipulation des vecteurs qui peut etre parallele, cad que tous les calculs de
+  vecteur/matrice peuvent se faire en parallele. On ne l'utilise pas dans Zelus.
+
+p2.
+"we cannot necessarily use "pre"...": a mon avis, le lecteur ne peut pas
+comprendre ce que tu ecris ici. A mon avis, tu peux dire ce qui marche (si je ne
+me trompe pas, pouvoir internaliser le solveur au modele et donc le composer
+avec un observateur qui contient son propre solveur) et ce qui est a faire (si
+je comprends, pouvoir ecrire directement assert dans le code et la compilation
+pour pouvoir co-simuler le modele et ses differents observateurs/assertions.
+Pour le "pre", c'est un point que tu peux mentionner plus loin dans le rapport
+lorsque le lecteur a plus de contexte et de matiere sur ce que tu as fait.
+
+Il n'y a pas de numero en bas des pages dans ton texte. Il en faut. Impossible
+de savoir ou on est sinon.
+
+section 2. Tu parles de streams (Nat -> V) alors que tu donnes une semantique
+avec des etats. C'est bizarre. Tu ecris pre(s) alors que l'on ne sait pas ce que
+c'est. le
+
+```ocaml
+let rec (o, s) = M.f_step(i, M.s0 -> pre(s))
+```
+
+n'est pas du caml valide.
+
+Que veux-tu dire ? Quel est le type de Simulate(M) ? Je pensais (cf. page
+d'apres) que tu voudrais ecrire:
+
+```ocaml
+simulate(M): list(I) -> list(O)
+```
+
+Le listing 1 ne correspond pas a la page precedente (ou l'inverse). Pourquoi ?
+
+Page d'apres (5 ?).
+
+Je ne suis pas fan de l'exemple sincos_discrete() tel que tu l'as ecrit car il
+diverge. Il laisse soupconner que l'on ne peut pas ecrire de schemas numeriques
+avec des streams. C'est faux, en general. 
+
+En somme, le code listing 2 est un mauvais programme. Il y a une raison
+mathematique liee a l'analyse des poles; je te montrerai a mon retour. Si tu
+veux garder cet exemple de sin/cos, il faut mettre deux integrateurs differents,
+un forward et un backward.
+
+Ou alors, il faut faire un discours (plus long) pour expliquer pourquoi c'est
+mieux d'ecrire la forme a temps continu, que justement, elle permet de ne pas se
+casser la tete pour savoir ou et quand mettre un pre. Mais c'est un peu
+orthogonal a ce que tu veux raconter.
+
+Discrete models -> Discrete-time models.
+Continuous models -> Continuous-time models.
+
+Tu pourras ensuite dire que tu confonds les deux.
+
+2.2 la raison de la divergence n'est pas la. Si tu prends un schema backward +
+forward, ca ne diverge pas. Par contre, si tu prends Van der Pol en discret, pas
+fixe, avec un pas trop petit ou trop petit, tu tombes sur nan. Regarde. J'avais
+fait l'exemple (regarde sur le depot; ou refais le).
+
+Rmq: sin/cos n'est pas un super exemple pour justifier l'interet de Zelus (ou du
+temps continu en general) car ce systeme est lineaire. Un schema numerique pas
+fixe (donc programmable directement en synchrone) marche bien. C'est plutot
+quand la dynamique est compliquee, non lineaire, qu'il te faut un schema
+numerique plus elabore et que l'expression directe d'un modele a temps continu
+se justifie. La modelisation d'evenement en etat (zero-crossing) le justifie
+aussi. Le cas classique, c'est le modele bang-bang. Tu veux detecter les
+instants ou la temperature passe un seuil. Avec un modele de temps pas fixe, tu
+ne peux pas.
+
+avant de donner CNode(...), dit ce qu'est le probleme.
+Qu'est ce qu'un modele M ?
+
+```ocaml
+model (i) = o where
+  der s = f_der i s
+  der o = f_out i s
+```
+
+2.3. Tu n'as pas dit/defini ce qu'etait un "initial value problem". Le faire
+(sinon, on ne comprends pas).
+
+"the integr node from Listing 2 is another example of a numerical solver
+(albeit not a very good one)"
+
+A mon avis, inutile. Que veux-tu dire que tu n'as pas deja dit (on peut calculer
+une approximation de `(der(x)/dt)(t)` a des instants `n * h` (`n in Nat`) par
+`(x - pre(x))/h`?
+
+
+"Of particular interest is the fact that numerical ODE solvers compute
+approximations sequentially. "
+
+Ca depend. Les solveurs a memoire (dits "multi-pas"). Les solveurs sans memoire
+tels que RK, non. A mon avis, tu peux commencer par exempliquer ce que calcule
+un solveur: etant donne le IVP, l'objectif est de calculer une solution
+[0, tmax] -> V. En pratique, il ne calcule pas toute la solution. Il calcule une
+suite de solution pour [0, h0][h0, h1][h1, h2], etc. Relis l'article de
+Chapoutot et al., de memoire, c'est tres bien explique. Sinon, il y a les livres
+jaunes dans l'etagere de mon bureau.
+
+"This sequential process gives way to a synchronous interpretation of an ODE
+solver as a discrete node."
+
+Qu'est-ce qu'un "discrete node" ?
+
+IVP(Y, Y'). Aurait du arriver bien plus tot.
+
+dy /dt (t) = f t (y(t))   
+y(0) = y0
+
+donner l'horizon de temps (par defaut, +infty ?).
+
+Je prendrais une autre lettre que "s". (on note s pour "state" en general). "o",
+pour "output" ?
+
+La notation pointee est un peu troublante (en math, on la confond avec la
+multiplication. Utiliser une police ad-hoc pour h et u de sorte que s_0.u ne
+soit pas ambigu.
+
+mets des numeros de ligne dans ton texte stp. Il y a un style latex pour ca. Ou
+au moins des no. de page.
+
+"The ODE solver does not itself introduce discontinuities; the only
+discontinuities in the system are those introduced by the input signal."
+
+Avant de dire cela, tu ne parles par d'entrees. Pour le moment, ton systeme
+n'est pas "hybride". C'est une ODE. Tu ne donnes pas d'hypotheses sur f. En
+faut-il ? Lesquelles ?
+
+"The simulation of a continuous-time system with an ODE solver is now itself a
+synchronous node:"
+
+c'est un point de vue. Puisque la simulation d'un modele a temps continu calcule
+une suite de solutions approchees, ne pourrait-on pas la voir elle meme comme
+une machine synchrone qui...
+
+page suivante.
+
+Plutot que Signal(V), j'utiliserais un autre nom. Tu as deja un langage qui
+manipule des signaux, non ?
+
+Superdense(V) ? En reference aux travaux de Pnueli et al. Puis Edward Lee et al.
+Puis Caspi et al.
+
+Superdence(V) = R+ -> Nat -> V avec, a cote, une fonction qui pour chaque t in
+R+, donne le nombre de sauts (relire les articles; j'ai oublie le nom de cette
+fonction). step(t) in Nat.
+
+est-ce tres different de
+
+Nat -> R+ -> V avec a cote, une fonction qui indique le temps qui s'ecoule pour
+chaque n in Nat ?
+
+Dans un des articles de Edward Lee, il explique le type des signaux pour le
+temps continu. Regarde son livre (vert) sur mon etagere.
+
+Le texte de cette page (8 ?) est un peu confus.
+
+est-ce que les bouts de fonctions sont collees les uns aux autres ?
+
+none a le sens de "not yet" ? Comment recolles-tu les morceaux ?
+
+(h0, u0) (h1, u1) ... (hn, un)
+
+est-ce equivalent a :
+
+(h0, u0) none (h1, u1) none none (hn, un) ?
+
+A ce stade, tu n'as pas dit ce qu'etait $italic("CNode")(I, O, S_M, S'_M)$. A
+quoi ca ressemble ?
+
+Les elements du listing 4 doivent etre donnes dans le texte en maths. Le code
+caml doit etre mis aussi dans le listing 4. Je comprends bien mieux le code que
+les explications ! Sois plus precis dans le texte, ca aidera a comprendre.
+
+utiliser hmax plutot que h pour ivp. Eviter les surcharges de noms autant que
+possible.
+
+Plutot que "discrete node", utiliser "synchronous machine" ? Le terme "machine"
+est un terme technique des annees 60/70. Cf. articles historiques sur les
+automates et les "sequential machines". Tu peux dire, qui se caraterise par un
+etat initial, une fonction step lisant une entree et produisant une sortie,
+(plus une fonction reset) si tu veux.
+
+"Since time is logical in discrete nodes". Un peu trop pedant (et obscur) a mon
+avis. On manipule des suites de valeurs; il n'y a donc pas de temps reel ou
+physique. Le temps est juste la succession des valeurs.
+
+Le paragraphe "The question of discrete events..." est un peu confus. Donne un
+exemple. E.g., un timer: un controleur ouvre un robinet pendant 4s; une lumiere
+doit clignoter en alternant allume/eteint 1s/2s. ce sont des cas ou il y a des
+evenements en temps, cad en reference a la variable t (der t = 1 init 0).
+D'autres evenements ne sont pas des evenements en temps. E.g., une roue qui
+tourne (e.g. volant moteur). Compter le nombre de tours de roue par seconde avec
+un capteur. Le schema general est dit de "Zero-crossing". Etc. La balle qui
+rebondit, etc. Tu en trouveras d'autres !
+
+
+La suite est pas mal. Il faut expliquer (et possiblement donner le code, au
+moins en annexe) pour 2.5, 2.6, 2.7.
+
+Ca prend forme. Tu peux donner l'intuition de la compilation. Dans le source, on
+melange les der, present, up, etc. et le compilo., apres une analyse statique
+(qui va verifier des proprietes et donc rejeter certains programmes), va
+produire les differentes fonctions necessaires a la simulation qui alterne des
+phases d'integration (le temps ronronne) et des pas discrets (reactions
+instantanees).
+
+Super. Continue ! --Marc
+
+