Donc un oignon n'est pas un légume...
../..
Alors que la fonction en utilisant VRAI = -1 est
du bricolage en connaissant la valeur associée à ce booléen.
../..
Donc un oignon n'est pas un légume...
../..
Alors que la fonction en utilisant VRAI = -1 est
du bricolage en connaissant la valeur associée à ce booléen.
../..
Donc un oignon n'est pas un légume...
../..
Alors que la fonction en utilisant VRAI = -1 est
du bricolage en connaissant la valeur associée à ce booléen.
../..
C'est je crois là où il y a une différence entre les langage de
progammation haut et bas niveau, non ?
C'est je crois là où il y a une différence entre les langage de
progammation haut et bas niveau, non ?
C'est je crois là où il y a une différence entre les langage de
progammation haut et bas niveau, non ?
Je vais utiliser le VRAI que je veux si je suis en dehors d'Excel. Je
suis dans Excel, je vais utiliser le VRAI d'Excel, faut pas être maso
non plus :P
Je vais utiliser le VRAI que je veux si je suis en dehors d'Excel. Je
suis dans Excel, je vais utiliser le VRAI d'Excel, faut pas être maso
non plus :P
Je vais utiliser le VRAI que je veux si je suis en dehors d'Excel. Je
suis dans Excel, je vais utiliser le VRAI d'Excel, faut pas être maso
non plus :P
Donc un oignon n'est pas un légume...
Donc un oignon n'est pas un légume...
Donc un oignon n'est pas un légume...
Si j'ai de grosses lacunes, je ne crois pas que ce soit dans les
notions basiques. Ou alors, nous ne sommes vraiment pas dans le même
milieu, car des personnes qui connaissent plus de bases d'Excel que
moi, je n'en connais pas tellement.
Après je sais qu'il y a des
personnes qui en connaissent bien plus, mais je ne dirais pas que les
connaissances qui me restent à acquérir soient basiques.
Si j'ai de grosses lacunes, je ne crois pas que ce soit dans les
notions basiques. Ou alors, nous ne sommes vraiment pas dans le même
milieu, car des personnes qui connaissent plus de bases d'Excel que
moi, je n'en connais pas tellement.
Après je sais qu'il y a des
personnes qui en connaissent bien plus, mais je ne dirais pas que les
connaissances qui me restent à acquérir soient basiques.
Si j'ai de grosses lacunes, je ne crois pas que ce soit dans les
notions basiques. Ou alors, nous ne sommes vraiment pas dans le même
milieu, car des personnes qui connaissent plus de bases d'Excel que
moi, je n'en connais pas tellement.
Après je sais qu'il y a des
personnes qui en connaissent bien plus, mais je ne dirais pas que les
connaissances qui me restent à acquérir soient basiques.
J'ai du mal à saisir ce que tu veux démontrer et tes exemples poireaux
carottes me donnent faim mais c'est tout.
Que les VRAIS programmateurs, ceux qui ont besoin d'un langage super
robuste, imposant des types de variables non convertibles à la volée,
avec un contrôle d'erreur très pointu... n'utilisent pas VBA c'est une
certitude
calculée dans un tableur...
Mais excel et son VBA n'est pas fait pour ces gens là. Et il offre une
souplesse qui permet de faire assez simplement ce qui serait
inaccessible à des non informaticien. Tu sais moi le coup des
informaticiens qui causent aux informaticiens ça me laisse de glace.
Ton exemple ou tu remplaces les vrais et les faux par des 0 ou des 1
ajoutés dans la colonne voisine montre que tu ne vois pas quels usages
les VRAIS utilisateurs d'excel (boutade !) font de ce tableur.
Je voudrais que tu voies certains tableaux, tu comprendrais vite que
ce que tu proposes n'est tout simplement pas faisable sur un plan
pratique et qu'il est autrement plus raisonnable de demander à excel
d'interpréter les vrais et les faux même si cela te chagrine.
Il se trouve que la clientèle d'excel n'est pas celle des programmeurs
professionnels. Du reste ceux là regardent en général avec dédain ce
pseudo langage.
Fort bien. Qu'ils programment en C++ ou en Pascal
s'ils préfère. Moi je n'ai jamais suivi un seul cours d'informatique
de ma
vie, mais j'utilise VBA tous les jours dans mon boulot qui n'a rien à
voire avec l'informatique. Mes codes sont souvent très crades, pas
finalisés parce qu'à usage quasi unique mais justement dans ces cas
là, j'apprécie +++ la tolérance d'excel.
Ne pas utiliser sommeprod ??? Au secours. ce n'est pas parce qu'en la
définissant microsoft n'avait pas du tout pensé à l'usage super
puissant qui peut en être fait, et qui n'est donc pas documenté, que
cette fonction ne doit pas être utilisée !
La question n'est pas de savoir qui possède ou pas les connaissances
basiques du fonctionnement d'excel. Franchement on s'en fout. ce qui
est intéressant avec excel c'est que des gens très très différents,
avec des niveaux de compétences très très variables l'utilisent pour
faire des choses que beaucoup n'imaginent même pas demander à un
tableur. Et justement ce qui permet ça c'est une certaine souplesse.
Maintenant encore une fois, j'espère que ce qui a besoin d'être
calculé à la 50° décimale ne l'est pas avec excel.
Mais cette discussion m'amuse beaucoup : habituellement la
conversation type c'est de dire OUI il FAUT déclarer ses variables,
c'est utile et ça évite les erreurs même si excel est très tolérant
et essaie
d'interpréter vos à peu près. Là nous voilà partis dans l'extrême
opposé. Ça change :-)
Excel est un langage de programmation pour amateurs ? oui peut être et
alors ? Je revendique pour ma part le fait d'être une amateur sur
excel. J'aime excel voilà, je fais mon coming out, c'est un grand
jour :-)
J'ai du mal à saisir ce que tu veux démontrer et tes exemples poireaux
carottes me donnent faim mais c'est tout.
Que les VRAIS programmateurs, ceux qui ont besoin d'un langage super
robuste, imposant des types de variables non convertibles à la volée,
avec un contrôle d'erreur très pointu... n'utilisent pas VBA c'est une
certitude
calculée dans un tableur...
Mais excel et son VBA n'est pas fait pour ces gens là. Et il offre une
souplesse qui permet de faire assez simplement ce qui serait
inaccessible à des non informaticien. Tu sais moi le coup des
informaticiens qui causent aux informaticiens ça me laisse de glace.
Ton exemple ou tu remplaces les vrais et les faux par des 0 ou des 1
ajoutés dans la colonne voisine montre que tu ne vois pas quels usages
les VRAIS utilisateurs d'excel (boutade !) font de ce tableur.
Je voudrais que tu voies certains tableaux, tu comprendrais vite que
ce que tu proposes n'est tout simplement pas faisable sur un plan
pratique et qu'il est autrement plus raisonnable de demander à excel
d'interpréter les vrais et les faux même si cela te chagrine.
Il se trouve que la clientèle d'excel n'est pas celle des programmeurs
professionnels. Du reste ceux là regardent en général avec dédain ce
pseudo langage.
Fort bien. Qu'ils programment en C++ ou en Pascal
s'ils préfère. Moi je n'ai jamais suivi un seul cours d'informatique
de ma
vie, mais j'utilise VBA tous les jours dans mon boulot qui n'a rien à
voire avec l'informatique. Mes codes sont souvent très crades, pas
finalisés parce qu'à usage quasi unique mais justement dans ces cas
là, j'apprécie +++ la tolérance d'excel.
Ne pas utiliser sommeprod ??? Au secours. ce n'est pas parce qu'en la
définissant microsoft n'avait pas du tout pensé à l'usage super
puissant qui peut en être fait, et qui n'est donc pas documenté, que
cette fonction ne doit pas être utilisée !
La question n'est pas de savoir qui possède ou pas les connaissances
basiques du fonctionnement d'excel. Franchement on s'en fout. ce qui
est intéressant avec excel c'est que des gens très très différents,
avec des niveaux de compétences très très variables l'utilisent pour
faire des choses que beaucoup n'imaginent même pas demander à un
tableur. Et justement ce qui permet ça c'est une certaine souplesse.
Maintenant encore une fois, j'espère que ce qui a besoin d'être
calculé à la 50° décimale ne l'est pas avec excel.
Mais cette discussion m'amuse beaucoup : habituellement la
conversation type c'est de dire OUI il FAUT déclarer ses variables,
c'est utile et ça évite les erreurs même si excel est très tolérant
et essaie
d'interpréter vos à peu près. Là nous voilà partis dans l'extrême
opposé. Ça change :-)
Excel est un langage de programmation pour amateurs ? oui peut être et
alors ? Je revendique pour ma part le fait d'être une amateur sur
excel. J'aime excel voilà, je fais mon coming out, c'est un grand
jour :-)
J'ai du mal à saisir ce que tu veux démontrer et tes exemples poireaux
carottes me donnent faim mais c'est tout.
Que les VRAIS programmateurs, ceux qui ont besoin d'un langage super
robuste, imposant des types de variables non convertibles à la volée,
avec un contrôle d'erreur très pointu... n'utilisent pas VBA c'est une
certitude
calculée dans un tableur...
Mais excel et son VBA n'est pas fait pour ces gens là. Et il offre une
souplesse qui permet de faire assez simplement ce qui serait
inaccessible à des non informaticien. Tu sais moi le coup des
informaticiens qui causent aux informaticiens ça me laisse de glace.
Ton exemple ou tu remplaces les vrais et les faux par des 0 ou des 1
ajoutés dans la colonne voisine montre que tu ne vois pas quels usages
les VRAIS utilisateurs d'excel (boutade !) font de ce tableur.
Je voudrais que tu voies certains tableaux, tu comprendrais vite que
ce que tu proposes n'est tout simplement pas faisable sur un plan
pratique et qu'il est autrement plus raisonnable de demander à excel
d'interpréter les vrais et les faux même si cela te chagrine.
Il se trouve que la clientèle d'excel n'est pas celle des programmeurs
professionnels. Du reste ceux là regardent en général avec dédain ce
pseudo langage.
Fort bien. Qu'ils programment en C++ ou en Pascal
s'ils préfère. Moi je n'ai jamais suivi un seul cours d'informatique
de ma
vie, mais j'utilise VBA tous les jours dans mon boulot qui n'a rien à
voire avec l'informatique. Mes codes sont souvent très crades, pas
finalisés parce qu'à usage quasi unique mais justement dans ces cas
là, j'apprécie +++ la tolérance d'excel.
Ne pas utiliser sommeprod ??? Au secours. ce n'est pas parce qu'en la
définissant microsoft n'avait pas du tout pensé à l'usage super
puissant qui peut en être fait, et qui n'est donc pas documenté, que
cette fonction ne doit pas être utilisée !
La question n'est pas de savoir qui possède ou pas les connaissances
basiques du fonctionnement d'excel. Franchement on s'en fout. ce qui
est intéressant avec excel c'est que des gens très très différents,
avec des niveaux de compétences très très variables l'utilisent pour
faire des choses que beaucoup n'imaginent même pas demander à un
tableur. Et justement ce qui permet ça c'est une certaine souplesse.
Maintenant encore une fois, j'espère que ce qui a besoin d'être
calculé à la 50° décimale ne l'est pas avec excel.
Mais cette discussion m'amuse beaucoup : habituellement la
conversation type c'est de dire OUI il FAUT déclarer ses variables,
c'est utile et ça évite les erreurs même si excel est très tolérant
et essaie
d'interpréter vos à peu près. Là nous voilà partis dans l'extrême
opposé. Ça change :-)
Excel est un langage de programmation pour amateurs ? oui peut être et
alors ? Je revendique pour ma part le fait d'être une amateur sur
excel. J'aime excel voilà, je fais mon coming out, c'est un grand
jour :-)
Bonsour® JérômeC avec ferveur ;o))) vous nous disiez :
Je vais utiliser le VRAI que je veux si je suis en dehors d'Excel. Je
suis dans Excel, je vais utiliser le VRAI d'Excel, faut pas être maso
non plus :P
;o)))
il y a deux vrais dans EXCEL !!!!
VRAI formule de calcul =1
TRUE VBA = -1
faut pas être obtus non plus ;-P
Bonsour® JérômeC avec ferveur ;o))) vous nous disiez :
Je vais utiliser le VRAI que je veux si je suis en dehors d'Excel. Je
suis dans Excel, je vais utiliser le VRAI d'Excel, faut pas être maso
non plus :P
;o)))
il y a deux vrais dans EXCEL !!!!
VRAI formule de calcul =1
TRUE VBA = -1
faut pas être obtus non plus ;-P
Bonsour® JérômeC avec ferveur ;o))) vous nous disiez :
Je vais utiliser le VRAI que je veux si je suis en dehors d'Excel. Je
suis dans Excel, je vais utiliser le VRAI d'Excel, faut pas être maso
non plus :P
;o)))
il y a deux vrais dans EXCEL !!!!
VRAI formule de calcul =1
TRUE VBA = -1
faut pas être obtus non plus ;-P
C'est je crois là où il y a une différence entre les langage de
progammation haut et bas niveau, non ?
C'est je crois là où il y a une différence entre les langage de
progammation haut et bas niveau, non ?
C'est je crois là où il y a une différence entre les langage de
progammation haut et bas niveau, non ?
Bonjour Jérome
J'ai du mal à saisir ce que tu veux démontrer et tes exemples poireaux
carottes me donnent faim mais c'est tout.
Qui a dit que VBA était THE langage de programmation parfait ?
Que les VRAIS programmateurs, ceux qui ont besoin d'un langage super
robuste, imposant des types de variables non convertibles à la volée, avec
un contrôle d'erreur très pointu... n'utilisent pas VBA c'est une
certitude et je préfère que la trajectoire des missiles ne soit pas
calculée dans un tableur...
Mais excel et son VBA n'est pas fait pour ces gens là. Et il offre une
souplesse qui permet de faire assez simplement ce qui serait inaccessible
à des non informaticien. Tu sais moi le coup des informaticiens qui
causent aux informaticiens ça me laisse de glace.
Ton exemple ou tu remplaces les vrais et les faux par des 0 ou des 1
ajoutés dans la colonne voisine montre que tu ne vois pas quels usages les
VRAIS utilisateurs d'excel (boutade !) font de ce tableur.
Je voudrais que tu voies certains tableaux, tu comprendrais vite que ce
que tu proposes n'est tout simplement pas faisable sur un plan pratique et
qu'il est autrement plus raisonnable de demander à excel d'interpréter les
vrais et les faux même si cela te chagrine.
Il se trouve que la clientèle d'excel n'est pas celle des programmeurs
professionnels. Du reste ceux là regardent en général avec dédain ce
pseudo langage. Fort bien. Qu'ils programment en C++ ou en Pascal s'ils
préfère. Moi je n'ai jamais suivi un seul cours d'informatique de ma vie,
mais j'utilise VBA tous les jours dans mon boulot qui n'a rien à voire
avec l'informatique. Mes codes sont souvent très crades, pas finalisés
parce qu'à usage quasi unique mais justement dans ces cas là, j'apprécie
+++ la tolérance d'excel.
Ne pas utiliser sommeprod ??? Au secours. ce n'est pas parce qu'en la
définissant microsoft n'avait pas du tout pensé à l'usage super puissant
qui peut en être fait, et qui n'est donc pas documenté, que cette fonction
ne doit pas être utilisée !
La question n'est pas de savoir qui possède ou pas les connaissances
basiques du fonctionnement d'excel. Franchement on s'en fout. ce qui est
intéressant avec excel c'est que des gens très très différents, avec des
niveaux de compétences très très variables l'utilisent pour faire des
choses que beaucoup n'imaginent même pas demander à un tableur. Et
justement ce qui permet ça c'est une certaine souplesse. Maintenant encore
une fois, j'espère que ce qui a besoin d'être calculé à la 50° décimale ne
l'est pas avec excel.
Mais cette discussion m'amuse beaucoup : habituellement la conversation
type c'est de dire OUI il FAUT déclarer ses variables, c'est utile et ça
évite les erreurs même si excel est très tolérant et essaie d'interpréter
vos à peu près. Là nous voilà partis dans l'extrême opposé. Ça change :-)
Excel est un langage de programmation pour amateurs ? oui peut être et
alors ? Je revendique pour ma part le fait d'être une amateur sur excel.
J'aime excel voilà, je fais mon coming out, c'est un grand jour :-)
Misange migrateuse
http://www.excelabo.net : Participez à un travail collaboratif sur excel !
JérômeC a écrit :| Dans Excel, le poireau booléen est aussi une carotte nombre.
**** C'est nouveau ça ! Tu as quelle version d'Excel ?
Une valeur booléenne demeure une valeur booléenne et je n'ai
jamais rien lu ou vu quelque chose qui allait dans le sens opposé dans
Excel.
Ce qu'Excel permet c'est la transformation de cette valeur booléenne
en valeur numérique. Pour ce faire, on pourrait une "vraie" fonction
comme N(), mais Excel permet la conversion de cette valeur en utilisant
plus d'une approche. On ne va pas lui reprocher sa flexibilité ?
Exemple :
si je demande à excel d'additionner :
=SOMME({VRAI;VRAI;VRAI}) = 0 et le 0 ne signifie pas que c'est faux
Excel reconnaît les "Vrai" comme valeur booléenne
(si tu les tapes en minuscules, Excel les affiche en majuscule à la
validation de la cellule, de plus ces expressions ne nécessitent
pas de guillemets) mais il ne les transforme pas en valeur numérique
de lui-même. La fonction "Somme" considère ces valeurs comme
étant du "texte" d'où le résultat.
Si Excel ne faisait pas de différence entre une valeur booléenne et
sa valeur numérique il retournerait 3. NON ????
Pourtant, on a diverses alternatives pour demander à Excel de
"CONVERTIR"
ces "Vrai" par leur équivalent numérique... quelques exemples possibles
et ils ne sont pas exhaustifs !
=SOMME(N({VRAI;VRAI;VRAI})) = 3
=SOMME({VRAI;VRAI;VRAI}+0) =3
=SOMME({VRAI;VRAI;VRAI}*1) = 3
Pour moi, seule le premier exemple a un sens. Je connais les deux autres.
À vrai dire, je suis surpris du résultat de =SOMME({VRAI;VRAI;VRAI}) ,
car =VRAI + VRAI + VRAI = 3. Et la différence entre les deux me laisse
vraiment perplexe. C'est exactement ce que je disais dans un autre
message : On ne sait pas quand Excel réalise une conversion ! (S'il y a
un endroit où c'est indiqué, une quelconque documentation m'indiquant
cela, je veux bien savoir où, les bases d'Excel m'intéresse)| Mais j'ai une certaine vision de la programmation qui est une
| programmation maintenable par n'importe qui connait la grammaire.
**** Si tu connais la grammaire d'excel, tu devrais pouvoir lire...
On ne peut pas dire qu'Excel cache sa grammaire !
Cf ma remarque ci-dessus.En vba, il est permis ceci :
'-------------------------------
Sub test()
Dim X As Boolean
X = 1
MsgBox TypeName(X)
End Sub
'-------------------------------
Après l'exécution, X = True et la boîte de message affiche
toujours que le type de la variable X est demeurer "Booléenne et
non "Integer", "Long" ....!
Encore heureux !
Mais des trucs avec la plébiscitée variable de type Variant, tu peux vite
foutre le bordel.
Dim X as Variant
X = vrai
X = 1
MsgBox TypeName(X) ??Je veux bien reconnaître que VBA est un langage de
programmation plus souple que d'autres langages de programmation.
Cela sert bien l'ensemble des usagers des applications Microsoft
car la majeure partie de ceux-ci ne sont pas des programmeurs de
formation.
Mais les gens qui en font un usage intensif généralement le font en
respectant les principes de base de la programmation.
Souple, certes, mais tellement souple que faire des noeuds s'en s'en
rendre compte est super facile. Avec Excel, je n'ai jamais eu de soucis.
Mais j'ai essayé avec Access, j'ai laissé tombé avec mon paquet de noeud.
Les principes de base de la programmation, je me demande bien ce que
c'est. J'ai eu certaines réponses d'un support à un kit de développement
(rien à voir avec Microsoft) bien surprenante. Et c'est sans parler de
certains bouts de code qui trainent sur le web, ni des perles de
programmation.
Bonjour Jérome
J'ai du mal à saisir ce que tu veux démontrer et tes exemples poireaux
carottes me donnent faim mais c'est tout.
Qui a dit que VBA était THE langage de programmation parfait ?
Que les VRAIS programmateurs, ceux qui ont besoin d'un langage super
robuste, imposant des types de variables non convertibles à la volée, avec
un contrôle d'erreur très pointu... n'utilisent pas VBA c'est une
certitude et je préfère que la trajectoire des missiles ne soit pas
calculée dans un tableur...
Mais excel et son VBA n'est pas fait pour ces gens là. Et il offre une
souplesse qui permet de faire assez simplement ce qui serait inaccessible
à des non informaticien. Tu sais moi le coup des informaticiens qui
causent aux informaticiens ça me laisse de glace.
Ton exemple ou tu remplaces les vrais et les faux par des 0 ou des 1
ajoutés dans la colonne voisine montre que tu ne vois pas quels usages les
VRAIS utilisateurs d'excel (boutade !) font de ce tableur.
Je voudrais que tu voies certains tableaux, tu comprendrais vite que ce
que tu proposes n'est tout simplement pas faisable sur un plan pratique et
qu'il est autrement plus raisonnable de demander à excel d'interpréter les
vrais et les faux même si cela te chagrine.
Il se trouve que la clientèle d'excel n'est pas celle des programmeurs
professionnels. Du reste ceux là regardent en général avec dédain ce
pseudo langage. Fort bien. Qu'ils programment en C++ ou en Pascal s'ils
préfère. Moi je n'ai jamais suivi un seul cours d'informatique de ma vie,
mais j'utilise VBA tous les jours dans mon boulot qui n'a rien à voire
avec l'informatique. Mes codes sont souvent très crades, pas finalisés
parce qu'à usage quasi unique mais justement dans ces cas là, j'apprécie
+++ la tolérance d'excel.
Ne pas utiliser sommeprod ??? Au secours. ce n'est pas parce qu'en la
définissant microsoft n'avait pas du tout pensé à l'usage super puissant
qui peut en être fait, et qui n'est donc pas documenté, que cette fonction
ne doit pas être utilisée !
La question n'est pas de savoir qui possède ou pas les connaissances
basiques du fonctionnement d'excel. Franchement on s'en fout. ce qui est
intéressant avec excel c'est que des gens très très différents, avec des
niveaux de compétences très très variables l'utilisent pour faire des
choses que beaucoup n'imaginent même pas demander à un tableur. Et
justement ce qui permet ça c'est une certaine souplesse. Maintenant encore
une fois, j'espère que ce qui a besoin d'être calculé à la 50° décimale ne
l'est pas avec excel.
Mais cette discussion m'amuse beaucoup : habituellement la conversation
type c'est de dire OUI il FAUT déclarer ses variables, c'est utile et ça
évite les erreurs même si excel est très tolérant et essaie d'interpréter
vos à peu près. Là nous voilà partis dans l'extrême opposé. Ça change :-)
Excel est un langage de programmation pour amateurs ? oui peut être et
alors ? Je revendique pour ma part le fait d'être une amateur sur excel.
J'aime excel voilà, je fais mon coming out, c'est un grand jour :-)
Misange migrateuse
http://www.excelabo.net : Participez à un travail collaboratif sur excel !
JérômeC a écrit :
| Dans Excel, le poireau booléen est aussi une carotte nombre.
**** C'est nouveau ça ! Tu as quelle version d'Excel ?
Une valeur booléenne demeure une valeur booléenne et je n'ai
jamais rien lu ou vu quelque chose qui allait dans le sens opposé dans
Excel.
Ce qu'Excel permet c'est la transformation de cette valeur booléenne
en valeur numérique. Pour ce faire, on pourrait une "vraie" fonction
comme N(), mais Excel permet la conversion de cette valeur en utilisant
plus d'une approche. On ne va pas lui reprocher sa flexibilité ?
Exemple :
si je demande à excel d'additionner :
=SOMME({VRAI;VRAI;VRAI}) = 0 et le 0 ne signifie pas que c'est faux
Excel reconnaît les "Vrai" comme valeur booléenne
(si tu les tapes en minuscules, Excel les affiche en majuscule à la
validation de la cellule, de plus ces expressions ne nécessitent
pas de guillemets) mais il ne les transforme pas en valeur numérique
de lui-même. La fonction "Somme" considère ces valeurs comme
étant du "texte" d'où le résultat.
Si Excel ne faisait pas de différence entre une valeur booléenne et
sa valeur numérique il retournerait 3. NON ????
Pourtant, on a diverses alternatives pour demander à Excel de
"CONVERTIR"
ces "Vrai" par leur équivalent numérique... quelques exemples possibles
et ils ne sont pas exhaustifs !
=SOMME(N({VRAI;VRAI;VRAI})) = 3
=SOMME({VRAI;VRAI;VRAI}+0) =3
=SOMME({VRAI;VRAI;VRAI}*1) = 3
Pour moi, seule le premier exemple a un sens. Je connais les deux autres.
À vrai dire, je suis surpris du résultat de =SOMME({VRAI;VRAI;VRAI}) ,
car =VRAI + VRAI + VRAI = 3. Et la différence entre les deux me laisse
vraiment perplexe. C'est exactement ce que je disais dans un autre
message : On ne sait pas quand Excel réalise une conversion ! (S'il y a
un endroit où c'est indiqué, une quelconque documentation m'indiquant
cela, je veux bien savoir où, les bases d'Excel m'intéresse)
| Mais j'ai une certaine vision de la programmation qui est une
| programmation maintenable par n'importe qui connait la grammaire.
**** Si tu connais la grammaire d'excel, tu devrais pouvoir lire...
On ne peut pas dire qu'Excel cache sa grammaire !
Cf ma remarque ci-dessus.
En vba, il est permis ceci :
'-------------------------------
Sub test()
Dim X As Boolean
X = 1
MsgBox TypeName(X)
End Sub
'-------------------------------
Après l'exécution, X = True et la boîte de message affiche
toujours que le type de la variable X est demeurer "Booléenne et
non "Integer", "Long" ....!
Encore heureux !
Mais des trucs avec la plébiscitée variable de type Variant, tu peux vite
foutre le bordel.
Dim X as Variant
X = vrai
X = 1
MsgBox TypeName(X) ??
Je veux bien reconnaître que VBA est un langage de
programmation plus souple que d'autres langages de programmation.
Cela sert bien l'ensemble des usagers des applications Microsoft
car la majeure partie de ceux-ci ne sont pas des programmeurs de
formation.
Mais les gens qui en font un usage intensif généralement le font en
respectant les principes de base de la programmation.
Souple, certes, mais tellement souple que faire des noeuds s'en s'en
rendre compte est super facile. Avec Excel, je n'ai jamais eu de soucis.
Mais j'ai essayé avec Access, j'ai laissé tombé avec mon paquet de noeud.
Les principes de base de la programmation, je me demande bien ce que
c'est. J'ai eu certaines réponses d'un support à un kit de développement
(rien à voir avec Microsoft) bien surprenante. Et c'est sans parler de
certains bouts de code qui trainent sur le web, ni des perles de
programmation.
Bonjour Jérome
J'ai du mal à saisir ce que tu veux démontrer et tes exemples poireaux
carottes me donnent faim mais c'est tout.
Qui a dit que VBA était THE langage de programmation parfait ?
Que les VRAIS programmateurs, ceux qui ont besoin d'un langage super
robuste, imposant des types de variables non convertibles à la volée, avec
un contrôle d'erreur très pointu... n'utilisent pas VBA c'est une
certitude et je préfère que la trajectoire des missiles ne soit pas
calculée dans un tableur...
Mais excel et son VBA n'est pas fait pour ces gens là. Et il offre une
souplesse qui permet de faire assez simplement ce qui serait inaccessible
à des non informaticien. Tu sais moi le coup des informaticiens qui
causent aux informaticiens ça me laisse de glace.
Ton exemple ou tu remplaces les vrais et les faux par des 0 ou des 1
ajoutés dans la colonne voisine montre que tu ne vois pas quels usages les
VRAIS utilisateurs d'excel (boutade !) font de ce tableur.
Je voudrais que tu voies certains tableaux, tu comprendrais vite que ce
que tu proposes n'est tout simplement pas faisable sur un plan pratique et
qu'il est autrement plus raisonnable de demander à excel d'interpréter les
vrais et les faux même si cela te chagrine.
Il se trouve que la clientèle d'excel n'est pas celle des programmeurs
professionnels. Du reste ceux là regardent en général avec dédain ce
pseudo langage. Fort bien. Qu'ils programment en C++ ou en Pascal s'ils
préfère. Moi je n'ai jamais suivi un seul cours d'informatique de ma vie,
mais j'utilise VBA tous les jours dans mon boulot qui n'a rien à voire
avec l'informatique. Mes codes sont souvent très crades, pas finalisés
parce qu'à usage quasi unique mais justement dans ces cas là, j'apprécie
+++ la tolérance d'excel.
Ne pas utiliser sommeprod ??? Au secours. ce n'est pas parce qu'en la
définissant microsoft n'avait pas du tout pensé à l'usage super puissant
qui peut en être fait, et qui n'est donc pas documenté, que cette fonction
ne doit pas être utilisée !
La question n'est pas de savoir qui possède ou pas les connaissances
basiques du fonctionnement d'excel. Franchement on s'en fout. ce qui est
intéressant avec excel c'est que des gens très très différents, avec des
niveaux de compétences très très variables l'utilisent pour faire des
choses que beaucoup n'imaginent même pas demander à un tableur. Et
justement ce qui permet ça c'est une certaine souplesse. Maintenant encore
une fois, j'espère que ce qui a besoin d'être calculé à la 50° décimale ne
l'est pas avec excel.
Mais cette discussion m'amuse beaucoup : habituellement la conversation
type c'est de dire OUI il FAUT déclarer ses variables, c'est utile et ça
évite les erreurs même si excel est très tolérant et essaie d'interpréter
vos à peu près. Là nous voilà partis dans l'extrême opposé. Ça change :-)
Excel est un langage de programmation pour amateurs ? oui peut être et
alors ? Je revendique pour ma part le fait d'être une amateur sur excel.
J'aime excel voilà, je fais mon coming out, c'est un grand jour :-)
Misange migrateuse
http://www.excelabo.net : Participez à un travail collaboratif sur excel !
JérômeC a écrit :| Dans Excel, le poireau booléen est aussi une carotte nombre.
**** C'est nouveau ça ! Tu as quelle version d'Excel ?
Une valeur booléenne demeure une valeur booléenne et je n'ai
jamais rien lu ou vu quelque chose qui allait dans le sens opposé dans
Excel.
Ce qu'Excel permet c'est la transformation de cette valeur booléenne
en valeur numérique. Pour ce faire, on pourrait une "vraie" fonction
comme N(), mais Excel permet la conversion de cette valeur en utilisant
plus d'une approche. On ne va pas lui reprocher sa flexibilité ?
Exemple :
si je demande à excel d'additionner :
=SOMME({VRAI;VRAI;VRAI}) = 0 et le 0 ne signifie pas que c'est faux
Excel reconnaît les "Vrai" comme valeur booléenne
(si tu les tapes en minuscules, Excel les affiche en majuscule à la
validation de la cellule, de plus ces expressions ne nécessitent
pas de guillemets) mais il ne les transforme pas en valeur numérique
de lui-même. La fonction "Somme" considère ces valeurs comme
étant du "texte" d'où le résultat.
Si Excel ne faisait pas de différence entre une valeur booléenne et
sa valeur numérique il retournerait 3. NON ????
Pourtant, on a diverses alternatives pour demander à Excel de
"CONVERTIR"
ces "Vrai" par leur équivalent numérique... quelques exemples possibles
et ils ne sont pas exhaustifs !
=SOMME(N({VRAI;VRAI;VRAI})) = 3
=SOMME({VRAI;VRAI;VRAI}+0) =3
=SOMME({VRAI;VRAI;VRAI}*1) = 3
Pour moi, seule le premier exemple a un sens. Je connais les deux autres.
À vrai dire, je suis surpris du résultat de =SOMME({VRAI;VRAI;VRAI}) ,
car =VRAI + VRAI + VRAI = 3. Et la différence entre les deux me laisse
vraiment perplexe. C'est exactement ce que je disais dans un autre
message : On ne sait pas quand Excel réalise une conversion ! (S'il y a
un endroit où c'est indiqué, une quelconque documentation m'indiquant
cela, je veux bien savoir où, les bases d'Excel m'intéresse)| Mais j'ai une certaine vision de la programmation qui est une
| programmation maintenable par n'importe qui connait la grammaire.
**** Si tu connais la grammaire d'excel, tu devrais pouvoir lire...
On ne peut pas dire qu'Excel cache sa grammaire !
Cf ma remarque ci-dessus.En vba, il est permis ceci :
'-------------------------------
Sub test()
Dim X As Boolean
X = 1
MsgBox TypeName(X)
End Sub
'-------------------------------
Après l'exécution, X = True et la boîte de message affiche
toujours que le type de la variable X est demeurer "Booléenne et
non "Integer", "Long" ....!
Encore heureux !
Mais des trucs avec la plébiscitée variable de type Variant, tu peux vite
foutre le bordel.
Dim X as Variant
X = vrai
X = 1
MsgBox TypeName(X) ??Je veux bien reconnaître que VBA est un langage de
programmation plus souple que d'autres langages de programmation.
Cela sert bien l'ensemble des usagers des applications Microsoft
car la majeure partie de ceux-ci ne sont pas des programmeurs de
formation.
Mais les gens qui en font un usage intensif généralement le font en
respectant les principes de base de la programmation.
Souple, certes, mais tellement souple que faire des noeuds s'en s'en
rendre compte est super facile. Avec Excel, je n'ai jamais eu de soucis.
Mais j'ai essayé avec Access, j'ai laissé tombé avec mon paquet de noeud.
Les principes de base de la programmation, je me demande bien ce que
c'est. J'ai eu certaines réponses d'un support à un kit de développement
(rien à voir avec Microsoft) bien surprenante. Et c'est sans parler de
certains bouts de code qui trainent sur le web, ni des perles de
programmation.
>;o)))
chaque langage posséde sa grammaire !!!!
et ici le langage macro VBA(US) est différent du langage EXCEL formule
feuille de calcul(FR)
>;o)))
chaque langage posséde sa grammaire !!!!
et ici le langage macro VBA(US) est différent du langage EXCEL formule
feuille de calcul(FR)
>;o)))
chaque langage posséde sa grammaire !!!!
et ici le langage macro VBA(US) est différent du langage EXCEL formule
feuille de calcul(FR)
