relecture calcul différentiel II

[parmentelat]

j'ai fait moi-même les corrections de typos

pour le code, je te laisse regarder les quelques commentaires qui restent, et le notebook qui allait avec;

ps: je suis étonné que le code soit embarqué dans le markdown, pourquoi pas un notebook en fait ? bon bien sûr c'est trop tard pour ce coup-ci..

[boisgera]

OK, super.

Pour le format, vaste question :). En gros: comme format de document (hors "code exécutable"), je trouve les notebooks Jupyters un peu pauvres (support footnotes, biblio, etc.) et la qualité (typo, layout, etc.) et configurabilité des backends (notebooks, PDF, HTML, etc.) relativement médiocre[*] ; sans parler de la chaîne outillée pour analyser/transformer les documents le cas échéant (coté "power user").

Dans un contexte ou la majorité des chapitres à pas ou peu de code (le chapitre II est plutôt une exception), produire un PDF par exemple qui soit beaucoup plus moche que le look standard de fait pour les cours de Maths (LaTeX) et en perdant trop de fonctionnalités utiles me semblait un show-stopper (ni souhaitable, ni "vendable" aux co-auteurs par exemple).

Ca m'est arrivé par contre de générer des notebooks Jupyter -- toujours à partir de markdown -- pour des cours avec beaucoup plus de code ; mais des slides "classiques" (reveal.js + PDF) sont alors générés en parallèle: https://github.com/boisgera/control-engineering-with-python-extra. Les notebooks étant alors utilisés en travaux pratiques. Best of both worlds.

Et en live, on utilisera un notebook (vierge) ; c'est toujours un très bon support pour l'interactif / expérimental à mon avis et dans ce cas, c'est litéralement un "notebook" qu'on produit.

[*]: https://observablehq.com/ est beaucoup plus plaisant esthétiquement par exemple ; ça aide que les auteurs fassent partie de l'équipe de graphic design du NYT j'imagine ... Le "jupyterlab" a un peu progressé de ce point vue toutefois.

[parmentelat]

Perso je trouve le format pdf totalement anachronique; c’est chacun ses goûts :)

Observable c’est tres bien pour faire du javascript et de la visu à la d3.js mais pour nos cours ça parait d’un usage anecdotique - je suis dac toutefois que quand le sujet s’y prête c’est très impressionnant comme rendu (et à ma connaissance Mike Bostock n’est plus au NYT depuis un paquet d’années maintenant)

Pour recentrer sur le sujet initial; j’ai fait un seul changement dans ton code pour enlever une vilaine compréhension ;) si quelque chose foire ça ne peut être que ça d’après moi...

Je n’ai pas vraiment d’acces hors mail aujourd’hui

Sent from my iPhone

On 20 Aug 2019, at 10:21, Sébastien Boisgérault notifications@github.com wrote:

OK, super.

Pour le format, vaste question :). En gros: comme format de document (hors "code exécutable"), je trouve les notebooks Jupyters un peu pauvres (support footnotes, biblio, etc.) et la qualité (typo, layout, etc.) et configurabilité des backends (notebooks, PDF, HTML, etc.) relativement médiocre[*] ; sans parler de la chaîne outillée pour analyser/transformer les documents le cas échéant (coté "power user").

Dans un contexte ou la majorité des chapitres à pas ou peu de code (le chapitre II est plutôt une exception), produire un PDF par exemple qui soit beaucoup plus moche que le look standard de fait pour les cours de Maths (LaTeX) et en perdant trop de fonctionnalités utiles me semblait un show-stopper (ni souhaitable, ni "vendable" aux co-auteurs par exemple).

Ca m'est arrivé par contre de générer des notebooks Jupyter -- toujours à partir de markdown -- pour des cours avec beaucoup plus de code ; mais des slides "classiques" (reveal.js + PDF) sont alors générés en parallèle: https://github.com/boisgera/control-engineering-with-python-extra. Les notebooks étant alors utilisés en travaux pratiques. Best of both worlds.

Et en live, on utilisera un notebook (vierge) ; c'est toujours un très bon support pour l'interactif / expérimental à mon avis et dans ce cas, c'est litéralement un "notebook" qu'on produit.

[*]: https://observablehq.com/ est beaucoup plus plaisant esthétiquement par exemple ; ça aide que les auteurs fassent partie de l'équipe de graphic design du NYT j'imagine ... Le "jupyterlab" a un peu progressé de ce point vue toutefois.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[boisgera]

Je suis d'accord avec toi pour le PDF (comme format électronique, beurk, pour moi c'est transitionnel et il faut aller vers HTML ; je l'ai fait en proto par le passé, mais sur ce cours ça n'est pas l'urgence ; il me suffit de savoir que la stack s'y prête pour le futur). Mais on a (encore ?) plein de clients pour l'impression papier.

Sur le code je vais essayer de jeter un oeil ... j'ai une petite idée.

[boisgera]

C'est bien ce que je pensais: ma version du code à commencé comme la tienne, sans la liste dans any(...). Mais le "any" de numpy qui est utilisé ici, est un peu concon (ou une subtilité m'échappe) et ne fait pas ce qu'il faut avec les générateurs (contrairement au any des builtins). Comme les symboles de numpy sont importés globalement dans le document, j'ai utilisé any([...]) ... pas beau, mais ça marche :)

[parmentelat]

Ah d’accord je me suis laissé abuser par cet any sans np.

C’est de ma faute je m’étais bien promis de ne pas toucher au code mais je me suis dit, quand même, on ne peut pas laisser ça

« Wizards should know better » ;)

Sent from my iPhone

On 20 Aug 2019, at 13:35, Sébastien Boisgérault notifications@github.com wrote:

Comme les symboles de numpy sont importés globalement dans le document, j'ai utilisé any([...]) ... pas beau, mais ça marche :)