Commentaires

Modifié, simplement parce que j'avais oublié de simplifier le "else", je suis un peu fatigué sans doute.

Salut Pierre,

Probablement des choses à rattraper

Salut Denis

Envoyé par User

Sympa ! il faudra que je me mette aussi à julia

C'est fou cette soif qu'on a d'apprendre encore et encore...

Sympa ! il faudra que je me mette aussi à julia

Pour améliorer ton code, tu peux regarder du côté des DefaultDict, dans DataStructures.jl : https://juliacollections.github.io/D.../default_dict/

Je trouve plus joli d'écrire key in keys(dict) que d'utiliser haskey, mais c'est une histoire de goût.

Pour mettre une valeur dans un dictionnaire, tu peux l'indexer directement sans passer par push! :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
julia>  d = Dict()
Dict{Any, Any}()

julia> d[1] = [1]
1-element Vector{Int64}:
 1

julia> d
Dict{Any, Any} with 1 entry:
  1 => [1]

Pour diminuer l'utilisation de mémoire, tu ne dois stocker que deux nombres par matière : le nombre de notes et le total (plutôt que de stocker toutes les notes indépendamment). La moyenne se fait avec la division du total par le nombre de notes.

Envoyé par Pogzy

Je me demande bien comment ils faisaient avant, qu'elles technos utilisait le système précédent, qui devait être une vieillerie s'il a été réécri

C'est précisé dans la source, prototypage sous Matlab, puis ré-écriture en C++.
Forcément ,quand on fait sauter une étape (surtout en remplaçant un outil "lent" et un langage "complexe" -- je mets des guillemets pour la relativité de l'adjectif entre), c'est plus rapide à mettre en place!

Je me demande bien comment ils faisaient avant, qu'elles technos utilisait le système précédent, qui devait être une vieillerie s'il a été réécri

Pour préciser : il y a beaucoup de compléments à Unitful.jl destinés à des domaines d'application pas forcément génériques.

Par contre, je ne pense pas qu'on puisse encore conseiller des paquets comme Units.jl (https://github.com/timholy/Units.jl).

Il s'agit de : trouver la position et la longueur de la plus longue séquence de lettres minuscules d'un mot de passe.

Le titre du billet est bloqué, impossible de mettre le titre complet.

Excellent ! Et comme dans d'autres rubriques, tu peux proposer des exercices, et même des Quiz pour s'entraîner sur Julia.

C'est bien parti, bonne continuation

L'exemple que tu reprends, outre son âge (depuis 2016, Julia a énormément évolué, mais globalement les résultats n'ont pas changé dans ce cas), parle d'un cas un peu différent : donner des types quand on est sûr de ce qu'on va y stocker. L'idéal serait plutôt d'écrire le code avec des paramètres comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
function count_numbers(v::Vector{T}) where T
    n = length(v)
    d = Dict{T, Int}()
    for i = 1:n 
        d[v[i]] = get(d, v[i], 0) + 1
    end 
    return d 
end

count_numbers2 est une écriture très foireuse : Julia ne râlera pas lors de l'appel de la fonction avec un vecteur de nombres à virgule flottante, mais ça plantera lors de l'ajout dans le dictionnaire… Mon code évitera ce problème, tout en ayant une performance similaire (d'après mes tests préliminaires avec la version 1.5.0, ça prend le même temps et un peu moins de mémoire que count_numbers2). Surtout, on peut utiliser cette fonction avec d'autres types de nombres ou même autre chose (un vecteur de distributions de probabilités, par exemple), ce qui n'est pas du tout le cas avec count_numbers2.

Je ne suis pas encore assez compétent en Julia pour discuter de ce sujet avec toi, mais j'ai trouvé une référence de 2016.

Performance and Concrete Types in Julia posted by PAUL STEY on JULY 20, 2016

Extrait de la fin de cet article :

Les résultats ci-dessus sont vraiment frappants. En termes de vitesse, nous voyons que notre version de type concret de la fonction est environ 4x plus rapide que notre version de type non concret (d'ailleurs, c'est environ 14x plus rapide que Python pour des vecteurs de longueur 10 millions). Nous notons également que la vitesse évolue linéairement (ou un peu mieux) avec la taille d'entrée.

Mais ce que je trouve fascinant, c'est que nos allocations et notre utilisation de la mémoire sont en fait constantes par rapport à la taille d'entrée! Dans notre version non concrète, notre appel de fonction alloue 300 Mo de mémoire sur le vecteur de longueur 10 millions; et la version de type béton n'utilise que 768 octets .

Cela m'a bouleversé quand je suis tombé dessus. Cela ressemble fondamentalement à de la magie. La leçon ici semble claire: lorsque les performances sont critiques, faites tout ce que vous pouvez pour utiliser des types concrets.

Plus vous utilisez votre système de typage, plus il fonctionne pour vous.

… et, moins on utilise le système de typage, mieux Julia fonctionne ! C'est comme ça qu'on peut résoudre des équations différentielles sur des nombres complexes ou des erreurs de mesure, par exemple. Si DifferentialEquations.jl (entre autres) forçaient à utiliser des Float64 partout, ça ne pourrait pas marcher aussi bien.

Merci ! C'est modifié. Pour le fichier HTML il faut sans doute effacer le cache du navigateur pour voir la nouvelle version.

Petite remarque concernant le titre (billet et fichier HTML) : tu fais un ajustement de courbe, pas l'inverse .

@dourouc05 : bonjour mon ami, un grand merci pour tes critiques constructives. J'en ai tenu compte dans la nouvelle version de la solution proposée.

L'énoncé de l'exercice est réel, les fonctions et leurs ordres de test sont explicitement demandés (voir : https://www.developpez.net/forums/d2.../#post11464396)

Tu devrais nommer les variables d'instance tout en bas de casse (https://www.python.org/dev/peps/pep-...variable-names), vu que tout le code Python respecte la norme PEP8 (l'un des très rares langages avec un guide stylistique commun !). Aussi, pour cacher ces variables d'instance, ça serait mieux de commencer leur nom avec un _, histoire d'indiquer clairement que ces variables ne sont pas censées accessibles en dehors de la classe elle-même : en dehors du module, ça devient difficile d'y accéder directement, il ne reste que l'interface que tu définis.

Ça donnerait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class Produit:
    def __init__(self, code, nom, prix):
        self._code = code
        self._nom = nom
        self._prix = prix
 
    @property
    def code(self):
        return self._code
 
    @property
    def nom(self):
        return self._nom
 
    @property
    def prix(self):
        return self._prix
 
    @Prix.setter
    def prix(self, prix):
        self._prix = prix

Ensuite, pour le reste de la solution, je ne suis pas du tout convaincu par tes fonctions saisir_. En fait, il s'agit juste d'appeler un constructeur, alors que ta spécification de ces fonctions est : "Écrire une fonction saisir_ qui permet à l’utilisateur de saisir…" Je m'attendrais plus à l'utilisation de input(), vu la spécification.

afficher_produit ne devrait pas être une fonction indépendante, mais plutôt une méthode de la classe Produit, plus précisément nommée __str__ pour suivre les normes de Python (https://stackoverflow.com/a/2626364/1066843). Ainsi, afficher le produit avec un print te donnera directement la bonne chaîne. D'ailleurs, ton implémentation ne correspond pas à ta spécification : tu devrais afficher une chaîne de caractères et non en retourner une.

Bonjour moi j'ai un problème avec le langage c

Bien vu, merci.

Une erreur de débutant en Python, oublier le +1 : for index in range(n, len(brin)+1, n):