NEW: 1903: adding files

1903/Makefile

+include share/make/share.mk
+include share/make/tex.mk
+
+all: slides.pdf
+
+clean:
+	${RM} slides.pdf* tmp*

1903/biblio.bib

+@InProceedings{   levillain.14.ciarp,
+  author        = {Roland Levillain and Thierry G\'eraud and Laurent Najman
+                  and Edwin Carlinet},
+  title         = {Practical Genericity: Writing Image Processing Algorithms
+                  Both Reusable and Efficient},
+  booktitle     = {Progress in Pattern Recognition, Image Analysis, Computer
+                  Vision, and Applications -- Proceedings of the 19th
+                  Iberoamerican Congress on Pattern Recognition (CIARP)},
+  address       = {Puerto Vallarta, Mexico},
+  month         = nov,
+  year          = {2014},
+  pages         = {70--79},
+  editor        = {Eduardo Bayro and Edwin Hancock},
+  publisher     = {Springer-Verlag},
+  series        = {Lecture Notes in Computer Science},
+  volume        = {8827},
+  lrdeprojects  = {Olena},
+  abstract      = {An important topic for the image processing and pattern
+                  recognition community is the construction of open source
+                  and efficient libraries. An increasing number of software
+                  frameworks are said to be generic: they allow users to
+                  write reusable algorithms compatible with many input image
+                  types. However, this design choice is often made at the
+                  expense of performance. We present an approach to preserve
+                  efficiency in a generic image processing framework, by
+                  leveraging data types features. Variants of generic
+                  algorithms taking advantage of image types properties can
+                  be defined, offering an adjustable trade-off between
+                  genericity and efficiency. Our experiments show that these
+                  generic optimizations can match dedicated code in terms of
+                  execution times, and even sometimes perform better than
+                  routines optimized by hand. Digital Topology software
+                  should reflect the generality of the underlying
+                  mathematics: mapping the latter to the former requires
+                  genericity. By designing generic solutions, one can
+                  effectively reuse digital topology data structures and
+                  algorithms. We propose an image processing framework
+                  focused on the Generic Programming paradigm in which an
+                  algorithm on the paper can be turned into a single code,
+                  written once and usable with various input types. This
+                  approach enables users to design and implement new methods
+                  at a lower cost, try cross-domain experiments and help
+                  generalize results.},
+  keywords      = {Generic Programming, Image Processing, Performance,
+                  Olena},
+  lrdepaper     = {http://www.lrde.epita.fr/dload/papers/levillain.14.ciarp.pdf},
+  lrdeslides    = {http://www.lrde.epita.fr/dload/papers/levillain.14.ciarp.slides.pdf},
+  lrdenewsdate  = {2014-09-10}
+}
+
+@InProceedings{	  roynard.18.rrpr,
+  title		= {An Image Processing Library in Modern {C++}: Getting
+		  Simplicity and Efficiency with Generic Programming},
+  author	= {Micha\"el Roynard and Edwin Carlinet and Thierry G\'eraud},
+  booktitle	= {Proceedings of the 2nd Workshop on Reproducible Research
+		  in Pattern Recognition (RRPR)},
+  year		= {2018},
+  abstract	= {As there are as many clients as many usages of an Image
+		  Processing library, each one may expect different services
+		  from it. Some clients may look for efficient and
+		  production-quality algorithms, some may look for a large
+		  tool set, while others may look for extensibility and
+		  genericity to inter-operate with their own code base... but
+		  in most cases, they want a simple-to-use and stable
+		  product. For a C++ Image Processing library designer, it is
+		  difficult to conciliate genericity, efficiency and
+		  simplicity at the same time. Modern C++ (post 2011) brings
+		  new features for library developers that will help
+		  designing a software solution combining those three points.
+		  In this paper, we develop a method using these facilities
+		  to abstract the library components and augment the
+		  genericity of the algorithms. Furthermore, this method is
+		  not specific to image processing; it can be applied to any
+		  C++ scientific library.}
+}
+
+
+@InProceedings{demaille.13.ciaa,
+  author        = {Akim Demaille and Alexandre Duret-Lutz and Sylvain
+                  Lombardy and Jacques Sakarovitch},
+  title         = {Implementation Concepts in {V}aucanson 2},
+  booktitle     = {Proceedings of Implementation and Application of Automata,
+                  18th International Conference (CIAA'13)},
+  pages         = {122--133},
+  year          = 2013,
+  editor        = {Stavros Konstantinidis},
+  publisher     = {Springer},
+  isbn          = {978-3-642-39274-0},
+  volume        = 7982,
+  series        = {Lecture Notes in Computer Science},
+  address       = {Halifax, NS, Canada},
+  month         = jul,
+  lrdeprojects  = {Vaucanson},
+  abstract      = {Vaucanson is an open source C++ platform dedicated to the
+                  computation with finite weighted automata. It is generic:
+                  it allows to write algorithms that apply on a wide set of
+                  mathematical objects. Initiated ten years ago, several
+                  shortcomings were discovered along the years, especially
+                  problems related to code complexity and obfuscation as well
+                  as performance issues. This paper presents the concepts
+                  underlying Vaucanson 2, a complete rewrite of the platform
+                  that addresses these issues.},
+  lrdeinc       = {demaille.13.ciaa.inc},
+  lrdeslides    = {http://www.lrde.epita.fr/dload/papers/demaille.13.ciaa.slides.pdf},
+  lrdepaper     = {http://www.lrde.epita.fr/dload/papers/demaille.13.ciaa.pdf},
+  lrdenewsdate  = {2013-05-02}
+}

1903/slides.tex

+\documentclass[bigger]{beamer}
+
+\usepackage[utf8]{inputenc}
+\usepackage[T1]{fontenc}
+\usepackage[francais]{babel}
+\usepackage{wrapfig}
+\usepackage{hyperref}
+\usepackage{booktabs}
+\usepackage{tabularx}
+
+\usetheme{KremlinBicetre}
+
+\renewcommand{\maketitle}
+{%
+    \begin{frame}
+        \titlepage%
+        \vspace{-10mm}%
+        \begin{flushright}%
+            \includegraphics[width=3cm]{figs/lrde-big}%
+        \end{flushright}%
+    \end{frame}%
+}
+
+\date[14-02-2019]{Lightning Talk: Feb 14}
+\author{Célian \textsc{Gossec}}
+\title[Le pont statique-dynamique]{Le pont statique-dynamique}
+\institute[LRDE]{LRDE\\Laboratoire de Recherche et Développement de l'EPITA}
+
+\renewcommand{\footnotesize}{\fontsize{6pt}{8pt}\selectfont}
+
+
+
+\begin{document}
+\maketitle
+
+\begin{frame}
+  \frametitle{La situation}
+
+    \structure{Point de départ.} Milena, une bibliothèque \emph{générique et performante} de traitement d'image codée en
+      C++.
+      \footnote{\tiny Practical Genericity : Writing Image Processing Algorithms Both Reusable and Efficient.
+      R. Levillain et al., \textit{ICPR'14}.}
+    \footnote{\tiny An Image Processing Library in Modern C++: Getting Simplicity and Efficiency with Generic Programming.
+      M. Roynard, E. Carlinet, T. Géraud, \textit{RRPR'18}.}
+
+  \begin{center}
+
+    \setlength{\fboxsep}{0pt}
+\begin{tabular}{cccc}
+ & \tiny image 2D & \tiny graph & \tiny mesh \\
+ \tiny in: & \fbox{\includegraphics[width=.15\linewidth]{figs/geninput-000b}} &
+ \fbox{\includegraphics[width=.15\linewidth]{figs/geninput-001b}} &
+ \fbox{\includegraphics[width=.15\linewidth]{figs/geninput-002b}} \\
+ %
+ \tiny out: & \fbox{\includegraphics[width=.15\linewidth]{figs/genoutput-000}} &
+ \fbox{\includegraphics[width=.15\linewidth]{figs/genoutput-001b}} &
+ \fbox{\includegraphics[width=.15\linewidth]{figs/genoutput-002b}} \\
+ \end{tabular}
+\end{center}
+
+
+    \structure{Objectif.} Faciliter l'usage d'Olena.\\[2pt]
+\end{frame}
+
+
+\begin{frame}
+    \structure{Moyen.} Exposer Olena en Python.
+
+    \bigskip
+    \bigskip
+
+    \structure{Difficultés.}
+    \begin{itemize}
+      \item Appeler du code \textit{statique} (templates) depuis un environnement \textit{dynamique}\\
+      \item Compatibilité avec Numpy
+      \end{itemize}
+\end{frame}
+
+\begin{frame}
+    \frametitle{Les différentes possibilités}
+        \begin{itemize}
+                \item La compilation à la volée (Just-In-Time)
+                \item Polymorphisme de coercition
+                \item L'effacement de type
+        \end{itemize}
+\end{frame}
+
+\begin{frame}
+        \frametitle{Approche 1 : Les compilateurs JIT}
+        Compilateurs JIT = compilation à la volée. \newline
+        Principe utilisé dans Vcsn\footnote{\tiny Implementation Concepts in {V}aucanson 2. A. Demaille et al.,
+          \textit{CIAA'13}}
+
+        \bigskip
+
+
+                \begin{tabularx}{\linewidth}{>{\parskip1ex}X@{\kern4\tabcolsep}>{\parskip1ex}X}
+                  %\toprule
+                        \hfil\bfseries \includegraphics[width=.7cm]{figs/angrygreen}
+                        &
+                        \hfil\bfseries \includegraphics[width=.7cm]{figs/angryred}
+                        \\\cmidrule(r{3\tabcolsep}){1-1}\cmidrule(l{-\tabcolsep}){2-2}
+
+                        Aussi rapide que le C++ (après la 1\iere compilation) \par
+
+                        &
+                        \parbox{\linewidth}{
+                        1\iere compilation lente \\[10pt]
+                        Nécessite un compilateur \\[10pt]
+                        Pas d'export NumPy\\ (par défaut) \par
+                        }
+                \\ %\bottomrule
+                \end{tabularx}
+\end{frame}
+
+\begin{frame}
+        \frametitle{Approche 2 : Polymorphisme de coercition}
+        Approche utilisée par Matlab \newline
+        Un type plus large qui englobe tous les types désirés.
+
+        \bigskip
+
+        \begin{tabularx}{\linewidth}{>{\parskip1ex}X@{\kern4\tabcolsep}>{\parskip1ex}X}
+          %\toprule
+          \hfil\bfseries \includegraphics[width=.7cm]{figs/angrygreen}
+          &
+          \hfil\bfseries \includegraphics[width=.7cm]{figs/angryred}
+          \\\cmidrule(r{3\tabcolsep}){1-1}\cmidrule(l{-\tabcolsep}){2-2}
+
+          Traitement d'un seul type rend facile l'exportation
+          vers Python \par
+
+          &
+
+          Limitation de la généricité \par
+          Perte de performance \par
+          \\ %\bottomrule
+        \end{tabularx}
+\end{frame}
+
+\begin{frame}
+        \frametitle{Approche 3: Effacement de type}
+        Type erasure = Type opaque avec une interface d'image.
+
+        \bigskip
+
+        \begin{tabularx}{\linewidth}{>{\parskip1ex}X@{\kern4\tabcolsep}>{\parskip1ex}X}
+          %\toprule
+          \hfil\bfseries \includegraphics[width=.7cm]{figs/angrygreen}
+          &
+          \hfil\bfseries \includegraphics[width=.7cm]{figs/angryred}
+          \\\cmidrule(r{3\tabcolsep}){1-1}\cmidrule(l{-\tabcolsep}){2-2}
+          Un seul type rend facile l'exportation
+          vers Python
+          &
+          Grosse perte de performance
+          \\%\bottomrule
+        \end{tabularx}
+
+\end{frame}
+
+\begin{frame}
+  \frametitle{Notre objectif : une approche hybride}
+  Fournir une type effacé avec interface d'image qui puisse être utilisé avec
+    numpy\footnote{\tiny https://github.com/pybind/pybind11},
+
+  mais \ldots
+
+  \pause
+  \medskip
+
+  \begin{itemize}
+    \item capable de se ``caster'' vers les types concrets (instancier des algortihmes par JIT)
+    \item capable de se ``convertir'' vers des types concrets (utiliser des algorithmes pré-définis)
+    \end{itemize}
+
+  \bigskip
+  pour récupérer la performance.
+\end{frame}
+
+\begin{frame}
+        \frametitle{Bibliographie}
+        \scriptsize
+        \nocite{levillain.14.ciarp, roynard.18.rrpr, demaille.13.ciaa}
+        \bibliography{biblio}
+        \bibliographystyle{apalike}
+\end{frame}
+
+\end{document}