On 17 juil, 16:57, totof2000 wrote:
> Un compilo qui ne sait pas aligner tout seul les données dans une structure,
> quitte à laisser des trous, c'est pas très sérieux.
Tout dépend du compilo et de ce que tu fais avec ....
Quand tu fais du dev bas niveau avec des accès hard, tu n'as pas
toujours envie que le compilo réorganise tes structures sans te
prévenir .....
Quand on veut faire du dev bas niveau avec des accès hard, on ne le
fait pas en Fortran, tout simplement. Il y a des langages plus
adaptés, plutôt que de faire des contorsions qui n'est pas fait pour à
la base.
On 17 juil, 16:57, totof2000 <cdesques...@ifrance.com> wrote:
> Un compilo qui ne sait pas aligner tout seul les données dans une structure,
> quitte à laisser des trous, c'est pas très sérieux.
Tout dépend du compilo et de ce que tu fais avec ....
Quand tu fais du dev bas niveau avec des accès hard, tu n'as pas
toujours envie que le compilo réorganise tes structures sans te
prévenir .....
Quand on veut faire du dev bas niveau avec des accès hard, on ne le
fait pas en Fortran, tout simplement. Il y a des langages plus
adaptés, plutôt que de faire des contorsions qui n'est pas fait pour à
la base.
On 17 juil, 16:57, totof2000 wrote:
> Un compilo qui ne sait pas aligner tout seul les données dans une structure,
> quitte à laisser des trous, c'est pas très sérieux.
Tout dépend du compilo et de ce que tu fais avec ....
Quand tu fais du dev bas niveau avec des accès hard, tu n'as pas
toujours envie que le compilo réorganise tes structures sans te
prévenir .....
Quand on veut faire du dev bas niveau avec des accès hard, on ne le
fait pas en Fortran, tout simplement. Il y a des langages plus
adaptés, plutôt que de faire des contorsions qui n'est pas fait pour à
la base.
Même sans ça. Tu peux très bien faire des hypothè ses sur le
placement en mémoire de tes objets pour optimiser certains codes.
>> > Les déclarations X*Y proviennent des extensions VAX et le Y est le
>> > nombre d'octets de la variable. J'aimerais que tu nous donnes ici un
>> > seul compilo fortran qui pour logical*1 positionne autre chose d'un
>> > drapeau sur un octet
>> Fais ton choix :
>>http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html
>> Voilà : ça n'a *jamais* été normalisé. Et de fait écrire u n code en
>> supposant par exemple que REAL*8 va occuper la même place qu'un DOUB LE
>> PRECISION est casse-gueule du point de vue portabilité (cas vécu).
Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont portab les
d'un compilo à l'autre. Même le compilo Fortran 5.x de Microsoft les
comprenait, c'est dire !
>> > Au passage, LOGICAL*1 et LOGICAL(1), ce n'est pas la même chose. J e
>> > te laisse chercher un peu.
>> Exact
Tu as pourtant écrit juste un peu plus haut LOGICAL(n) alors que je
te parle de LOGICAL*n, ce qui est _différent_.
>> > Il y a longtemps que tu n'as pas vu un code Fortran, toi !
>> J'en fais juste tous les jours, ou presque.
Un type qui est infoutu de faire la différence entre LO GICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.
>> Et je maintiens : en comparaison du C, la norme Fortran se soucie tr ès peu
>> de la façon dont sont représentées les données en mémoire, e t ça s'est
>> accentué depuis le Fortran 90 (tableaux qui ne sont plus forcément contigus
>> en mémoire, etc...).
Gnîii ? Là, tu mélanges allègrement deux notions, mais venant de
toi, je m'attends vraiment à tout !...
>> La seule contrainte de ce genre en Fortran est qu'un
>> REAL ou un LOGICAL doivent occuper exactement la place d'un INTEGER (s ans
>> que ce soit forcément un mot machine) et qu'un COMPLEX ou un DOUBLE
>> PRECISION doivent occuper la place de deux REAL. Tout le reste est à la
>> libre appréciation du compilo.
Faux. J'ai la flemme de chercher dans la doc, mais j'ai a u moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit.
J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est deux
fois plus long qu'un REAL. Enfin, c'est à toi de voir.
>> D'ailleurs je note que les extensions Y*n n'ont jamais été normali sées alors
>> qu'elles étaient très courantes. A la place ce sont les Y(KIND=m ) qui l'ont
>> été, qui sont très différents des Y*n comme tu l'as rappelé, et qui
>> notamment ne disent *rien* sur la place occupée en mémoire.
Ça, c'est parce que tu codes comme un pied. Il y a un m écanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de ta
plage. Je te laisse là encore chercher.
Même sans ça. Tu peux très bien faire des hypothè ses sur le
placement en mémoire de tes objets pour optimiser certains codes.
>> > Les déclarations X*Y proviennent des extensions VAX et le Y est le
>> > nombre d'octets de la variable. J'aimerais que tu nous donnes ici un
>> > seul compilo fortran qui pour logical*1 positionne autre chose d'un
>> > drapeau sur un octet
>> Fais ton choix :
>>http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html
>> Voilà : ça n'a *jamais* été normalisé. Et de fait écrire u n code en
>> supposant par exemple que REAL*8 va occuper la même place qu'un DOUB LE
>> PRECISION est casse-gueule du point de vue portabilité (cas vécu).
Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont portab les
d'un compilo à l'autre. Même le compilo Fortran 5.x de Microsoft les
comprenait, c'est dire !
>> > Au passage, LOGICAL*1 et LOGICAL(1), ce n'est pas la même chose. J e
>> > te laisse chercher un peu.
>> Exact
Tu as pourtant écrit juste un peu plus haut LOGICAL(n) alors que je
te parle de LOGICAL*n, ce qui est _différent_.
>> > Il y a longtemps que tu n'as pas vu un code Fortran, toi !
>> J'en fais juste tous les jours, ou presque.
Un type qui est infoutu de faire la différence entre LO GICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.
>> Et je maintiens : en comparaison du C, la norme Fortran se soucie tr ès peu
>> de la façon dont sont représentées les données en mémoire, e t ça s'est
>> accentué depuis le Fortran 90 (tableaux qui ne sont plus forcément contigus
>> en mémoire, etc...).
Gnîii ? Là, tu mélanges allègrement deux notions, mais venant de
toi, je m'attends vraiment à tout !...
>> La seule contrainte de ce genre en Fortran est qu'un
>> REAL ou un LOGICAL doivent occuper exactement la place d'un INTEGER (s ans
>> que ce soit forcément un mot machine) et qu'un COMPLEX ou un DOUBLE
>> PRECISION doivent occuper la place de deux REAL. Tout le reste est à la
>> libre appréciation du compilo.
Faux. J'ai la flemme de chercher dans la doc, mais j'ai a u moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit.
J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est deux
fois plus long qu'un REAL. Enfin, c'est à toi de voir.
>> D'ailleurs je note que les extensions Y*n n'ont jamais été normali sées alors
>> qu'elles étaient très courantes. A la place ce sont les Y(KIND=m ) qui l'ont
>> été, qui sont très différents des Y*n comme tu l'as rappelé, et qui
>> notamment ne disent *rien* sur la place occupée en mémoire.
Ça, c'est parce que tu codes comme un pied. Il y a un m écanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de ta
plage. Je te laisse là encore chercher.
Même sans ça. Tu peux très bien faire des hypothè ses sur le
placement en mémoire de tes objets pour optimiser certains codes.
>> > Les déclarations X*Y proviennent des extensions VAX et le Y est le
>> > nombre d'octets de la variable. J'aimerais que tu nous donnes ici un
>> > seul compilo fortran qui pour logical*1 positionne autre chose d'un
>> > drapeau sur un octet
>> Fais ton choix :
>>http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html
>> Voilà : ça n'a *jamais* été normalisé. Et de fait écrire u n code en
>> supposant par exemple que REAL*8 va occuper la même place qu'un DOUB LE
>> PRECISION est casse-gueule du point de vue portabilité (cas vécu).
Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont portab les
d'un compilo à l'autre. Même le compilo Fortran 5.x de Microsoft les
comprenait, c'est dire !
>> > Au passage, LOGICAL*1 et LOGICAL(1), ce n'est pas la même chose. J e
>> > te laisse chercher un peu.
>> Exact
Tu as pourtant écrit juste un peu plus haut LOGICAL(n) alors que je
te parle de LOGICAL*n, ce qui est _différent_.
>> > Il y a longtemps que tu n'as pas vu un code Fortran, toi !
>> J'en fais juste tous les jours, ou presque.
Un type qui est infoutu de faire la différence entre LO GICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.
>> Et je maintiens : en comparaison du C, la norme Fortran se soucie tr ès peu
>> de la façon dont sont représentées les données en mémoire, e t ça s'est
>> accentué depuis le Fortran 90 (tableaux qui ne sont plus forcément contigus
>> en mémoire, etc...).
Gnîii ? Là, tu mélanges allègrement deux notions, mais venant de
toi, je m'attends vraiment à tout !...
>> La seule contrainte de ce genre en Fortran est qu'un
>> REAL ou un LOGICAL doivent occuper exactement la place d'un INTEGER (s ans
>> que ce soit forcément un mot machine) et qu'un COMPLEX ou un DOUBLE
>> PRECISION doivent occuper la place de deux REAL. Tout le reste est à la
>> libre appréciation du compilo.
Faux. J'ai la flemme de chercher dans la doc, mais j'ai a u moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit.
J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est deux
fois plus long qu'un REAL. Enfin, c'est à toi de voir.
>> D'ailleurs je note que les extensions Y*n n'ont jamais été normali sées alors
>> qu'elles étaient très courantes. A la place ce sont les Y(KIND=m ) qui l'ont
>> été, qui sont très différents des Y*n comme tu l'as rappelé, et qui
>> notamment ne disent *rien* sur la place occupée en mémoire.
Ça, c'est parce que tu codes comme un pied. Il y a un m écanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de ta
plage. Je te laisse là encore chercher.
> Quand on veut faire du dev bas niveau avec des accès hard, on ne le
> fait pas en Fortran, tout simplement. Il y a des langages plus
> adaptés, plutôt que de faire des contorsions qui n'est pas fait pou r à
> la base.
On s'en contrefiche. Le fait d'avoir des types de longueu rs
différentes, même si ça te semble inutile, est quelque chose
d'intéressant
(et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran).
> Quand on veut faire du dev bas niveau avec des accès hard, on ne le
> fait pas en Fortran, tout simplement. Il y a des langages plus
> adaptés, plutôt que de faire des contorsions qui n'est pas fait pou r à
> la base.
On s'en contrefiche. Le fait d'avoir des types de longueu rs
différentes, même si ça te semble inutile, est quelque chose
d'intéressant
(et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran).
> Quand on veut faire du dev bas niveau avec des accès hard, on ne le
> fait pas en Fortran, tout simplement. Il y a des langages plus
> adaptés, plutôt que de faire des contorsions qui n'est pas fait pou r à
> la base.
On s'en contrefiche. Le fait d'avoir des types de longueu rs
différentes, même si ça te semble inutile, est quelque chose
d'intéressant
(et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran).
On 17 juil, 17:12, JKB wrote:
Même sans ça. Tu peux très bien faire des hypothèses sur le
placement en mémoire de tes objets pour optimiser certains codes.
Et en général faire un code non portable.
>> > Les déclarations X*Y proviennent des extensions VAX et le Y est le
>> > nombre d'octets de la variable. J'aimerais que tu nous donnes ici un
>> > seul compilo fortran qui pour logical*1 positionne autre chose d'un
>> > drapeau sur un octet
>> Fais ton choix :
>>http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html
Pas de commentaire là-dessus ?
>> Voilà : ça n'a *jamais* été normalisé. Et de fait écrire un code en
>> supposant par exemple que REAL*8 va occuper la même place qu'un DOUBLE
>> PRECISION est casse-gueule du point de vue portabilité (cas vécu).
Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont portables
d'un compilo à l'autre. Même le compilo Fortran 5.x de Microsoft les
comprenait, c'est dire !
Un draft ça veut dire ce que ça veut dire : as-tu un document final
adopté ?
Et même en admettant que ça ait pu être normalisé en tant qu'extension
de F77, ça n'a pas été reconduit en F90 et au-delà. Et F77 étant une
norme obsolète, les extensions Y*n sont de fait obsolètes aussi.
>> > Au passage, LOGICAL*1 et LOGICAL(1), ce n'est pas la même chose. Je
>> > te laisse chercher un peu.
>> Exact
Tu as pourtant écrit juste un peu plus haut LOGICAL(n) alors que je
te parle de LOGICAL*n, ce qui est _différent_.
Oui. J'ai fait un abus de notation.
>> > Il y a longtemps que tu n'as pas vu un code Fortran, toi !
>> J'en fais juste tous les jours, ou presque.
Un type qui est infoutu de faire la différence entre LOGICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.
J'ai juste écrit trop vite.
Mais celui qui affirme qu'un LOGICAL*1 occupe *toujours* 1 octet, il
devrait faire quoi ?
>> Et je maintiens : en comparaison du C, la norme Fortran se soucie très peu
>> de la façon dont sont représentées les données en mémoire, et ça s'est
>> accentué depuis le Fortran 90 (tableaux qui ne sont plus forcément contigus
>> en mémoire, etc...).
Gnîii ? Là, tu mélanges allègrement deux notions, mais venant de
toi, je m'attends vraiment à tout !...
Explique-moi plutôt quelles notions je mélange selon toi.
>> La seule contrainte de ce genre en Fortran est qu'un
>> REAL ou un LOGICAL doivent occuper exactement la place d'un INTEGER (sans
>> que ce soit forcément un mot machine) et qu'un COMPLEX ou un DOUBLE
>> PRECISION doivent occuper la place de deux REAL. Tout le reste est à la
>> libre appréciation du compilo.
Faux. J'ai la flemme de chercher dans la doc, mais j'ai au moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit.
Ben voyons :
http://www.fortran.com/F77_std/rjcnf0001-sh-4.html#sh-4
4.3 Integer Type
... An integer datum has one numeric storage unit in a storage
sequence.
4.4 Real Type
... A real datum has one numeric storage unit in a storage sequence.
4.5 Double Precision Type
... A double precision datum has two consecutive numeric storage units
in a storage sequence.
4.6 Complex Type
... A complex datum has two consecutive numeric storage units in a
storage sequence;
4.7 Logical Type
A logical datum has one numeric storage unit in a storage sequence.J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Un conseil : jette-les. Ou bien arrête de picoler.
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est deux
fois plus long qu'un REAL. Enfin, c'est à toi de voir.
Voir ci-dessus. Ces histoires de place occupée par les différents
types, c'est quand même des notions de base en Fortran. Je suis plus
qu'étonné que tu ne les connaisses pas.
>> D'ailleurs je note que les extensions Y*n n'ont jamais été normalisées alors
>> qu'elles étaient très courantes. A la place ce sont les Y(KIND=m) qui l'ont
>> été, qui sont très différents des Y*n comme tu l'as rappelé, et qui
>> notamment ne disent *rien* sur la place occupée en mémoire.
Ça, c'est parce que tu codes comme un pied. Il y a un mécanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de ta
plage. Je te laisse là encore chercher.
Tu t'enfonces allègrement dans ta méconnaissance du Fortran.
Le mécanisme en question ne fait aucune référence à la place
disponible pour le type, mais à la précision et à l'étendue numérique
désirées.
SELECTED_INT_KIND(RANGE=r) retourne un KIND qui permet de représenter
des entiers au moins entre -10^r et 10^r
SELECTED_REAL_KIND(PRECISION=p,RANGE=r) retourne un KIND qui permet de
représenter des flottants au moins entre -10^r et 10^r, avec une
mantisse d'au moins p chiffres décimaux significatifs.
*Aucune* notion de place mémoire là-dedans. Tu racontes vraiment
n'importe quoi.
On 17 juil, 17:12, JKB <knatsc...@koenigsberg.fr> wrote:
Même sans ça. Tu peux très bien faire des hypothèses sur le
placement en mémoire de tes objets pour optimiser certains codes.
Et en général faire un code non portable.
>> > Les déclarations X*Y proviennent des extensions VAX et le Y est le
>> > nombre d'octets de la variable. J'aimerais que tu nous donnes ici un
>> > seul compilo fortran qui pour logical*1 positionne autre chose d'un
>> > drapeau sur un octet
>> Fais ton choix :
>>http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html
Pas de commentaire là-dessus ?
>> Voilà : ça n'a *jamais* été normalisé. Et de fait écrire un code en
>> supposant par exemple que REAL*8 va occuper la même place qu'un DOUBLE
>> PRECISION est casse-gueule du point de vue portabilité (cas vécu).
Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont portables
d'un compilo à l'autre. Même le compilo Fortran 5.x de Microsoft les
comprenait, c'est dire !
Un draft ça veut dire ce que ça veut dire : as-tu un document final
adopté ?
Et même en admettant que ça ait pu être normalisé en tant qu'extension
de F77, ça n'a pas été reconduit en F90 et au-delà. Et F77 étant une
norme obsolète, les extensions Y*n sont de fait obsolètes aussi.
>> > Au passage, LOGICAL*1 et LOGICAL(1), ce n'est pas la même chose. Je
>> > te laisse chercher un peu.
>> Exact
Tu as pourtant écrit juste un peu plus haut LOGICAL(n) alors que je
te parle de LOGICAL*n, ce qui est _différent_.
Oui. J'ai fait un abus de notation.
>> > Il y a longtemps que tu n'as pas vu un code Fortran, toi !
>> J'en fais juste tous les jours, ou presque.
Un type qui est infoutu de faire la différence entre LOGICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.
J'ai juste écrit trop vite.
Mais celui qui affirme qu'un LOGICAL*1 occupe *toujours* 1 octet, il
devrait faire quoi ?
>> Et je maintiens : en comparaison du C, la norme Fortran se soucie très peu
>> de la façon dont sont représentées les données en mémoire, et ça s'est
>> accentué depuis le Fortran 90 (tableaux qui ne sont plus forcément contigus
>> en mémoire, etc...).
Gnîii ? Là, tu mélanges allègrement deux notions, mais venant de
toi, je m'attends vraiment à tout !...
Explique-moi plutôt quelles notions je mélange selon toi.
>> La seule contrainte de ce genre en Fortran est qu'un
>> REAL ou un LOGICAL doivent occuper exactement la place d'un INTEGER (sans
>> que ce soit forcément un mot machine) et qu'un COMPLEX ou un DOUBLE
>> PRECISION doivent occuper la place de deux REAL. Tout le reste est à la
>> libre appréciation du compilo.
Faux. J'ai la flemme de chercher dans la doc, mais j'ai au moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit.
Ben voyons :
http://www.fortran.com/F77_std/rjcnf0001-sh-4.html#sh-4
4.3 Integer Type
... An integer datum has one numeric storage unit in a storage
sequence.
4.4 Real Type
... A real datum has one numeric storage unit in a storage sequence.
4.5 Double Precision Type
... A double precision datum has two consecutive numeric storage units
in a storage sequence.
4.6 Complex Type
... A complex datum has two consecutive numeric storage units in a
storage sequence;
4.7 Logical Type
A logical datum has one numeric storage unit in a storage sequence.
J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Un conseil : jette-les. Ou bien arrête de picoler.
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est deux
fois plus long qu'un REAL. Enfin, c'est à toi de voir.
Voir ci-dessus. Ces histoires de place occupée par les différents
types, c'est quand même des notions de base en Fortran. Je suis plus
qu'étonné que tu ne les connaisses pas.
>> D'ailleurs je note que les extensions Y*n n'ont jamais été normalisées alors
>> qu'elles étaient très courantes. A la place ce sont les Y(KIND=m) qui l'ont
>> été, qui sont très différents des Y*n comme tu l'as rappelé, et qui
>> notamment ne disent *rien* sur la place occupée en mémoire.
Ça, c'est parce que tu codes comme un pied. Il y a un mécanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de ta
plage. Je te laisse là encore chercher.
Tu t'enfonces allègrement dans ta méconnaissance du Fortran.
Le mécanisme en question ne fait aucune référence à la place
disponible pour le type, mais à la précision et à l'étendue numérique
désirées.
SELECTED_INT_KIND(RANGE=r) retourne un KIND qui permet de représenter
des entiers au moins entre -10^r et 10^r
SELECTED_REAL_KIND(PRECISION=p,RANGE=r) retourne un KIND qui permet de
représenter des flottants au moins entre -10^r et 10^r, avec une
mantisse d'au moins p chiffres décimaux significatifs.
*Aucune* notion de place mémoire là-dedans. Tu racontes vraiment
n'importe quoi.
On 17 juil, 17:12, JKB wrote:
Même sans ça. Tu peux très bien faire des hypothèses sur le
placement en mémoire de tes objets pour optimiser certains codes.
Et en général faire un code non portable.
>> > Les déclarations X*Y proviennent des extensions VAX et le Y est le
>> > nombre d'octets de la variable. J'aimerais que tu nous donnes ici un
>> > seul compilo fortran qui pour logical*1 positionne autre chose d'un
>> > drapeau sur un octet
>> Fais ton choix :
>>http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html
Pas de commentaire là-dessus ?
>> Voilà : ça n'a *jamais* été normalisé. Et de fait écrire un code en
>> supposant par exemple que REAL*8 va occuper la même place qu'un DOUBLE
>> PRECISION est casse-gueule du point de vue portabilité (cas vécu).
Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont portables
d'un compilo à l'autre. Même le compilo Fortran 5.x de Microsoft les
comprenait, c'est dire !
Un draft ça veut dire ce que ça veut dire : as-tu un document final
adopté ?
Et même en admettant que ça ait pu être normalisé en tant qu'extension
de F77, ça n'a pas été reconduit en F90 et au-delà. Et F77 étant une
norme obsolète, les extensions Y*n sont de fait obsolètes aussi.
>> > Au passage, LOGICAL*1 et LOGICAL(1), ce n'est pas la même chose. Je
>> > te laisse chercher un peu.
>> Exact
Tu as pourtant écrit juste un peu plus haut LOGICAL(n) alors que je
te parle de LOGICAL*n, ce qui est _différent_.
Oui. J'ai fait un abus de notation.
>> > Il y a longtemps que tu n'as pas vu un code Fortran, toi !
>> J'en fais juste tous les jours, ou presque.
Un type qui est infoutu de faire la différence entre LOGICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.
J'ai juste écrit trop vite.
Mais celui qui affirme qu'un LOGICAL*1 occupe *toujours* 1 octet, il
devrait faire quoi ?
>> Et je maintiens : en comparaison du C, la norme Fortran se soucie très peu
>> de la façon dont sont représentées les données en mémoire, et ça s'est
>> accentué depuis le Fortran 90 (tableaux qui ne sont plus forcément contigus
>> en mémoire, etc...).
Gnîii ? Là, tu mélanges allègrement deux notions, mais venant de
toi, je m'attends vraiment à tout !...
Explique-moi plutôt quelles notions je mélange selon toi.
>> La seule contrainte de ce genre en Fortran est qu'un
>> REAL ou un LOGICAL doivent occuper exactement la place d'un INTEGER (sans
>> que ce soit forcément un mot machine) et qu'un COMPLEX ou un DOUBLE
>> PRECISION doivent occuper la place de deux REAL. Tout le reste est à la
>> libre appréciation du compilo.
Faux. J'ai la flemme de chercher dans la doc, mais j'ai au moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit.
Ben voyons :
http://www.fortran.com/F77_std/rjcnf0001-sh-4.html#sh-4
4.3 Integer Type
... An integer datum has one numeric storage unit in a storage
sequence.
4.4 Real Type
... A real datum has one numeric storage unit in a storage sequence.
4.5 Double Precision Type
... A double precision datum has two consecutive numeric storage units
in a storage sequence.
4.6 Complex Type
... A complex datum has two consecutive numeric storage units in a
storage sequence;
4.7 Logical Type
A logical datum has one numeric storage unit in a storage sequence.J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Un conseil : jette-les. Ou bien arrête de picoler.
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est deux
fois plus long qu'un REAL. Enfin, c'est à toi de voir.
Voir ci-dessus. Ces histoires de place occupée par les différents
types, c'est quand même des notions de base en Fortran. Je suis plus
qu'étonné que tu ne les connaisses pas.
>> D'ailleurs je note que les extensions Y*n n'ont jamais été normalisées alors
>> qu'elles étaient très courantes. A la place ce sont les Y(KIND=m) qui l'ont
>> été, qui sont très différents des Y*n comme tu l'as rappelé, et qui
>> notamment ne disent *rien* sur la place occupée en mémoire.
Ça, c'est parce que tu codes comme un pied. Il y a un mécanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de ta
plage. Je te laisse là encore chercher.
Tu t'enfonces allègrement dans ta méconnaissance du Fortran.
Le mécanisme en question ne fait aucune référence à la place
disponible pour le type, mais à la précision et à l'étendue numérique
désirées.
SELECTED_INT_KIND(RANGE=r) retourne un KIND qui permet de représenter
des entiers au moins entre -10^r et 10^r
SELECTED_REAL_KIND(PRECISION=p,RANGE=r) retourne un KIND qui permet de
représenter des flottants au moins entre -10^r et 10^r, avec une
mantisse d'au moins p chiffres décimaux significatifs.
*Aucune* notion de place mémoire là-dedans. Tu racontes vraiment
n'importe quoi.
On 17 juil, 17:27, JKB wrote:
> Quand on veut faire du dev bas niveau avec des accès hard, on ne le
> fait pas en Fortran, tout simplement. Il y a des langages plus
> adaptés, plutôt que de faire des contorsions qui n'est pas fait pour à
> la base.
On s'en contrefiche. Le fait d'avoir des types de longueurs
différentes, même si ça te semble inutile, est quelque chose
d'intéressant
Ce n'est pas que ça me semble inutile par essence, c'est que ça ne
cadre pas avec ce qu'est le Fortran, et que ça ne peut que conduire à
faire du code avec des problèmes potentiels de portabilité.
Et pour en revenir aux questions d'alignements, en Fortran c'est au
compilateur de gérer ça, je ne vois pas l'intérêt de chercher à
aligner soi-même les données.
(et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran).
En F2003 l'interfaçage C/Fortran est normalisé.
On 17 juil, 17:27, JKB <knatsc...@koenigsberg.fr> wrote:
> Quand on veut faire du dev bas niveau avec des accès hard, on ne le
> fait pas en Fortran, tout simplement. Il y a des langages plus
> adaptés, plutôt que de faire des contorsions qui n'est pas fait pour à
> la base.
On s'en contrefiche. Le fait d'avoir des types de longueurs
différentes, même si ça te semble inutile, est quelque chose
d'intéressant
Ce n'est pas que ça me semble inutile par essence, c'est que ça ne
cadre pas avec ce qu'est le Fortran, et que ça ne peut que conduire à
faire du code avec des problèmes potentiels de portabilité.
Et pour en revenir aux questions d'alignements, en Fortran c'est au
compilateur de gérer ça, je ne vois pas l'intérêt de chercher à
aligner soi-même les données.
(et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran).
En F2003 l'interfaçage C/Fortran est normalisé.
On 17 juil, 17:27, JKB wrote:
> Quand on veut faire du dev bas niveau avec des accès hard, on ne le
> fait pas en Fortran, tout simplement. Il y a des langages plus
> adaptés, plutôt que de faire des contorsions qui n'est pas fait pour à
> la base.
On s'en contrefiche. Le fait d'avoir des types de longueurs
différentes, même si ça te semble inutile, est quelque chose
d'intéressant
Ce n'est pas que ça me semble inutile par essence, c'est que ça ne
cadre pas avec ce qu'est le Fortran, et que ça ne peut que conduire à
faire du code avec des problèmes potentiels de portabilité.
Et pour en revenir aux questions d'alignements, en Fortran c'est au
compilateur de gérer ça, je ne vois pas l'intérêt de chercher à
aligner soi-même les données.
(et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran).
En F2003 l'interfaçage C/Fortran est normalisé.
J'ai prétendu une seule chose : que Gimp ne pouvait pas rendre les
mêmes services que Photoshop. C'est une réalité
et il n'y a pas besoin
de les utiliser *régulièrement* pour le constater.
J'ai prétendu une seule chose : que Gimp ne pouvait pas rendre les
mêmes services que Photoshop. C'est une réalité
et il n'y a pas besoin
de les utiliser *régulièrement* pour le constater.
J'ai prétendu une seule chose : que Gimp ne pouvait pas rendre les
mêmes services que Photoshop. C'est une réalité
et il n'y a pas besoin
de les utiliser *régulièrement* pour le constater.
Ce n'est pas que ça me semble inutile par essence, c'est que ça ne
cadre pas avec ce qu'est le Fortran, et que ça ne peut que conduire à
faire du code avec des problèmes potentiels de portabilité.
Et pour en revenir aux questions d'alignements, en Fortran c'est au
compilateur de gérer ça, je ne vois pas l'intérêt de chercher à
aligner soi-même les données.
C'est pour cela qu'il y a un truc extrèmement casse-gueule qui
s'appelle EQUIVALENCE. Arrête, tu t'enfonces !
(et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran).
En F2003 l'interfaçage C/Fortran est normalisé.
Pour les types simples. Comment fais-tu avec des structures (ou des
types derivés si on cause Fortran) ? L'alignement des types dérivés du
Fortran n'a aucune raison d'être celui des structures du C.
Ce n'est pas que ça me semble inutile par essence, c'est que ça ne
cadre pas avec ce qu'est le Fortran, et que ça ne peut que conduire à
faire du code avec des problèmes potentiels de portabilité.
Et pour en revenir aux questions d'alignements, en Fortran c'est au
compilateur de gérer ça, je ne vois pas l'intérêt de chercher à
aligner soi-même les données.
C'est pour cela qu'il y a un truc extrèmement casse-gueule qui
s'appelle EQUIVALENCE. Arrête, tu t'enfonces !
(et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran).
En F2003 l'interfaçage C/Fortran est normalisé.
Pour les types simples. Comment fais-tu avec des structures (ou des
types derivés si on cause Fortran) ? L'alignement des types dérivés du
Fortran n'a aucune raison d'être celui des structures du C.
Ce n'est pas que ça me semble inutile par essence, c'est que ça ne
cadre pas avec ce qu'est le Fortran, et que ça ne peut que conduire à
faire du code avec des problèmes potentiels de portabilité.
Et pour en revenir aux questions d'alignements, en Fortran c'est au
compilateur de gérer ça, je ne vois pas l'intérêt de chercher à
aligner soi-même les données.
C'est pour cela qu'il y a un truc extrèmement casse-gueule qui
s'appelle EQUIVALENCE. Arrête, tu t'enfonces !
(et parfois d'indispensable comme lorsque tu dois
interfacer des bouts de C avec du Fortran).
En F2003 l'interfaçage C/Fortran est normalisé.
Pour les types simples. Comment fais-tu avec des structures (ou des
types derivés si on cause Fortran) ? L'alignement des types dérivés du
Fortran n'a aucune raison d'être celui des structures du C.
En meme temps, Titanic est un des pires navets de la production
americaine.
C'est vrai : on ne voit même pas Hulk dans le film...
En meme temps, Titanic est un des pires navets de la production
americaine.
C'est vrai : on ne voit même pas Hulk dans le film...
En meme temps, Titanic est un des pires navets de la production
americaine.
C'est vrai : on ne voit même pas Hulk dans le film...
Le 17-07-2009, ? propos de
Re: 32 vs. 64 bits [était Re: Windows sur le mainframe],
pehache-tolai ?crivait dans fr.comp.os.linux.debats :On 17 juil, 17:12, JKB wrote:
Même sans ça. Tu peux très bien faire des hypothèses sur le
placement en mémoire de tes objets pour optimiser certains codes.
Et en général faire un code non portable.
Par forcément. J'ai des tas de situations comme celle-là avec du
code _parfaitement_ portable (et qui est un mélange entre du C, du F77
et du F9x).
Ce n'est pas parce que tu ne sais pas faire que ça n'est
pas possible.
Fais ton choix :http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html
Pas de commentaire là-dessus ?
Et que veux tu que je te dise ? Que sur ce compilo un real*8 vaut un
real(kind=8) ? Dans le cas général, c'est faux. C'est juste vrai sur
cette implantation.
Voilà : ça n'a *jamais* été normalisé. Et de fait écrire un code
en supposant par exemple que REAL*8 va occuper la même place
qu'un DOUBLE PRECISION est casse-gueule du point de vue
portabilité (cas vécu).
Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont
portables d'un compilo à l'autre. Même le compilo Fortran 5.x de
Microsoft les comprenait, c'est dire !
Un draft ça veut dire ce que ça veut dire : as-tu un document final
adopté ?
J'ai dit un draft. Ce qui veut dire qu'assez de monde a bosser sur
ce point pour qu'il soit adopté,
mais pas normalisé effectivement
(sinon on parlerait de _norme_ et non d'_extension_)
Et même en admettant que ça ait pu être normalisé en tant
qu'extension de F77, ça n'a pas été reconduit en F90 et au-delà. Et
F77 étant une norme obsolète, les extensions Y*n sont de fait
obsolètes aussi.
Les extensions Y*X sont encore marquées comme extensions _valides_
et non _obsolètes_ dans la référence Fortran2003 que j'ai sous les
yeux.
Il y a longtemps que tu n'as pas vu un code Fortran, toi !J'en fais juste tous les jours, ou presque.
Un type qui est infoutu de faire la différence entre LOGICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.
J'ai juste écrit trop vite.
Mais celui qui affirme qu'un LOGICAL*1 occupe *toujours* 1 octet, il
devrait faire quoi ?
Exprime-toi clairement.
Explique-moi plutôt quelles notions je mélange selon toi.
Non, à toi l'honneur. Tu prétends qu'un tableau n'est pas forcément
contigu.
Je t'attends,
parce qu'il y a une subtilité qui semble
d'échapper.
Faux. J'ai la flemme de chercher dans la doc, mais j'ai au moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit.
Ben voyons :
http://www.fortran.com/F77_std/rjcnf0001-sh-4.html#sh-4
4.3 Integer Type
... An integer datum has one numeric storage unit in a storage
sequence.
4.4 Real Type
... A real datum has one numeric storage unit in a storage sequence.
4.5 Double Precision Type
... A double precision datum has two consecutive numeric storage
units in a storage sequence.
4.6 Complex Type
... A complex datum has two consecutive numeric storage units in a
storage sequence;
4.7 Logical Type
A logical datum has one numeric storage unit in a storage sequence.J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Un conseil : jette-les. Ou bien arrête de picoler.
Non, c'est toi qui mélange 'numeric storage' entier et flottant.
Ce n'est pas parce que dans l'immense majorité des cas, on peut
assimiler les deux que c'est _toujours_ le cas.
Je te répète que j'ai
des compilos _certifiés_ F77 puisque c'est de ça qu'on parle qui ne se
comportent pas de la même façon (pour diverses raisons que je
n'expliciterai pas ici) :
integer -> 16 bits
real -> 32 bits
double precision -> 64 bits
logical -> 16 bits
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est
deux fois plus long qu'un REAL. Enfin, c'est à toi de voir.
Voir ci-dessus. Ces histoires de place occupée par les différents
types, c'est quand même des notions de base en Fortran. Je suis plus
qu'étonné que tu ne les connaisses pas.
Je les connais parfaitement.
Il existe des architectures tordues et
non orientées octet dans lesquelles ton double precision n'est pas
deux fois plus long que le real.
D'ailleurs je note que les extensions Y*n n'ont jamais été
normalisées alors qu'elles étaient très courantes. A la place ce
sont les Y(KIND=m) qui l'ont été, qui sont très différents des
Y*n comme tu l'as rappelé, et qui notamment ne disent *rien* sur
la place occupée en mémoire.
Ça, c'est parce que tu codes comme un pied. Il y a un mécanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de
ta plage. Je te laisse là encore chercher.
Tu t'enfonces allègrement dans ta méconnaissance du Fortran.
Le mécanisme en question ne fait aucune référence à la place
disponible pour le type, mais à la précision et à l'étendue numérique
désirées.
SELECTED_INT_KIND(RANGE=r) retourne un KIND qui permet de représenter
des entiers au moins entre -10^r et 10^r
SELECTED_REAL_KIND(PRECISION=p,RANGE=r) retourne un KIND qui permet
de représenter des flottants au moins entre -10^r et 10^r, avec une
mantisse d'au moins p chiffres décimaux significatifs.
C'est exactement ce que je te disais
Le 17-07-2009, ? propos de
Re: 32 vs. 64 bits [était Re: Windows sur le mainframe],
pehache-tolai ?crivait dans fr.comp.os.linux.debats :
On 17 juil, 17:12, JKB <knatsc...@koenigsberg.fr> wrote:
Même sans ça. Tu peux très bien faire des hypothèses sur le
placement en mémoire de tes objets pour optimiser certains codes.
Et en général faire un code non portable.
Par forcément. J'ai des tas de situations comme celle-là avec du
code _parfaitement_ portable (et qui est un mélange entre du C, du F77
et du F9x).
Ce n'est pas parce que tu ne sais pas faire que ça n'est
pas possible.
Fais ton choix :
http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html
Pas de commentaire là-dessus ?
Et que veux tu que je te dise ? Que sur ce compilo un real*8 vaut un
real(kind=8) ? Dans le cas général, c'est faux. C'est juste vrai sur
cette implantation.
Voilà : ça n'a *jamais* été normalisé. Et de fait écrire un code
en supposant par exemple que REAL*8 va occuper la même place
qu'un DOUBLE PRECISION est casse-gueule du point de vue
portabilité (cas vécu).
Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont
portables d'un compilo à l'autre. Même le compilo Fortran 5.x de
Microsoft les comprenait, c'est dire !
Un draft ça veut dire ce que ça veut dire : as-tu un document final
adopté ?
J'ai dit un draft. Ce qui veut dire qu'assez de monde a bosser sur
ce point pour qu'il soit adopté,
mais pas normalisé effectivement
(sinon on parlerait de _norme_ et non d'_extension_)
Et même en admettant que ça ait pu être normalisé en tant
qu'extension de F77, ça n'a pas été reconduit en F90 et au-delà. Et
F77 étant une norme obsolète, les extensions Y*n sont de fait
obsolètes aussi.
Les extensions Y*X sont encore marquées comme extensions _valides_
et non _obsolètes_ dans la référence Fortran2003 que j'ai sous les
yeux.
Il y a longtemps que tu n'as pas vu un code Fortran, toi !
J'en fais juste tous les jours, ou presque.
Un type qui est infoutu de faire la différence entre LOGICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.
J'ai juste écrit trop vite.
Mais celui qui affirme qu'un LOGICAL*1 occupe *toujours* 1 octet, il
devrait faire quoi ?
Exprime-toi clairement.
Explique-moi plutôt quelles notions je mélange selon toi.
Non, à toi l'honneur. Tu prétends qu'un tableau n'est pas forcément
contigu.
Je t'attends,
parce qu'il y a une subtilité qui semble
d'échapper.
Faux. J'ai la flemme de chercher dans la doc, mais j'ai au moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit.
Ben voyons :
http://www.fortran.com/F77_std/rjcnf0001-sh-4.html#sh-4
4.3 Integer Type
... An integer datum has one numeric storage unit in a storage
sequence.
4.4 Real Type
... A real datum has one numeric storage unit in a storage sequence.
4.5 Double Precision Type
... A double precision datum has two consecutive numeric storage
units in a storage sequence.
4.6 Complex Type
... A complex datum has two consecutive numeric storage units in a
storage sequence;
4.7 Logical Type
A logical datum has one numeric storage unit in a storage sequence.
J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Un conseil : jette-les. Ou bien arrête de picoler.
Non, c'est toi qui mélange 'numeric storage' entier et flottant.
Ce n'est pas parce que dans l'immense majorité des cas, on peut
assimiler les deux que c'est _toujours_ le cas.
Je te répète que j'ai
des compilos _certifiés_ F77 puisque c'est de ça qu'on parle qui ne se
comportent pas de la même façon (pour diverses raisons que je
n'expliciterai pas ici) :
integer -> 16 bits
real -> 32 bits
double precision -> 64 bits
logical -> 16 bits
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est
deux fois plus long qu'un REAL. Enfin, c'est à toi de voir.
Voir ci-dessus. Ces histoires de place occupée par les différents
types, c'est quand même des notions de base en Fortran. Je suis plus
qu'étonné que tu ne les connaisses pas.
Je les connais parfaitement.
Il existe des architectures tordues et
non orientées octet dans lesquelles ton double precision n'est pas
deux fois plus long que le real.
D'ailleurs je note que les extensions Y*n n'ont jamais été
normalisées alors qu'elles étaient très courantes. A la place ce
sont les Y(KIND=m) qui l'ont été, qui sont très différents des
Y*n comme tu l'as rappelé, et qui notamment ne disent *rien* sur
la place occupée en mémoire.
Ça, c'est parce que tu codes comme un pied. Il y a un mécanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de
ta plage. Je te laisse là encore chercher.
Tu t'enfonces allègrement dans ta méconnaissance du Fortran.
Le mécanisme en question ne fait aucune référence à la place
disponible pour le type, mais à la précision et à l'étendue numérique
désirées.
SELECTED_INT_KIND(RANGE=r) retourne un KIND qui permet de représenter
des entiers au moins entre -10^r et 10^r
SELECTED_REAL_KIND(PRECISION=p,RANGE=r) retourne un KIND qui permet
de représenter des flottants au moins entre -10^r et 10^r, avec une
mantisse d'au moins p chiffres décimaux significatifs.
C'est exactement ce que je te disais
Le 17-07-2009, ? propos de
Re: 32 vs. 64 bits [était Re: Windows sur le mainframe],
pehache-tolai ?crivait dans fr.comp.os.linux.debats :On 17 juil, 17:12, JKB wrote:
Même sans ça. Tu peux très bien faire des hypothèses sur le
placement en mémoire de tes objets pour optimiser certains codes.
Et en général faire un code non portable.
Par forcément. J'ai des tas de situations comme celle-là avec du
code _parfaitement_ portable (et qui est un mélange entre du C, du F77
et du F9x).
Ce n'est pas parce que tu ne sais pas faire que ça n'est
pas possible.
Fais ton choix :http://www.idris.fr/su/Vectoriel/brodie/options_fortran.html
Pas de commentaire là-dessus ?
Et que veux tu que je te dise ? Que sur ce compilo un real*8 vaut un
real(kind=8) ? Dans le cas général, c'est faux. C'est juste vrai sur
cette implantation.
Voilà : ça n'a *jamais* été normalisé. Et de fait écrire un code
en supposant par exemple que REAL*8 va occuper la même place
qu'un DOUBLE PRECISION est casse-gueule du point de vue
portabilité (cas vécu).
Si, en extension du Fortran-77, justement. J'ai un draft IEEE
là-dessus. C'est même pour cela que les extension VAX/VMS sont
portables d'un compilo à l'autre. Même le compilo Fortran 5.x de
Microsoft les comprenait, c'est dire !
Un draft ça veut dire ce que ça veut dire : as-tu un document final
adopté ?
J'ai dit un draft. Ce qui veut dire qu'assez de monde a bosser sur
ce point pour qu'il soit adopté,
mais pas normalisé effectivement
(sinon on parlerait de _norme_ et non d'_extension_)
Et même en admettant que ça ait pu être normalisé en tant
qu'extension de F77, ça n'a pas été reconduit en F90 et au-delà. Et
F77 étant une norme obsolète, les extensions Y*n sont de fait
obsolètes aussi.
Les extensions Y*X sont encore marquées comme extensions _valides_
et non _obsolètes_ dans la référence Fortran2003 que j'ai sous les
yeux.
Il y a longtemps que tu n'as pas vu un code Fortran, toi !J'en fais juste tous les jours, ou presque.
Un type qui est infoutu de faire la différence entre LOGICAL(kind=n)
et LOGICAL*n devrait commencer par changer de métier.
J'ai juste écrit trop vite.
Mais celui qui affirme qu'un LOGICAL*1 occupe *toujours* 1 octet, il
devrait faire quoi ?
Exprime-toi clairement.
Explique-moi plutôt quelles notions je mélange selon toi.
Non, à toi l'honneur. Tu prétends qu'un tableau n'est pas forcément
contigu.
Je t'attends,
parce qu'il y a une subtilité qui semble
d'échapper.
Faux. J'ai la flemme de chercher dans la doc, mais j'ai au moins un
contre-exemple. INTEGER et LOGICAL (de base) sont de même longueur.
Quant à REAL, rien n'est dit.
Ben voyons :
http://www.fortran.com/F77_std/rjcnf0001-sh-4.html#sh-4
4.3 Integer Type
... An integer datum has one numeric storage unit in a storage
sequence.
4.4 Real Type
... A real datum has one numeric storage unit in a storage sequence.
4.5 Double Precision Type
... A double precision datum has two consecutive numeric storage
units in a storage sequence.
4.6 Complex Type
... A complex datum has two consecutive numeric storage units in a
storage sequence;
4.7 Logical Type
A logical datum has one numeric storage unit in a storage sequence.J'ai plusieurs compilo pour lesquels la
longueur du REAL est supérieure à celle de l'INTEGER.
Un conseil : jette-les. Ou bien arrête de picoler.
Non, c'est toi qui mélange 'numeric storage' entier et flottant.
Ce n'est pas parce que dans l'immense majorité des cas, on peut
assimiler les deux que c'est _toujours_ le cas.
Je te répète que j'ai
des compilos _certifiés_ F77 puisque c'est de ça qu'on parle qui ne se
comportent pas de la même façon (pour diverses raisons que je
n'expliciterai pas ici) :
integer -> 16 bits
real -> 32 bits
double precision -> 64 bits
logical -> 16 bits
Tu t'avances aussi beaucoup en disant qu'un DOUBLE PRECISION est
deux fois plus long qu'un REAL. Enfin, c'est à toi de voir.
Voir ci-dessus. Ces histoires de place occupée par les différents
types, c'est quand même des notions de base en Fortran. Je suis plus
qu'étonné que tu ne les connaisses pas.
Je les connais parfaitement.
Il existe des architectures tordues et
non orientées octet dans lesquelles ton double precision n'est pas
deux fois plus long que le real.
D'ailleurs je note que les extensions Y*n n'ont jamais été
normalisées alors qu'elles étaient très courantes. A la place ce
sont les Y(KIND=m) qui l'ont été, qui sont très différents des
Y*n comme tu l'as rappelé, et qui notamment ne disent *rien* sur
la place occupée en mémoire.
Ça, c'est parce que tu codes comme un pied. Il y a un mécanisme qui
te permet de trouver le type à balancer dans le KIND en fonction de
ta plage. Je te laisse là encore chercher.
Tu t'enfonces allègrement dans ta méconnaissance du Fortran.
Le mécanisme en question ne fait aucune référence à la place
disponible pour le type, mais à la précision et à l'étendue numérique
désirées.
SELECTED_INT_KIND(RANGE=r) retourne un KIND qui permet de représenter
des entiers au moins entre -10^r et 10^r
SELECTED_REAL_KIND(PRECISION=p,RANGE=r) retourne un KIND qui permet
de représenter des flottants au moins entre -10^r et 10^r, avec une
mantisse d'au moins p chiffres décimaux significatifs.
C'est exactement ce que je te disais
pehache-tolai wrote:
J'ai prétendu une seule chose : que Gimp ne pouvait pas rendre les
mêmes services que Photoshop. C'est une réalité
En dehors de certains aspects très particuliers,
c'est une réalité qui
n'est constatée que par ceux qui ne maîtrisent pas Gimp.
En d'autres termes, ce n'est pas parce qu'une personne ne sait pas
faire quelque chose avec Gimp que Gimp n'est pas capable de le faire.et il n'y a pas besoin
de les utiliser *régulièrement* pour le constater.
Ben si, justement, c'est en maîtrisant les outils que tu peux parler
de leurs limitations.
pehache-tolai wrote:
J'ai prétendu une seule chose : que Gimp ne pouvait pas rendre les
mêmes services que Photoshop. C'est une réalité
En dehors de certains aspects très particuliers,
c'est une réalité qui
n'est constatée que par ceux qui ne maîtrisent pas Gimp.
En d'autres termes, ce n'est pas parce qu'une personne ne sait pas
faire quelque chose avec Gimp que Gimp n'est pas capable de le faire.
et il n'y a pas besoin
de les utiliser *régulièrement* pour le constater.
Ben si, justement, c'est en maîtrisant les outils que tu peux parler
de leurs limitations.
pehache-tolai wrote:
J'ai prétendu une seule chose : que Gimp ne pouvait pas rendre les
mêmes services que Photoshop. C'est une réalité
En dehors de certains aspects très particuliers,
c'est une réalité qui
n'est constatée que par ceux qui ne maîtrisent pas Gimp.
En d'autres termes, ce n'est pas parce qu'une personne ne sait pas
faire quelque chose avec Gimp que Gimp n'est pas capable de le faire.et il n'y a pas besoin
de les utiliser *régulièrement* pour le constater.
Ben si, justement, c'est en maîtrisant les outils que tu peux parler
de leurs limitations.
