Tu peux faire du javascript sur Arduino.
http://johnny-five.io/
Ça me fait penser que mes étudiants pourraient bosser au CERN : https://root.cern.ch/cling
Attention, un Max_well peut en cacher un autre
Equipe Highlander La Rache
Ah ben, en FORTRAN 7 pas de prototype de fonction, à toi de faire gaffe à la liste et aux types d'argument. Tu tep lantes --> exploration de la pile.
ALORS TE PLAINT PAS
Natif dans le sens où les commandes et syntaxes spécifiques à la parallélisation font partie du langage. Pas besoin d'utiliser OpenMP avec les commentaires à ajouter dans le code...
Mais c'est pas forcément plus simple ou plus efficace hein
C'est dans le standard fortran depuis Fortran 2008. Les compilateurs commencent à l'implémenter. La librairie inclue dans gfortran permet de compiler les programmes parallèles, mais ne peut faire tourner qu'une seule image
Je connais seulement la librairie OpenCoArrays pour gfortran qui implémente certains trucs du draft fortran 2015, comme la gestion des signaux entre les différentes images.
Non, ça ce sont les data scientistes, il manque juste un doctorat
- - - Mise à jour - - -
Dans toutes les ENSI, t'as des étudiants en filière généraliste qui passent à travers les grilles alors qu'ils ont rien panné en info.
De toute manière, si tu ne peux pas mettre moins de 12 à une copie blanche sans prendre une soufflante de la scolarité, tu te doutes bien que ça encourage la fainéantise.
lolno c'était en effet des 'scientists' du CERN. Là bas même les cuisiniers et les femmes de ménage ont un doctorat.
Donc du C++ et une grosse couche en python pour rendre le tout digeste.
Un petit commentaire tiré de là
Mario Alemi, former Physicist at CERN (1994-2000)
I worked at CERN (as a physicist) from 1995 to 2000.
Back then, I didn’t like to be “forced” to use FORTRAN, which at the time I perceived as old. I wanted to do C++.
So I started using ROOT. I was eager to learn C++. I took courses, read Bjarne Stroustrup’s book.
And then asked myself –was the LSD so strong, ROOT people wanted us to use C++ as scripting language??
Mais en fait je m'en fous un peu, je fais du Java, forcé de faire du C, et aspirant à faire du Kotlin
Pour les curieux voici la classe pour faire un pauvre histogramme:
https://root.cern.ch/root/html520/TH1.html
"Les faits sont têtus."
d'où le python avec PyROOT (heureusement que c'était pas du Visual Basic, ça aurait fait Visual B-ROOT ...)
Et pour les jeux de mot foireux il y a son compagnon, pypyroot.
Merki mais c'est pas simple non plus.
Sinon, ROOT, j'ai déjà donné et c'est bien de la merde
haha c'est génial.
Je vais poser une question beaucoup plus terre à terre.
Je suis un peu à la rue sur les choses à faire (ou ne surtout pas faire) pour chiffrer une chaîne de caractères. Je lis un peu tout et n'importe quoi sur le sujet et autant je peux écarter les solutions qui sentent bon l'amateurisme (ie. "tu transformes en base64 puis tu fais un chiffrement de César"), autant je ne sais pas pondérer une solution qui à l'air viable par rapport à une autre.
Par exemple, la solution mise en avant sur ce post me semble pas mal. Vous confirmez mes impressions ?
Le contexte consiste à chiffrer en C# des logs applicative qui peuvent parfois contenir des données sensibles et qui sont sauvegardées sur Azure (cette contrainte n'est pas modifiable). Ce n'est pas une application critique, mais si on peut avoir une bonne base pour une utilisation plus poussé, cela sera intéressant. On a déjà pensé à éviter de loguer ces fameuses données sensible, mais le type de données pourra être amené à évoluer régulièrement, cela va rapidement devenir inmaintenable.
Tu as plusieurs méthodes pour chiffrer des données, si on reste sur du symétrique tu as entre autres :
- Code de César, ou chiffrement par décalage : tu augmentes/diminues d'une certaine valeur le code de chaque caractère. Même si tu peux aller au-delà de 26, après tout tu n'es pas limité à l'alphabet, c'est un peu moisi
- Chiffrement par substitution : le principe est d'associer à chaque lettre une autre lettre, les possibilités sont déjà grandes, cependant si une personne mal intentionnée a mis la main sur un message chiffré et a une idée précise de la langue d'origine il lui sera aisé de faire des suppositions basées sur la fréquence d'apparition des lettres, ce qui fait que c'est loin d'être impossible à chiffrer
- Chiffre de Vigenère : c'est le même principe que le Code de César, mais au lieu de décaler tous les caractères en utilisant une unique valeur, tu décales en fonction du caractère courant dans un mot ou une phrase. On peut déjà
aller assez loin en termes de possibilités, et il est plus difficile de reconnaître la langue d'origine du message
L'avantage des chiffrements symétriques étant que c'est rapide en termes d'exécution.
J'ai mis au point un petit outil de chiffrement symétrique qui tape dans les 100 mo/s, en étant limité par le disque dur et sans trop tirer sur le CPU. Si j'étais sur Ramdisk, je pense que je pourrais monter bien plus haut.
L'inconvénient, évidemment, c'est qu'il faut la même clé pour chiffrer et déchiffrer un message.
Après, tu as l'asymétrique, qui offre l'avantage de proposer une clé différente pour le chiffrement et le déchiffrement, mais le traitement est un peu plus lourd.
Il parait aussi qu'avec les ordinateurs quantiques, le RSA se fera démolir la face, mais pour l'instant les fameux ordinateurs quantiques ne vont pas assez loin en calcul pour représenter un réel danger.