Oui, ok, c'est ce que je voulais dire. Désolé je ne pensais pas spécifiquement à "char" dans mon commentaire, mais à déclarer ses entiers de la taille dont on a besoin.
Mais c'est quand même au compilateur de passer d'un tableau d'entier de cette taille à l'utilisation de l'instruction appropriée.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Effectivement tu économises un peu de mémoire (encore que vu la granularité des allocations sur la pile - une page - je suis pas sûr que ca soit visible en pratique pour les variables locales), par contre tu payes très cher en performance en x86[-64] et sur d'autres architectures.
Ça dépend. Ton compilateur peut très bien décider de mettre son char sur 4 octets, parce qu'il pensera que ce sera plus rapide (et de ce que tu lui demandes). Du coup il ne perdra pas de temps. Et il ne gagnera pas de place en mémoire non plus. Par contre, sur d'autres architectures (je ne connais pas bien x86, à ce niveau) il y a des instructions de load non alignées, qui prennent le même temps qu'un load aligné, si je ne me trompe pas. Du coup tu peux gagner de la place sans perdre en performance. Mais c'est plutôt à réserver aux applications où tu en as vraiment besoin, ou éventuellement aux tableaux. Tu ne gagnes globalement rien si tu passes 42 int en char dans tout ton programme. (dans un précédent projet, on avait une table de calibration composée de 2*4*27*27 char si je me rappelle bien. Et 4Mo de RAM, 2Mo de ROM. La différence entre char et int (de 4 octets) c'est 17 ko, presque 1% de la ROM, 0.5% de la RAM.
Pour un exemple de load non aligné, il y a par exemple
ldub address, reg
sur sparc.
Faut faire quand même faire attention, ça peut avoir des effets ailleurs (enfin, ça a été révélateur d'un bug). On réutilisait un code de correction d'erreur (c'était un système embarqué fort exposé aux rayonnements, donc beaucoup de bit flip) qui faisait simplement, à la réception de l'interruption "erreur détectée" un load et un store de l'adresse qui avait généré l'erreur (il y avait un système d'EDAC dans l'électronique qui nous corrigeait la valeur quand on loadait, et donc on restaurait la bonne valeur lors du store) Et ce code, qui était une réutilisation de code qui marchait, nous a provoqué une belle erreur sur un load non aligné…
ldsb address, reg # avec address pas multiple de 4
# --> EDAC, du à un SEU quelque part entre address, donc interruption
# gestion de l'interruption
[...]
ld address, reg # boum interruption, adresse non alignée, alors qu'on est dans une trap
nop
st reg, address
[...]
(la correction c'est de modifier l'adresse pour l'aligner sur un multiple de 4 dans la gestion de l'interruption, mais c'était du code qui existait depuis longtemps, et jusque là ça ne s'était jamais produit… enfin c'était un bug intéressant à comprendre, c'est juste dommage que ça se produise quand le machin était déjà lancé)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Il faut remarquer que la taille des "problèmes" à résoudre augmente aussi. La "puissance" de calcul brute augmente vite (supposons qu'elle est proportionnel au nombre de transistors, qui d'après la loi de Moore double tous les deux ans), mais les choses qu'on demandent augmentent aussi. Bon évidemment, c'est assez dépendant de l'application, mais beaucoup de problèmes ne peuvent pas voire augmenter leur taille aussi vite que la puissance de calcul.
Si un problème est de complexité O(n), on peut le doubler quand la puissance de calcul double. S'il est de complexité O(n2), on ne peut doubler la taille pour un même temps de calcul que lorsqu'on quadruple la puissance de calcul.
Alors évidement, la plupart des applications de tous les jours ne font pas de calcul intensif, mais par exemple le nombre de pixel qu'un programme doit afficher a tendance à quadrupler quand la taille (en nombre de pixels dans une direction) double. C'est pas nécessairement intensifs en calculs (ça dépend de ce qu'on veut afficher, et puis si c'est "complexe" et "3D" ce sera fait en partie par le GPU), mais on trouve ce genre de trucs un peu partout.
Après à la limite ça va dans ton sens, sur la partie "les applications aujourd'hui sont des trucs imbriqués dans tous les sens" (si j'ose résumé comme ça) parce qu'on gagne plus en vitesse si on utilise le meilleur algo connu en O(np) et pas celui plus simple en O(nq) avec q > p. (Enfin ça dépend de n et de la constante cachée dans le O.) Donc un développeur qui connait (ou se renseigne) son domaine et qui utilise le bon algo dans un truc à l'archi compliqué pourra (peut-être) faire un programme plus rapide qu'un développeur qui fera une archi plus simple mais avec un moins bon algo. Le mieux étant probablement l'archi simple avec le bon algo, mais ça demande du temps (et de l'investissement.)
C'est plus simple de passer de 4 Go de ram à 24Go pour pouvoir dire "ouais, il y a peut-être une fuite mémoire, mais bon, avec 24Go de ram vous aurez de la marge, faudra surement redémarrer l'appli pour une maj avant que la fuite n'ait tout pris." (à peu près l'idée d'un truc qui a été fait ici… /o\)(je suis l'utilisateur pas le dev, mais en même temps je suis nul en IHM donc je ne critique pas trop)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Combien d'enfants sont déclarés avec uniquement une mère ? (appelons ce nombre M) Combien d'enfants sont déclarés avec seulement un père ? (appelons ce nombre P)
Je soutiens deux choses.
Si un des deux nombres est plus grand que l'autre, alors sa catégorie de parents est plus susceptible que l'autre de prendre un congé parental.
M > P
Est-ce que tu contestes une de ces deux affirmations, et si oui, laquelle ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Les cas où une femme met au monde un enfant puis le donne à un père célibataire juste après, assez tôt pour que ce père puisse prendre un congé paternité, ça me semble plus rare que les mères célibataires qui accouchent et peuvent profiter d'un congé maternité.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Les historiens, paléontologues et astrophysiciens peuvent dépasser, mais les physiciens des hautes énergie et Usain Bolt ne peuvent pas dépasser. Chacun son temps suffisamment bref.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
En même temps si le boulot est nécessaire, pendant que la personne doit prendre son congé, quelqu'un d'autre doit le faire. Donc une autre personne travaille, au lieu de toucher une aide.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Ton ignorance crasse continue, toute cette surface sera donc utilisee au detriment d'autre chose. chose que tu fais mine de completement oublie…(ou que tu oublies honnetement ce qui est pire)
Genre par exemple des forets, des terres arables etc..
Ou des maisons. On ne va pas pouvoir mettre de bâtiment sur un panneau solaire, ça ne marchera pas !
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Je suis bien d'accord avec ta dernière phrase. Par contre on ne peut pas stocker d'énergie en se disant qu'on va déplacer des voitures de A à B ;-) (si A et B sont à la même altitude) (on peut les stocker dans les batteries, ou produire un carburant, ou pomper de l'eau en hauteur.)
Et surtout on peut l'utiliser comme elle arrive, à la place de centrale nucléaire ou d'autre centrale thermique. Quand on l'utilise, on va de toute façon avoir une génération de chaleur, mais pas plus que si on utilisait la même quantité d'énergie nucléaire/gaz/pétrole/charbon/éolien/solaire (modulo les pertes dans la "centrale" réceptionnant l'énergie et dans l'atmosphère avant d'y arriver, éventuellement) Et si ça remplace du fossile, on a l'avantage de générer moins de gaz à effet de serre et donc on peut diminuer un peu la température par rapport à l'utilisation de fossile.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Oui, c'est le travail mécanique. Sauf qu'en fait, quand tu es sur l'autoroute (plate) à vitesse stable, la force qui s'applique à ta voiture, c'est 0. En imaginant une route parfaitement droite et plate, tu as 3 régimes. Au début, une accélération 1 (disons à accélération constante), puis un déplacement à vitesse constante 2, puis la décélération 3 (constante). L'énergie que tu produis en 1 est stockée en énergie cinétique (et vaut bien W = F_acc*(A->fin accélération) ), en 2 l'énergie que tu produis est parfaitement contrebalancée par toutes les autres forces, l'énergie cinétique reste constante, et en 3 tu dissipes l'énergie cinétique en autre chose (souvent en frottement dans le moteur et frein, mais aussi en stockage de l'énergie dans ton système de récupération de l'énergie cinétique, si tu en as un ;-) )
Ça marche aussi c'est c'est pas en ligne droite, pas plat, et pas en 3 phase avec a ou v constant. Faut juste intégrer sur la trajectoire et rajouter le potentiel gravitique dans l'équation. Quand au cas où il n'y a pas d'air, tu as raison, la force ne peut pas être nulle au début, mais cette énergie est contrebalancée par le freinage (enfin décélération, pas nécessairement limité au frein) de la fin.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Donc les camions, voitures qui se déplacent sur une route pour aller réparer une centrale nucléaire ne consomment pas d'énergie, contrairement aux bateaux qui vont réparer une éolienne en mer ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
Tu as raison, il faut retirer 0.7% de ces 927TWh. On passerait donc de 48% à 47.5%. Du coup ce n'est plus du tout une grosse part du tout. (avant que tu ne critiques, j'ai arrondi, deux fois, dans un sens qui te favorise, et je n'ai pas repris en compte la rétroaction électricité -> chaleur, qui fait que ça devrait diminuer encore un peu l'écart)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
En attendant en Allemagne ils exportent toujours plus d'électricité http://www.welt.de/wirtschaft/energie/article110838598/Deutscher-Stromexport-steigt-auf-Rekordhoch.html (avec cet effet un peu con que le prix industriel ne cesse de baisser parce qu'il est subventionné par les taxes des ménages…) Toujours est-il que les producteurs pourraient produire moins si ils estimaient que ce prix bas industriel n'était pas rentable.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
L'éolien non plus ne s'arrête pas, pas plus que le photovoltaïque. Leur croissance est même plus forte en France que celle du nucléaire, ces dernières années, si je ne me trompe pas.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Méthodes de développement
Posté par 2PetitsVerres . En réponse au journal De l'inéluctable progrès de l'informatique, ou pas.. Évalué à 3. Dernière modification le 20 novembre 2012 à 15:14.
Oui, ok, c'est ce que je voulais dire. Désolé je ne pensais pas spécifiquement à "char" dans mon commentaire, mais à déclarer ses entiers de la taille dont on a besoin.
Mais c'est quand même au compilateur de passer d'un tableau d'entier de cette taille à l'utilisation de l'instruction appropriée.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Méthodes de développement
Posté par 2PetitsVerres . En réponse au journal De l'inéluctable progrès de l'informatique, ou pas.. Évalué à 2.
Ça dépend. Ton compilateur peut très bien décider de mettre son char sur 4 octets, parce qu'il pensera que ce sera plus rapide (et de ce que tu lui demandes). Du coup il ne perdra pas de temps. Et il ne gagnera pas de place en mémoire non plus. Par contre, sur d'autres architectures (je ne connais pas bien x86, à ce niveau) il y a des instructions de load non alignées, qui prennent le même temps qu'un load aligné, si je ne me trompe pas. Du coup tu peux gagner de la place sans perdre en performance. Mais c'est plutôt à réserver aux applications où tu en as vraiment besoin, ou éventuellement aux tableaux. Tu ne gagnes globalement rien si tu passes 42 int en char dans tout ton programme. (dans un précédent projet, on avait une table de calibration composée de 2*4*27*27 char si je me rappelle bien. Et 4Mo de RAM, 2Mo de ROM. La différence entre char et int (de 4 octets) c'est 17 ko, presque 1% de la ROM, 0.5% de la RAM.
Pour un exemple de load non aligné, il y a par exemple
sur sparc.
Faut faire quand même faire attention, ça peut avoir des effets ailleurs (enfin, ça a été révélateur d'un bug). On réutilisait un code de correction d'erreur (c'était un système embarqué fort exposé aux rayonnements, donc beaucoup de bit flip) qui faisait simplement, à la réception de l'interruption "erreur détectée" un load et un store de l'adresse qui avait généré l'erreur (il y avait un système d'EDAC dans l'électronique qui nous corrigeait la valeur quand on loadait, et donc on restaurait la bonne valeur lors du store) Et ce code, qui était une réutilisation de code qui marchait, nous a provoqué une belle erreur sur un load non aligné…
(la correction c'est de modifier l'adresse pour l'aligner sur un multiple de 4 dans la gestion de l'interruption, mais c'était du code qui existait depuis longtemps, et jusque là ça ne s'était jamais produit… enfin c'était un bug intéressant à comprendre, c'est juste dommage que ça se produise quand le machin était déjà lancé)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Complexité
Posté par 2PetitsVerres . En réponse au journal De l'inéluctable progrès de l'informatique, ou pas.. Évalué à 5.
Il faut remarquer que la taille des "problèmes" à résoudre augmente aussi. La "puissance" de calcul brute augmente vite (supposons qu'elle est proportionnel au nombre de transistors, qui d'après la loi de Moore double tous les deux ans), mais les choses qu'on demandent augmentent aussi. Bon évidemment, c'est assez dépendant de l'application, mais beaucoup de problèmes ne peuvent pas voire augmenter leur taille aussi vite que la puissance de calcul.
Si un problème est de complexité O(n), on peut le doubler quand la puissance de calcul double. S'il est de complexité O(n2), on ne peut doubler la taille pour un même temps de calcul que lorsqu'on quadruple la puissance de calcul.
Alors évidement, la plupart des applications de tous les jours ne font pas de calcul intensif, mais par exemple le nombre de pixel qu'un programme doit afficher a tendance à quadrupler quand la taille (en nombre de pixels dans une direction) double. C'est pas nécessairement intensifs en calculs (ça dépend de ce qu'on veut afficher, et puis si c'est "complexe" et "3D" ce sera fait en partie par le GPU), mais on trouve ce genre de trucs un peu partout.
Après à la limite ça va dans ton sens, sur la partie "les applications aujourd'hui sont des trucs imbriqués dans tous les sens" (si j'ose résumé comme ça) parce qu'on gagne plus en vitesse si on utilise le meilleur algo connu en O(np) et pas celui plus simple en O(nq) avec q > p. (Enfin ça dépend de n et de la constante cachée dans le O.) Donc un développeur qui connait (ou se renseigne) son domaine et qui utilise le bon algo dans un truc à l'archi compliqué pourra (peut-être) faire un programme plus rapide qu'un développeur qui fera une archi plus simple mais avec un moins bon algo. Le mieux étant probablement l'archi simple avec le bon algo, mais ça demande du temps (et de l'investissement.)
C'est plus simple de passer de 4 Go de ram à 24Go pour pouvoir dire "ouais, il y a peut-être une fuite mémoire, mais bon, avec 24Go de ram vous aurez de la marge, faudra surement redémarrer l'appli pour une maj avant que la fuite n'ait tout pris." (à peu près l'idée d'un truc qui a été fait ici… /o\)(je suis l'utilisateur pas le dev, mais en même temps je suis nul en IHM donc je ne critique pas trop)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Réponse simple à la question.
Posté par 2PetitsVerres . En réponse au journal Du code propre, c'est quoi ?. Évalué à 4.
Du code propre, c'est au mieux quelque chose de relatif, au pire quelque chose qui n'existe pas.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: libre
Posté par 2PetitsVerres . En réponse au journal Adopter un style de programmation fonctionnel. Évalué à 3.
fsqrts %l1, %l2
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Rendement
Posté par 2PetitsVerres . En réponse à la dépêche Le Top 500 de novembre 2012. Évalué à 7.
J'imagine le type qui mesure.
Excusez-moi, je débranche votre ordinateur deux secondes, c'est juste pour intercaler le Wattmètre.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Variables...
Posté par 2PetitsVerres . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 2.
Non j'ai rien dit c'est pas le nombre d'entrées qui peut faire l'overfitting, mais plutôt le rapport paramètres du modèle/nombre d'exemple dispo. /o\
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: égalité
Posté par 2PetitsVerres . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 2.
On va le faire plus simplement.
Combien d'enfants sont déclarés avec uniquement une mère ? (appelons ce nombre M) Combien d'enfants sont déclarés avec seulement un père ? (appelons ce nombre P)
Je soutiens deux choses.
Est-ce que tu contestes une de ces deux affirmations, et si oui, laquelle ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Dédommagement != espérance de gain
Posté par 2PetitsVerres . En réponse au journal Enfin !!!!. Évalué à 1.
Ou dis autrement, ils sont sur-gradés et redescendu artificiellement.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: égalité
Posté par 2PetitsVerres . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 5.
Les cas où une femme met au monde un enfant puis le donne à un père célibataire juste après, assez tôt pour que ce père puisse prendre un congé paternité, ça me semble plus rare que les mères célibataires qui accouchent et peuvent profiter d'un congé maternité.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Discrimination
Posté par 2PetitsVerres . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 2.
Et les morts de faim dans le monde c'est pire que la neige sur les routes en hiver. Tu proposes d'arrêter de dégager les routes ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Variables...
Posté par 2PetitsVerres . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 2.
Avec 1000 variables, même si elles ne sont que binaires, ça fait juste 10301 états. Son modèle risque un peu l'overfitting.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Et ailleurs ?
Posté par 2PetitsVerres . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 3.
Les historiens, paléontologues et astrophysiciens peuvent dépasser, mais les physiciens des hautes énergie et Usain Bolt ne peuvent pas dépasser. Chacun son temps suffisamment bref.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Et ailleurs ?
Posté par 2PetitsVerres . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 4.
Je vois mal comment on peut être coincé derrière quelqu'un qui roule à 131.5 km/h si la limite est de 130 km/h.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: égalité
Posté par 2PetitsVerres . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 3.
En même temps si le boulot est nécessaire, pendant que la personne doit prendre son congé, quelqu'un d'autre doit le faire. Donc une autre personne travaille, au lieu de toucher une aide.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: égalité
Posté par 2PetitsVerres . En réponse au journal Assurance auto : égalité hommes/femmes. Évalué à 1.
Les femmes célibataires auront toujours plus de risque que les hommes célibataires de "devoir" prendre ce congé.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: rendement oui, mais quel vent avez-vous souvent ?
Posté par 2PetitsVerres . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 3.
J'avais glissé un poil d'ironie dans mon message précédent ;-)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: rendement oui, mais quel vent avez-vous souvent ?
Posté par 2PetitsVerres . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 5.
Ou des maisons. On ne va pas pouvoir mettre de bâtiment sur un panneau solaire, ça ne marchera pas !
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
# Ouais, c'est ça.
Posté par 2PetitsVerres . En réponse au journal ZeroMQ et les mangoustes. Évalué à 8.
On dit tous ça. /o\
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Éolienne verticale
Posté par 2PetitsVerres . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 3.
Je suis bien d'accord avec ta dernière phrase. Par contre on ne peut pas stocker d'énergie en se disant qu'on va déplacer des voitures de A à B ;-) (si A et B sont à la même altitude) (on peut les stocker dans les batteries, ou produire un carburant, ou pomper de l'eau en hauteur.)
Et surtout on peut l'utiliser comme elle arrive, à la place de centrale nucléaire ou d'autre centrale thermique. Quand on l'utilise, on va de toute façon avoir une génération de chaleur, mais pas plus que si on utilisait la même quantité d'énergie nucléaire/gaz/pétrole/charbon/éolien/solaire (modulo les pertes dans la "centrale" réceptionnant l'énergie et dans l'atmosphère avant d'y arriver, éventuellement) Et si ça remplace du fossile, on a l'avantage de générer moins de gaz à effet de serre et donc on peut diminuer un peu la température par rapport à l'utilisation de fossile.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Éolienne verticale
Posté par 2PetitsVerres . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 3.
Oui, c'est le travail mécanique. Sauf qu'en fait, quand tu es sur l'autoroute (plate) à vitesse stable, la force qui s'applique à ta voiture, c'est 0. En imaginant une route parfaitement droite et plate, tu as 3 régimes. Au début, une accélération 1 (disons à accélération constante), puis un déplacement à vitesse constante 2, puis la décélération 3 (constante). L'énergie que tu produis en 1 est stockée en énergie cinétique (et vaut bien W = F_acc*(A->fin accélération) ), en 2 l'énergie que tu produis est parfaitement contrebalancée par toutes les autres forces, l'énergie cinétique reste constante, et en 3 tu dissipes l'énergie cinétique en autre chose (souvent en frottement dans le moteur et frein, mais aussi en stockage de l'énergie dans ton système de récupération de l'énergie cinétique, si tu en as un ;-) )
Ça marche aussi c'est c'est pas en ligne droite, pas plat, et pas en 3 phase avec a ou v constant. Faut juste intégrer sur la trajectoire et rajouter le potentiel gravitique dans l'équation. Quand au cas où il n'y a pas d'air, tu as raison, la force ne peut pas être nulle au début, mais cette énergie est contrebalancée par le freinage (enfin décélération, pas nécessairement limité au frein) de la fin.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: rendement oui, mais quel vent avez-vous souvent ?
Posté par 2PetitsVerres . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 1.
Donc les camions, voitures qui se déplacent sur une route pour aller réparer une centrale nucléaire ne consomment pas d'énergie, contrairement aux bateaux qui vont réparer une éolienne en mer ?
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: rendement oui, mais quel vent avez-vous souvent ?
Posté par 2PetitsVerres . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 3.
Tu as raison, il faut retirer 0.7% de ces 927TWh. On passerait donc de 48% à 47.5%. Du coup ce n'est plus du tout une grosse part du tout. (avant que tu ne critiques, j'ai arrondi, deux fois, dans un sens qui te favorise, et je n'ai pas repris en compte la rétroaction électricité -> chaleur, qui fait que ça devrait diminuer encore un peu l'écart)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: rendement oui, mais quel vent avez-vous souvent ?
Posté par 2PetitsVerres . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 3.
En attendant en Allemagne ils exportent toujours plus d'électricité http://www.welt.de/wirtschaft/energie/article110838598/Deutscher-Stromexport-steigt-auf-Rekordhoch.html (avec cet effet un peu con que le prix industriel ne cesse de baisser parce qu'il est subventionné par les taxes des ménages…) Toujours est-il que les producteurs pourraient produire moins si ils estimaient que ce prix bas industriel n'était pas rentable.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: rendement oui, mais quel vent avez-vous souvent ?
Posté par 2PetitsVerres . En réponse à la dépêche Un projet d’éolienne sous licences libres. Évalué à 3.
L'éolien non plus ne s'arrête pas, pas plus que le photovoltaïque. Leur croissance est même plus forte en France que celle du nucléaire, ces dernières années, si je ne me trompe pas.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.