J'ai un travail a faire que je dois rendre en C, mais que j'ai écris au Python car c'est un des seuls langages que je maitrise pour l'instant..
Le problème est que je n'ai aucune idée de comment faire un intervalle en C, voici ce que ca donne en Python (après for i in range([...])) et que variable est un argument de la fonction:
if variable[i:i+4] == 8:
J'espere que quelqu'un comprendra et saura m'aider!
Merci.
- Edité par agsouywgdhvde 27 octobre 2019 à 23:55:45
Manipuler des trucs primitifs permet d'avoir un programme plus efficace. C'est pour ça que l'assembleur est encore plus rapide. Mais l'assembleur est trop primitif pour moi. Je trouve que le langage C est un juste milieu.
Je m'étais amusé à apprendre le Python il y a quelques années et j'ai adoré. Suite à une discussion dans le forum Python juste à côté (un problème de parcours de listes pour trouver des nombres particuliers), j'ai compris à quel point les listes de Python étaient lentes à parcourir (apparemment ce sont des listes chaînées), et comme j'aime la vitesse, je n'aime plus Python - trop civilisé pour moi...
Je ne paie pas pour le temps CPU de mon ordi personnel.
C'est idio ce que tu dis, c'est a cause de ce genre de reflexion qu'on a des tellephones 8 cores, avec 32 G de ram mais qui finissent par être moins perforamant qu'un raspberry.
Je ne veux pas revenir aux ordinateurs à transistors "discrets" ou à lampes.
Peux-tu écrire ton code en moins de lignes sans que les performances deviennent affreuses?
Ça donnerait quoi s'il y avait 100 possibilités au lieu de 5?
Surtout qu'il s'agit d'un intervalle, pas de valeurs discontinues.
Bien sur que l'on peut:
/* 0 = au moins une valeur ne respecte pas la condition
* 1 = toutes les valeurs respectent la condition imposée
*/
int testeIntrvalle(int * values, int count){
for(int i = 0; i< count;++i){
if(values[i] != 8)
return 0;
}
return 1;
}
- Edité par koala01 29 octobre 2019 à 1:00:14
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Et quelque chose du genre? for (ok=1, i=0; i < 100; i++) if (variable[i] != 8) { ok=0; break; } if (ok) {...} Pour ox223252: Mon code est-il lamentablement moins efficace que le tien? Avec l'option -O9 ça ne devrait pas être troop affreux. Je n'ai écris que deux lignes pour 100 valeurs (sauf le code exécuté ensuite). Ça t'aurait pris combien de temps pour écrire ton code pour 100 valeurs? Je crois savoir que tu as une Lamborghini immatriculée 8086K, je n'ai qu'une Ferrari immatriculée 4790K.
Le Tout est souvent plus grand que la somme de ses parties.
La fonction est compliquée a comprendre mais en revanche la condition fait que j'aimerai prendre toutes les valeurs compris entre i et i+4 qui sont égales a 8 provenants de value (j'ai peut être mal expliqué ?)
Et enfin non le code python marche comme je le souhaite (évidemment la fonction toute entière n'est pas écrite)*
Prendre les valeurs, ca veut rien dire. Tu veux en faire quoi, de tes 8 ?
Et d'abord, value, c'est quoi ? Quel type ?
PS @koala01
/* 0 = au moins une valeur ne respecte pas la condition
* 1 = toutes les valeurs respectent la condition imposée
*/
int testeIntrvalle(int * values, int count){
C'est pas comme si on avait le type bool en C, depuis 20 ans :-)
for (ok=1, i=0; i < 100; i++)
if (variable[i] != 8) { ok=0; break; }
if (ok) {...}
Pour ox223252:
Mon code est-il lamentablement moins efficace que le tien?
Avec l'option -O9 ça ne devrait pas être troop affreux.
C'est pas au niveau du code généré que c'est affreux, vu que le compilateur est assez malin pour reconnaitre la situation et générer le même code.
C'est au niveau du code source, qui est moins lisible, parce que les chemins d'exécution sont plus compliqués. Si on trouve une valeur différente de 8 quelque part on
positionne un indicateur, ajouté au programme pour la circonstance
sort de la boucle par un break
teste cet indicateur
en fonction de ça retourne 1 ou 0
On peut pas dire que ça soit simple (c'est relatif, voir les autres solutions et comparer).
Donc ça fait perdre du temps aux programmeurs (ceux qui écrivent et ceux qui relisent), et comme tu le fais remarquer, c'est ça qui coûte cher.
Déjà on pourrait décider
de nommer la fonction correctement. Elle repond vrai quand il y a seulement des 8, donc contientSeulementDesHuits
lui faire retourner un boolean
utiliser un boolean comme variable à retourner
s'en servir dans le controle de la boucle
Version 1
bool contientSeulementDesHuits (int taille,
int tableau[])
{
boolean ok = true;
for (int i=0; ok && (i < taille); i++) {
ok = (tableau[i] == 8);
}
return ok;
}
Version 2 : sortir dès qu'on peut conclure
bool contientSeulementDesHuits (int taille,
int tableau[])
{
for (int i=0; i < taille; i++) {
if (tableau[i] != 8) {
return false;
}
return true;
}
---
enfin, le compilateur sait faire du dépliage de boucle. Le code suivant
Celle du processeur qui est optimisée en assembleur, et celle du programmeur qui fera le moins de choses possible pour avoir le même résultat.
Je ne paie pas pour le temps CPU de mon ordi personnel.
Mais il existe des situations où le temps CPU est primordial. C'est pour ça, j'imagine, qu'il existe de nombreux langages, les situations pouvant être très diverses.
Comme je l'ai dit, j'ai programmé en assembleur sur des machines peu rapides avec de petites mémoires. C'était essenciel de le faire ainsi.
Mais je voulais insister sur le fait que le temps "humain" que l'on dépense n'est pas négligeable non plus.
Prenons Linux. Il a des possibilités très puissances. Si tu passes une semaine pour écrire du code alors que Linux avec sa multitude d'outils peut le faire en quelques secondes et te demande un minimum de travail, n'est-il pas mieux de "sacrifier" du CPU plutôt que ton temps?
Je croyais que les ordinateurs étaient justement là pour nous sauver du travail plutôt que nous en donner pour les ménager, ces pauvres petites bêtes de travail!
Le Tout est souvent plus grand que la somme de ses parties.
n'est-il pas mieux de "sacrifier" du CPU plutôt que ton temps?
Ce que je disais, c'est que ça dépend des situations. Si j'écris un interpréteur Python, ça serait probablement plus vite fait en Python lui même, mais l'interpréteur ne risque-t-il pas d'être plus rapide écrit en assembleur, ou même en C ? Si oui, peut-être que ça vaut le coup de passer du temps à l'optimiser dans un langage qui le permet...
C'est pas seulement que ça serve tout le temps, il faut aussi que ça soit _critique_. Gratter 10% sur un truc qui dure un dixième de seconde, même si on le lance 100 fois par jour, ça justifie combien d'heures de travail supplémentaires ?
Ca ne veut pas dire qu'il faut programmer comme des gorets. Au contraire. Si c'est un truc qui sert souvent, il y des chances qu'on ait besoin de le faire évoluer assez souvent, donc il faut que le code soit écrit de façon à être maintenu facilement. Parce que le temps de développeur perdu à se retrouver dans un code mal foutu, ça coute beaucoup plus que les microsecondes CPU gaspillées.
Et puis il n'y a pas de langage performant en soi. Il y a des langages qui permettent d'avoir des programmes performants, quand ils sont utilisés par des gens compétents et qui y consacrent l'effort nécessaire.
ps: quand je parle d'effort, c'est l'effort _supplémentaire_ accordé aux questions d'optimisation. Parce qu'il ne suffit de se contenter d'écrire un truc en C, en s'emmerdant bien par exemple avec les chaines parce que c'est une galère en C, pour que le programme soit efficace (1). Il faut en plus, sérieusement, faire des mesures pour comparer des versions et déterminer laquelle est la meilleure.
(1) je pense à cette manière de faire une boucle sur une chaine, preuve qu'on peut écrire des choses complètement inefficaces en C
for (size_t i=0; i < strlen(chaine); ++i) {
...
}
- Edité par michelbillaud 30 octobre 2019 à 8:32:48
Même si on pense qu'un programme ne servira qu'une fois, ça ne veut pas dire que ça doit être un torchon.
Cependant, je pense qu'on mettra moins de temps à optimiser un programme qu'on ne souhaite utiliser qu'une fois.
On a parfois la surprise de constater que le programme en question pourrait servir plus souvent qu'on pensait ou qu'on pourrait y ajouter des fonctionalités connexes avec sa fonction d'origine.
S'il est relativement bien écrit, il sera plus facile à améliorer et optimiser.
Et comme le dit michelbillaud, ça ne sert à rien de passer des heures pour optimiser du code qui ne s'exécute que durant une fraction de seconde, même 100 fois par jour.
Le Tout est souvent plus grand que la somme de ses parties.
Le débat part un peu dans tous les sens... Le point de départ était la question de PierrotLeFou : pourquoi y a-t-il encore des gens qui s'embêtent à programmer en C ? Il me semblait que la réponse était : parce qu'il existe des contextes où l'on recherche l'efficacité du C malgré ses inconvénients (et il existe des contextes où c'est tout le contraire, bien sûr). Évidemment, encore faut-il bien faire les choses, ce qui est un autre sujet.
(Par exemple il me semble que beaucoup d'interpréteurs Python sont écrits en C. Et peut-être beaucoup d'interpréteurs d'autres langages, d'ailleurs. Je trouve ça compréhensible. Je ne serais pas étonné que les compilateurs C soient écrits en C.)
Je n'ai jamais dit que je m'embêtais à programmer en C. J'en ai contre le fait de passer trop de temps à optimiser certains programmes quand ça ne vaut pas la peine de le faire.
À ma connaissance, le compilateur C est écrit en C lui-même. En tout cas, c'était le cas quand je l'installais sur Unix.
Le Tout est souvent plus grand que la somme de ses parties.
Et quelque chose du genre? for (ok=1, i=0; i < 100; i++) if (variable[i] != 8) { ok=0; break; } if (ok) {...} Pour ox223252: Mon code est-il lamentablement moins efficace que le tien? Avec l'option -O9 ça ne devrait pas être troop affreux. Je n'ai écris que deux lignes pour 100 valeurs (sauf le code exécuté ensuite). Ça t'aurait pris combien de temps pour écrire ton code pour 100 valeurs? Je crois savoir que tu as une Lamborghini immatriculée 8086K, je n'ai qu'une Ferrari immatriculée 4790K.
je ne t'ai jamais parlé de ton code qui est idio ou autre, si tu lis bien ce que j'ai ecris
ox223252 a écrit:
PierrotLeFou a écrit:
Je ne paie pas pour le temps CPU de mon ordi personnel.
C'est idio ce que tu dis, c'est a cause de ce genre de reflexion qu'on a des tellephones 8 cores, avec 32 G de ram mais qui finissent par être moins perforamant qu'un raspberry.
Je dis que le temps CPU tu le paye et même très cher car c'est le prix du proco + le pric de l'electricité + le prix du refroidissement, donc oui ça reste idio de dire que le temps CPU tu ne le payes pas.
si tu as besoin du dernier i9 pour faire tourner un code alors que tu pourrais avoir un simple STM32 à 5$ pour faire la même chose... ça coute cher
la connaissance est une chose qui ne nous appauvrit pas quand on la partage.
Un ordinateur ça peut servir à beaucoup de choses. Il y a des choses pour lesquelles un STM32 serait suffisant et d'autres pour lesquelles un I9 aurait peine à suffire.
Ha oui! J'oubliais, le coût de l'électricité est moindre au Québec qu'en Europe.
Le ventillo fonctionne également à l'electricité.
Un ordi qui fonctionne une heure à 100 watts consomme 0.1 kw/h, donc l'équivalent de 0.6 centime.
Même si tu es payé 20 euro de l'heure, tu coûtes plus cher que ton ordi. (je suppose que le coût d'achat à été amorti)
Peux-tu dire que tu éteins ton ordi si tu restes 5 minutes à réfléchir et tu le repart quand tu as une idée?
Il arrive souvent que nos ordi tournent "idle" sans rien faire.
Le Tout est souvent plus grand que la somme de ses parties.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
la connaissance est une chose qui ne nous appauvrit pas quand on la partage.
Mon GitHub
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
Le Tout est souvent plus grand que la somme de ses parties.
la connaissance est une chose qui ne nous appauvrit pas quand on la partage.
Mon GitHub
Le Tout est souvent plus grand que la somme de ses parties.