Le point 2 parle surtout des problèmes de mantisses quand on additionne 2 nombres de tailles différentes. C'est bien une forme d'accumulation d'erreur. C'est le "fameux" problème d'addition des souris et des éléphants. Ici, la souris passe sous le lsb dans l'addition avec l'éléphant.
Pour illustrer son point 4, il utilise chop comme fonction d'arrondit. IEEE754 utilise round to even, c'est pas pour rien. En moyenne, cet arrondi annule les effets cumulatifs. Et il parle de problème très particuliers.
Je suis bien conscient que le cas général ne peut pas être géré facilement, mais les cas particuliers utiles pourraient l'être.
Concernant la stabilité, c'est par exemple la répétition de x= x(-1)*.1 ? A part dans le monde des calculs scientifiques, ce genre de chose est évité dans le traitement du signal, parce ce que les valeurs d'entrés ne sont de toute façon jamais connu de façon précise.
Je veux dire par là, qu'il existe toute une gamme d'équation non simplifiable du style de celle que tu décris, mais elles ne sont pas tant utilisé tant que ça dans les faits.
Connaître la précision requise des opérations de base (+,-,*,/) c'est bien beau mais ce qui compte réellement c'est la précision globale de l'algo.
Oui mais en partant des erreurs connu de "+" (0.5 lsb) tu peux en déduire la propagation d'erreur dans une équation et la borner d'une façon ou d'une autre, dans l'implémentation choisi par le compilo. Genre ((a+b)*c+de)+a pourrait être traduit en (ac+bd)+(de+a) si on peut supporter la perte de 2 ou 3 lsb dans le résultat attendu.
Mais si tu connais une solution, je suis preneur et la communauté scientifique aussi. Je crois même qu'il est probable que tu recevras une récompense pour ça…
Sacré motivation :) Je pensais simplement à simplifier des équation mathématique, genre un -fast-math avec résultat contrôlé. En voulant faire ça, je me suis rendu compte que l'on ne pouvait rien faire avec du code C ou C++ utilisant des flottants : il manque trop d'information.
L'idée ressemble beaucoup au ROM (reduce order modeling) dont j'ai entendu parlé récemment, le compilo travaillerai au niveau equation et non plus au niveau model 3D. http://www.bris.ac.uk/aerodynamics-research/roms/
Exactement. Il y a des tas d'optimisation simple à faire pour augmenter la vitesse d'un code numérique qui sont très dure à faire si on ne connait pas les besoins réels du codeur concernant la précision requise.
On peut même imaginer une implémentation sans code flottant, et sans devoir faire totalement la conversion à la main.
Le gros hic, c'est la stabilité numérique :/ Et ça, je vois très mal un compilo être capable de l'estimer.
Tu parles des équations bizarres qui peuvent diverger autour de points spéciaux ? Parce que dans l'embarqué, qui utilise des code rétroactif, il utilise en général des équations qui évitent d'être sensible aux bits de poids faible d'une grandeur, car elles sont physiques et donc soumises elle-même à une erreur de mesure. Les équations instables sont évitées comme la peste : comment prouver que le système ne peut par partir en sucette ? Si il y a des hommes dedans, cela peut être gênant.
Non, je veux un type de donné qui correspond aux problèmes systèmes, c'est ensuite au compilateur de faire son boulot pour trouver la meilleur représentation machine et de faire des simplications mathématique qui rende le code plus simple. On peut imaginer des factorisations pour réduire le nombre de division et l'inverse pour augmenter le parallélisme du code. On peut encore imaginer aller plus loin avec une linéarisation des équations valides dans le range précisé et la précision voulue.
Tout cela n'est possible qu'avec range et précision absolu (ou absolu + relatif même si c'est plus chiant) et que l'on considère les équations comme avec des réels et non comme avec des nombres flottants.
math.acos( math.cos(xmin+step*i)*math.cos( t[k,0] ) pour une précision donnée se réduit à un polynôme ou presque.
Quand tu fais un logiciel, du point de vue système tu te fou de savoir si tu utilises des flottants ou des virgules fixes. Il s'agit toujours de "nombre". En compta, il utilise un big number ou équivalent. Un nombre avec range + précision peut être mappé sur n'importe quelle représentation informatique.
Un float c'est Significant digits × baseexponent. Donc la précision varie en fonction de ces 3 paramètres. Le range ne donne rien de ces trois paramètres (y a pas que le IEEE dans la vie).
Sauf qu'il y a très peu de variantes pour ses 3 variables. Si ta fpu n'est pas IEEE754, je ne vois pas ce que tu peux faire au niveau précision car tu ne sais même pas ce que la fpu va te perdre.
Si tu veux de l'absolu, tu utilise le point fixe. Les flottants donnent toujours une précision variable quelque soit l'intervalle choisi (Il y a évidement une précision minimale - ensemble fini d'éléments donc différences 2 à 2 finies).
Oui, mais on veut une précision minimum, pas une précision fixe. On veut une précision finale du point de vue système, on se contre fou de la manière d'y arriver.
En fait, non. Si tu prends une précision relative, que faire autour de zéro et que faire des nombres dénormalisés ? Il va te falloir en plus une précision absolue juste pour ce cas-là.
De plus, si tu regardes des spécifications, les grandeurs d'entrée ou de sorties de calcul sont toujours en absolue : précisions d'ADC, précision de capteur, "lsb" de nombre entier pour la musique, pixel pour des images, etc…
Dans le cas de comptabilité, on a envie d'avoir une erreur inférieur au centime, quelque soit les sommes intermédiaires.
Les nombres flottants peuvent être utilisés avec une précision absolue si tu as le range, donc, c'est bon.
Déjà si les types incluaient range et précision absolu, on pourrait faire des transformations avec "perte maitrisée" de la précision de calcul. Là avec le code IEEE754, on ne peut rien en faire de "maitrisable".
J'imagine que générer du code openMP, et du gcc vectorisable par gcc ne doit pas être sorcier, à condition de maitriser le layout mémoire des données.
Pour faire de n'importe quoi un binaire optimisé, il faut que tu puisses déduire les types exactes de chaque valeur. Cela nécessite une analyse global du programme qui n'est pas toujours possible.
Par exemple, en C, si tu as une fonction qui prend 2 pointeurs de même type en entrée, sans "restrict", le compilo part du principe que les 2 zones pointées peuvent se recouvrir. C'est idiot pour 99% des cas, mais cela oblige des passages vers la mémoire totalement inutile.
En C, 99% du temps tu te fous de l'ordre des éléments dans la déclaration de structure, faire un tri pour éviter le padding serait plus efficace, mais tu change l'ordre prévus par le codeur, ce qui peut poser problème (tableau de taille nul en fin de structure par exemple).
Quand tu manipules des données flottantes IEEE754, aucune transformation ne peut se faire sans perte, car l'ensemble des nombres n'est pas un ensemble mathématique classique. Sans information sur les "pertes acceptables de précision" , le compilo ne fait rien ou presque.
Toutes ses informations peuvent se retrouver par une analyse précise et total du code, mais cela devient hyper complexe.
Cela serait cool aussi d'avoir un clavier avec complétion automatique version emacs ou eclipse. Le T9 ne tient compte que de douze touches et c'est pénible. Le principe de l'apprentissage permet à l'usage moins de proposition inutile qu'avec le T9 je pense.
Le 2 est assez cocasse car les DRM sont fait justement pour faire ressembler les copies numériques à des objets que l'on ne peut plus dupliquer à l'infini. C'est tellement vrai que des sites de revente de musique sous DRM se sont créer.
Maintenant, les majors ont envie d'utiliser les DRM pour empêcher tout ce qui n'était pas possible de faire avec un objet : interdire la revente, interdire le prêt, interdire l'occasion.
"en regardant l'épargne et dividendes qui devront quand même être dépensés un jour par les riches donc avec TVA)"
Attention quand même au facteur temps, les prélèvements sont pensés annuellement. L'épargne introduit un retard dans le boucle qui est un problème en soi. L'argent qui dort ne sert à rien d'un point de vue global. C'est d'ailleurs marrant de voir que l'augmentation de 30% de la masse monétaire fin 2011 n'a pas produit du tout d'inflation. Cela veut dire qu'elle est resté dans les sphères purement financières sans atteindre le monde réelle et la production de richesse.
Le facteur temps est tellement important, que certain préconise de viser une inflation à 4% plutôt que 2, justement pour forcer les rentiers à investir et rendre les entreprises plus attractif que les livrets d'épargne.
J'aime bien les gens qui reproche à Zenitram de faire du Zenitram.
Il veut simplement dire que le principe de l'augmentation de la TVA n'implique pas forcément une hausse mécanique plus forte des taux réelle de prélèvement pour les plus pauvres que pour les plus riches. Il y a des moyens de contre-balancer ça.
Devant le manque de travail, il devient absurde d'utiliser le salaire comme base d'imposition, en tout cas pour le commun des mortels. Il faut donc alléger les cotisations sociales et trouver d'autres assiettes. Les bénéfices sont une très mauvaise assiette car le CAC40 se débrouillera toujours pour ne quasiment rien payer au contraire des PME. Il ne reste plus vraiment d'autre piste qui ne soit pas déjà utilisé. (ISF, impôt sur les successions, impôt de bourse, CSG,…)
Au fait pourquoi tu ne fais pas une recherche exhaustive pour nanimopt ? Il faut quand même un gros nombre d'image pour ne pas arriver à les trier (>100 ?). Beaucoup de problèmes np-complet sont définit avec peu d'éléments. Si cela calcul pendant quelques minutes de plus pour sauver de la place en mémoire, personne ne t'en voudra.
"Oui enfin faudrait savoir, on parlait d'une hypothèse où il n'y aurait que la TVA comme impôt. Si on ajoute l'ISF et l'IR, c'est plus la même chose."
Il n'y aura jamais de changement brutal d'un système à l'autre, il y aura forcément un glissement et donc une cohabitation.
L'ISF peut aussi être vu comme un impôt en avance sur la succession, impôt indiscutable qui évite les dynasties. Mais c'est vrai que le plafond de l'ISF n'a pas bougé alors que l'immobilier à doubler de prix.
[^] # Re: Liaison dynamique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1.
Le point 2 parle surtout des problèmes de mantisses quand on additionne 2 nombres de tailles différentes. C'est bien une forme d'accumulation d'erreur. C'est le "fameux" problème d'addition des souris et des éléphants. Ici, la souris passe sous le lsb dans l'addition avec l'éléphant.
Pour illustrer son point 4, il utilise chop comme fonction d'arrondit. IEEE754 utilise round to even, c'est pas pour rien. En moyenne, cet arrondi annule les effets cumulatifs. Et il parle de problème très particuliers.
Je suis bien conscient que le cas général ne peut pas être géré facilement, mais les cas particuliers utiles pourraient l'être.
"La première sécurité est la liberté"
[^] # Re: Liaison dynamique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 2.
Métier, quand il ne s'agit pas de système, justement :) Un avion, une voiture, un train, une grue, un bateau…
"La première sécurité est la liberté"
[^] # Re: Liaison dynamique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1. Dernière modification le 21 février 2013 à 12:33.
Concernant la stabilité, c'est par exemple la répétition de x= x(-1)*.1 ? A part dans le monde des calculs scientifiques, ce genre de chose est évité dans le traitement du signal, parce ce que les valeurs d'entrés ne sont de toute façon jamais connu de façon précise.
Je veux dire par là, qu'il existe toute une gamme d'équation non simplifiable du style de celle que tu décris, mais elles ne sont pas tant utilisé tant que ça dans les faits.
Connaître la précision requise des opérations de base (+,-,*,/) c'est bien beau mais ce qui compte réellement c'est la précision globale de l'algo.
Oui mais en partant des erreurs connu de "+" (0.5 lsb) tu peux en déduire la propagation d'erreur dans une équation et la borner d'une façon ou d'une autre, dans l'implémentation choisi par le compilo. Genre ((a+b)*c+de)+a pourrait être traduit en (ac+bd)+(de+a) si on peut supporter la perte de 2 ou 3 lsb dans le résultat attendu.
Mais si tu connais une solution, je suis preneur et la communauté scientifique aussi. Je crois même qu'il est probable que tu recevras une récompense pour ça…
Sacré motivation :) Je pensais simplement à simplifier des équation mathématique, genre un -fast-math avec résultat contrôlé. En voulant faire ça, je me suis rendu compte que l'on ne pouvait rien faire avec du code C ou C++ utilisant des flottants : il manque trop d'information.
L'idée ressemble beaucoup au ROM (reduce order modeling) dont j'ai entendu parlé récemment, le compilo travaillerai au niveau equation et non plus au niveau model 3D.
http://www.bris.ac.uk/aerodynamics-research/roms/
"La première sécurité est la liberté"
[^] # Re: Liaison dynamique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1.
Exactement. Il y a des tas d'optimisation simple à faire pour augmenter la vitesse d'un code numérique qui sont très dure à faire si on ne connait pas les besoins réels du codeur concernant la précision requise.
On peut même imaginer une implémentation sans code flottant, et sans devoir faire totalement la conversion à la main.
Le gros hic, c'est la stabilité numérique :/ Et ça, je vois très mal un compilo être capable de l'estimer.
Tu parles des équations bizarres qui peuvent diverger autour de points spéciaux ? Parce que dans l'embarqué, qui utilise des code rétroactif, il utilise en général des équations qui évitent d'être sensible aux bits de poids faible d'une grandeur, car elles sont physiques et donc soumises elle-même à une erreur de mesure. Les équations instables sont évitées comme la peste : comment prouver que le système ne peut par partir en sucette ? Si il y a des hommes dedans, cela peut être gênant.
"La première sécurité est la liberté"
[^] # Re: Liaison dynamique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1.
C'est le truc à résoudre avant de commencer à coder.
"La première sécurité est la liberté"
[^] # Re: Liaison dynamique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1. Dernière modification le 20 février 2013 à 17:28.
Non, je veux un type de donné qui correspond aux problèmes systèmes, c'est ensuite au compilateur de faire son boulot pour trouver la meilleur représentation machine et de faire des simplications mathématique qui rende le code plus simple. On peut imaginer des factorisations pour réduire le nombre de division et l'inverse pour augmenter le parallélisme du code. On peut encore imaginer aller plus loin avec une linéarisation des équations valides dans le range précisé et la précision voulue.
Tout cela n'est possible qu'avec range et précision absolu (ou absolu + relatif même si c'est plus chiant) et que l'on considère les équations comme avec des réels et non comme avec des nombres flottants.
math.acos( math.cos(xmin+step*i)*math.cos( t[k,0] ) pour une précision donnée se réduit à un polynôme ou presque.
"La première sécurité est la liberté"
[^] # Re: Liaison dynamique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 2.
Quand tu fais un logiciel, du point de vue système tu te fou de savoir si tu utilises des flottants ou des virgules fixes. Il s'agit toujours de "nombre". En compta, il utilise un big number ou équivalent. Un nombre avec range + précision peut être mappé sur n'importe quelle représentation informatique.
Un float c'est Significant digits × baseexponent. Donc la précision varie en fonction de ces 3 paramètres. Le range ne donne rien de ces trois paramètres (y a pas que le IEEE dans la vie).
Sauf qu'il y a très peu de variantes pour ses 3 variables. Si ta fpu n'est pas IEEE754, je ne vois pas ce que tu peux faire au niveau précision car tu ne sais même pas ce que la fpu va te perdre.
Si tu veux de l'absolu, tu utilise le point fixe. Les flottants donnent toujours une précision variable quelque soit l'intervalle choisi (Il y a évidement une précision minimale - ensemble fini d'éléments donc différences 2 à 2 finies).
Oui, mais on veut une précision minimum, pas une précision fixe. On veut une précision finale du point de vue système, on se contre fou de la manière d'y arriver.
"La première sécurité est la liberté"
[^] # Re: erreur d'historique?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.8. Évalué à 4.
Vers l'alpha, je pense, premier port de Linux.
"La première sécurité est la liberté"
[^] # Re: Liaison dynamique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1.
Une relative est plus raisonnable…
En fait, non. Si tu prends une précision relative, que faire autour de zéro et que faire des nombres dénormalisés ? Il va te falloir en plus une précision absolue juste pour ce cas-là.
De plus, si tu regardes des spécifications, les grandeurs d'entrée ou de sorties de calcul sont toujours en absolue : précisions d'ADC, précision de capteur, "lsb" de nombre entier pour la musique, pixel pour des images, etc…
Dans le cas de comptabilité, on a envie d'avoir une erreur inférieur au centime, quelque soit les sommes intermédiaires.
Les nombres flottants peuvent être utilisés avec une précision absolue si tu as le range, donc, c'est bon.
"La première sécurité est la liberté"
[^] # Re: oui mais non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal C'est pas passé loin !. Évalué à 3.
Même que les versions en métal, s'appelle des … canons.
"La première sécurité est la liberté"
[^] # Re: Liaison dynamique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 1.
Déjà si les types incluaient range et précision absolu, on pourrait faire des transformations avec "perte maitrisée" de la précision de calcul. Là avec le code IEEE754, on ne peut rien en faire de "maitrisable".
J'imagine que générer du code openMP, et du gcc vectorisable par gcc ne doit pas être sorcier, à condition de maitriser le layout mémoire des données.
"La première sécurité est la liberté"
[^] # Re: Ça m'intéresse
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pythran 0.2 : Python peut-il être aussi rapide que du C ?. Évalué à 3.
Pour faire de n'importe quoi un binaire optimisé, il faut que tu puisses déduire les types exactes de chaque valeur. Cela nécessite une analyse global du programme qui n'est pas toujours possible.
Par exemple, en C, si tu as une fonction qui prend 2 pointeurs de même type en entrée, sans "restrict", le compilo part du principe que les 2 zones pointées peuvent se recouvrir. C'est idiot pour 99% des cas, mais cela oblige des passages vers la mémoire totalement inutile.
En C, 99% du temps tu te fous de l'ordre des éléments dans la déclaration de structure, faire un tri pour éviter le padding serait plus efficace, mais tu change l'ordre prévus par le codeur, ce qui peut poser problème (tableau de taille nul en fin de structure par exemple).
Quand tu manipules des données flottantes IEEE754, aucune transformation ne peut se faire sans perte, car l'ensemble des nombres n'est pas un ensemble mathématique classique. Sans information sur les "pertes acceptables de précision" , le compilo ne fait rien ou presque.
Toutes ses informations peuvent se retrouver par une analyse précise et total du code, mais cela devient hyper complexe.
"La première sécurité est la liberté"
# complétion automatique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De la conception d'une disposition BÉPO pour Android…. Évalué à 2.
Cela serait cool aussi d'avoir un clavier avec complétion automatique version emacs ou eclipse. Le T9 ne tient compte que de douze touches et c'est pénible. Le principe de l'apprentissage permet à l'usage moins de proposition inutile qu'avec le T9 je pense.
"La première sécurité est la liberté"
[^] # Re: Pas besoin de découpe
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Mise à disposition progressive du contenu: bonne idée.. Évalué à 2.
Le 2 est assez cocasse car les DRM sont fait justement pour faire ressembler les copies numériques à des objets que l'on ne peut plus dupliquer à l'infini. C'est tellement vrai que des sites de revente de musique sous DRM se sont créer.
Maintenant, les majors ont envie d'utiliser les DRM pour empêcher tout ce qui n'était pas possible de faire avec un objet : interdire la revente, interdire le prêt, interdire l'occasion.
"La première sécurité est la liberté"
[^] # Re: Pas besoin de découpe
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Mise à disposition progressive du contenu: bonne idée.. Évalué à 2.
Une bande annonce peut être meilleur que le film, mais pas le 1er album d'une BD, donc, je n'ai pas l'impression que tu arnaques le publique.
"La première sécurité est la liberté"
# Pas besoin de découpe
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Mise à disposition progressive du contenu: bonne idée.. Évalué à 3.
Il n'a pas besoin de découper un album comme cela.
Il peut tout à fait faire un premier épisode gratuit (~30 pages) et le reste payant (mais au vrai prix !! autour de 3€/50 pages).
Le début gratuit a le rôle de bande annonce et si la distribution est libre, la publicité se fait à cout nul.
"La première sécurité est la liberté"
[^] # Re: taxe sur le chiffre d'affaire
Posté par Nicolas Boulay (site web personnel) . En réponse au journal TAXONS LES !. Évalué à 3.
"en regardant l'épargne et dividendes qui devront quand même être dépensés un jour par les riches donc avec TVA)"
Attention quand même au facteur temps, les prélèvements sont pensés annuellement. L'épargne introduit un retard dans le boucle qui est un problème en soi. L'argent qui dort ne sert à rien d'un point de vue global. C'est d'ailleurs marrant de voir que l'augmentation de 30% de la masse monétaire fin 2011 n'a pas produit du tout d'inflation. Cela veut dire qu'elle est resté dans les sphères purement financières sans atteindre le monde réelle et la production de richesse.
Le facteur temps est tellement important, que certain préconise de viser une inflation à 4% plutôt que 2, justement pour forcer les rentiers à investir et rendre les entreprises plus attractif que les livrets d'épargne.
"La première sécurité est la liberté"
[^] # Re: exemples
Posté par Nicolas Boulay (site web personnel) . En réponse à l’entrée du suivi Générer des courbes (fonctionnalité de tableur). Évalué à 2 (+0/-0).
C'est vrai. Sinon il y a aussi le code javascript de http://numcalc.com/ ?
"La première sécurité est la liberté"
[^] # Re: taxe sur le chiffre d'affaire
Posté par Nicolas Boulay (site web personnel) . En réponse au journal TAXONS LES !. Évalué à 2.
C'est surtout que le panier type d'un primo accédant n'est pas celui d'un retraité.
Le logement est représenté par 6% sur le prix des loyers…
"La première sécurité est la liberté"
[^] # Re: taxe sur le chiffre d'affaire
Posté par Nicolas Boulay (site web personnel) . En réponse au journal TAXONS LES !. Évalué à 4.
J'aime bien les gens qui reproche à Zenitram de faire du Zenitram.
Il veut simplement dire que le principe de l'augmentation de la TVA n'implique pas forcément une hausse mécanique plus forte des taux réelle de prélèvement pour les plus pauvres que pour les plus riches. Il y a des moyens de contre-balancer ça.
Devant le manque de travail, il devient absurde d'utiliser le salaire comme base d'imposition, en tout cas pour le commun des mortels. Il faut donc alléger les cotisations sociales et trouver d'autres assiettes. Les bénéfices sont une très mauvaise assiette car le CAC40 se débrouillera toujours pour ne quasiment rien payer au contraire des PME. Il ne reste plus vraiment d'autre piste qui ne soit pas déjà utilisé. (ISF, impôt sur les successions, impôt de bourse, CSG,…)
"La première sécurité est la liberté"
[^] # Re: nanimopt
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nanimstudio, un éditeur d'animations 2d. Évalué à 2.
De mémoire le bin packing avec un tri, permet de garantir d'être à 50% de l'optimal. C'est déjà pas mal.
"La première sécurité est la liberté"
[^] # Re: exemples
Posté par Nicolas Boulay (site web personnel) . En réponse à l’entrée du suivi Générer des courbes (fonctionnalité de tableur). Évalué à 2 (+0/-0).
Le web n'est pas trop mon domaine. Mais j'imagine que modifier le code wiki pour gérer des cellules de données ne doit pas être compliqué.
Quelques exemples :
http://webdesigneraid.com/html5-canvas-graphing-solutions-every-web-developers-must-know/
"La première sécurité est la liberté"
# nanimopt
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Nanimstudio, un éditeur d'animations 2d. Évalué à 2.
Au fait pourquoi tu ne fais pas une recherche exhaustive pour nanimopt ? Il faut quand même un gros nombre d'image pour ne pas arriver à les trier (>100 ?). Beaucoup de problèmes np-complet sont définit avec peu d'éléments. Si cela calcul pendant quelques minutes de plus pour sauver de la place en mémoire, personne ne t'en voudra.
"La première sécurité est la liberté"
[^] # Re: taxe sur le chiffre d'affaire
Posté par Nicolas Boulay (site web personnel) . En réponse au journal TAXONS LES !. Évalué à 3.
Pour l'IR actuel, tu ne peux pas dépasser le dernier taux marginal, c'est pareil.
"La première sécurité est la liberté"
[^] # Re: taxe sur le chiffre d'affaire
Posté par Nicolas Boulay (site web personnel) . En réponse au journal TAXONS LES !. Évalué à 2.
"Oui enfin faudrait savoir, on parlait d'une hypothèse où il n'y aurait que la TVA comme impôt. Si on ajoute l'ISF et l'IR, c'est plus la même chose."
Il n'y aura jamais de changement brutal d'un système à l'autre, il y aura forcément un glissement et donc une cohabitation.
L'ISF peut aussi être vu comme un impôt en avance sur la succession, impôt indiscutable qui évite les dynasties. Mais c'est vrai que le plafond de l'ISF n'a pas bougé alors que l'immobilier à doubler de prix.
"La première sécurité est la liberté"