2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)
Je veux bien voir ça ;-)
2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)
Je veux bien voir ça ;-)
2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)
Je veux bien voir ça ;-)
1/ c'est _hors_ norme
Je sais bien que c'est hors norme. Seulement, à l'époque où la no rme
Fortran ne fournissait *aucun* mécanisme d'allocation dynamique (avant
Fortran 90, donc) il fallait bien trouver des solutions. Respecter la
norme c'est très bien, mais par moment il faut être un peu
pragmatique...
Mais oui. Lorsqu'on code un truc dans son coin sur sa petite
machine, c'est bien. Lorsqu'on doit écrire du code pérenne, c 'en est
une autre.
Et la syntaxe des pointeurs Cray s'était peu à peu imposée, au po int
de devenir une extension "standard de fait", implémentée par tous l es
grands constructeurs (en tous cas dans le monde Unix, je ne sais pas
pour VMS). Tout compilo ne proposant pas cette extension s'excluait
d'entrée du jeu dans les applis industrielles.
Là encore, non. Il y a de très bonnes raisons d'avoir une m émoire
_statique_ en FORTRAN.
La reproductibilité est un critère tellement évident que je n'ai même
pas songé à le citer. Un compilateur qui donne des résultats faux,
c'est direct poubelle :-)
Bon. On va commencer : IVF poubelle, CVF poubelle aussi. Il y a de
subtiles bugs dans la gestion des flottants IEEE.
Et je maintiens qu'en calcul scientifique, le critère de la vitesse
d'exécution est souvent LE premier critère.
Non. En calcul scientifique, on espère un résultat _reproduct ible_,
quitte à attendre un peu plus.
Suivre la norme pour un compilo veut dire compiler tout code
respectant ladite norme. Ce qui n'empêche pas de compiler des
extensions à la norme.
Bien sûr, bien sûr... Sauf que ce qui est hors norme n'est pas
forcément implantable dans un compilateur qui doit fonctionner sur
certaines architectures baroques.
Encore une fois, à cause de certaines limitations importantes qu'à
longtemps eu le Fortran, de nombreuses applications écrites en Fortran
ont longtemps eu recours à certaines extensions. Ce code existe et il
faut en tenir compte.
Ah, si tu le dis. F77 était fait pour faire des calculs. J'ai
personnellement utilisé du F77 à la norme avec une gestion
_dynamique_ de la mémoire sans _jamais_ n'avoir utiliser un poi nteur
Cray ou un autre truc hors norme.
Et je peux te dire que j'ai
quelques milliers de lignes de F77 derrière moi.
On est en train de titiller la norme. Ton problème est gros com me
une maison, mais je te laisse chercher. En tout cas :
rayleigh:[/export/home/bertrand/tmp] > cat test.f90
program TEST
implicit none
integer*4 I
real*4 R
R = -1.0
I = transfer(R, 0)
write(*,*) I,R
end
rayleigh:[/export/home/bertrand/tmp] > gfortran test.f90
rayleigh:[/export/home/bertrand/tmp] > ./a.out
-1082130432 -1.000000
Je rajouterais que lorsqu'on ne connaît pas Fortran correctemen t, on
évite de raconter des conneries. Le problème n'est pas gfortr an et
tu as de la chance que cela fonctionne avec d'autres compilos par ce
que c'est plutôt un hasard.
Si j'enlève l'affectation (locase=), ou bien si je compile la même
fonction en dehors du module, ça passe. Ce bout de code est pour moi
valide (et d'ailleurs même si il ne l'était pas, gfortran ne devrait
pas faire une 'internal compiler error')
Possible. Réfléchis bien à ce qu'est un module.
re-bref, en 10mn j'ai revérifié que gfortran n'était pas fiable...
Mais oui...
1/ c'est _hors_ norme
Je sais bien que c'est hors norme. Seulement, à l'époque où la no rme
Fortran ne fournissait *aucun* mécanisme d'allocation dynamique (avant
Fortran 90, donc) il fallait bien trouver des solutions. Respecter la
norme c'est très bien, mais par moment il faut être un peu
pragmatique...
Mais oui. Lorsqu'on code un truc dans son coin sur sa petite
machine, c'est bien. Lorsqu'on doit écrire du code pérenne, c 'en est
une autre.
Et la syntaxe des pointeurs Cray s'était peu à peu imposée, au po int
de devenir une extension "standard de fait", implémentée par tous l es
grands constructeurs (en tous cas dans le monde Unix, je ne sais pas
pour VMS). Tout compilo ne proposant pas cette extension s'excluait
d'entrée du jeu dans les applis industrielles.
Là encore, non. Il y a de très bonnes raisons d'avoir une m émoire
_statique_ en FORTRAN.
La reproductibilité est un critère tellement évident que je n'ai même
pas songé à le citer. Un compilateur qui donne des résultats faux,
c'est direct poubelle :-)
Bon. On va commencer : IVF poubelle, CVF poubelle aussi. Il y a de
subtiles bugs dans la gestion des flottants IEEE.
Et je maintiens qu'en calcul scientifique, le critère de la vitesse
d'exécution est souvent LE premier critère.
Non. En calcul scientifique, on espère un résultat _reproduct ible_,
quitte à attendre un peu plus.
Suivre la norme pour un compilo veut dire compiler tout code
respectant ladite norme. Ce qui n'empêche pas de compiler des
extensions à la norme.
Bien sûr, bien sûr... Sauf que ce qui est hors norme n'est pas
forcément implantable dans un compilateur qui doit fonctionner sur
certaines architectures baroques.
Encore une fois, à cause de certaines limitations importantes qu'à
longtemps eu le Fortran, de nombreuses applications écrites en Fortran
ont longtemps eu recours à certaines extensions. Ce code existe et il
faut en tenir compte.
Ah, si tu le dis. F77 était fait pour faire des calculs. J'ai
personnellement utilisé du F77 à la norme avec une gestion
_dynamique_ de la mémoire sans _jamais_ n'avoir utiliser un poi nteur
Cray ou un autre truc hors norme.
Et je peux te dire que j'ai
quelques milliers de lignes de F77 derrière moi.
On est en train de titiller la norme. Ton problème est gros com me
une maison, mais je te laisse chercher. En tout cas :
rayleigh:[/export/home/bertrand/tmp] > cat test.f90
program TEST
implicit none
integer*4 I
real*4 R
R = -1.0
I = transfer(R, 0)
write(*,*) I,R
end
rayleigh:[/export/home/bertrand/tmp] > gfortran test.f90
rayleigh:[/export/home/bertrand/tmp] > ./a.out
-1082130432 -1.000000
Je rajouterais que lorsqu'on ne connaît pas Fortran correctemen t, on
évite de raconter des conneries. Le problème n'est pas gfortr an et
tu as de la chance que cela fonctionne avec d'autres compilos par ce
que c'est plutôt un hasard.
Si j'enlève l'affectation (locase=), ou bien si je compile la même
fonction en dehors du module, ça passe. Ce bout de code est pour moi
valide (et d'ailleurs même si il ne l'était pas, gfortran ne devrait
pas faire une 'internal compiler error')
Possible. Réfléchis bien à ce qu'est un module.
re-bref, en 10mn j'ai revérifié que gfortran n'était pas fiable...
Mais oui...
1/ c'est _hors_ norme
Je sais bien que c'est hors norme. Seulement, à l'époque où la no rme
Fortran ne fournissait *aucun* mécanisme d'allocation dynamique (avant
Fortran 90, donc) il fallait bien trouver des solutions. Respecter la
norme c'est très bien, mais par moment il faut être un peu
pragmatique...
Mais oui. Lorsqu'on code un truc dans son coin sur sa petite
machine, c'est bien. Lorsqu'on doit écrire du code pérenne, c 'en est
une autre.
Et la syntaxe des pointeurs Cray s'était peu à peu imposée, au po int
de devenir une extension "standard de fait", implémentée par tous l es
grands constructeurs (en tous cas dans le monde Unix, je ne sais pas
pour VMS). Tout compilo ne proposant pas cette extension s'excluait
d'entrée du jeu dans les applis industrielles.
Là encore, non. Il y a de très bonnes raisons d'avoir une m émoire
_statique_ en FORTRAN.
La reproductibilité est un critère tellement évident que je n'ai même
pas songé à le citer. Un compilateur qui donne des résultats faux,
c'est direct poubelle :-)
Bon. On va commencer : IVF poubelle, CVF poubelle aussi. Il y a de
subtiles bugs dans la gestion des flottants IEEE.
Et je maintiens qu'en calcul scientifique, le critère de la vitesse
d'exécution est souvent LE premier critère.
Non. En calcul scientifique, on espère un résultat _reproduct ible_,
quitte à attendre un peu plus.
Suivre la norme pour un compilo veut dire compiler tout code
respectant ladite norme. Ce qui n'empêche pas de compiler des
extensions à la norme.
Bien sûr, bien sûr... Sauf que ce qui est hors norme n'est pas
forcément implantable dans un compilateur qui doit fonctionner sur
certaines architectures baroques.
Encore une fois, à cause de certaines limitations importantes qu'à
longtemps eu le Fortran, de nombreuses applications écrites en Fortran
ont longtemps eu recours à certaines extensions. Ce code existe et il
faut en tenir compte.
Ah, si tu le dis. F77 était fait pour faire des calculs. J'ai
personnellement utilisé du F77 à la norme avec une gestion
_dynamique_ de la mémoire sans _jamais_ n'avoir utiliser un poi nteur
Cray ou un autre truc hors norme.
Et je peux te dire que j'ai
quelques milliers de lignes de F77 derrière moi.
On est en train de titiller la norme. Ton problème est gros com me
une maison, mais je te laisse chercher. En tout cas :
rayleigh:[/export/home/bertrand/tmp] > cat test.f90
program TEST
implicit none
integer*4 I
real*4 R
R = -1.0
I = transfer(R, 0)
write(*,*) I,R
end
rayleigh:[/export/home/bertrand/tmp] > gfortran test.f90
rayleigh:[/export/home/bertrand/tmp] > ./a.out
-1082130432 -1.000000
Je rajouterais que lorsqu'on ne connaît pas Fortran correctemen t, on
évite de raconter des conneries. Le problème n'est pas gfortr an et
tu as de la chance que cela fonctionne avec d'autres compilos par ce
que c'est plutôt un hasard.
Si j'enlève l'affectation (locase=), ou bien si je compile la même
fonction en dehors du module, ça passe. Ce bout de code est pour moi
valide (et d'ailleurs même si il ne l'était pas, gfortran ne devrait
pas faire une 'internal compiler error')
Possible. Réfléchis bien à ce qu'est un module.
re-bref, en 10mn j'ai revérifié que gfortran n'était pas fiable...
Mais oui...
Le 05-07-2007, à propos de
Re: fortran, linux,
thierry écrivait dans fr.comp.os.linux.debats :2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)
Je veux bien voir ça ;-)
HEAP__1 = %LOC(HEAP__)
Qui compile farpaitement avec g77. Une autre question ?
Le 05-07-2007, à propos de
Re: fortran, linux,
thierry écrivait dans fr.comp.os.linux.debats :
2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)
Je veux bien voir ça ;-)
HEAP__1 = %LOC(HEAP__)
Qui compile farpaitement avec g77. Une autre question ?
Le 05-07-2007, à propos de
Re: fortran, linux,
thierry écrivait dans fr.comp.os.linux.debats :2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)
Je veux bien voir ça ;-)
HEAP__1 = %LOC(HEAP__)
Qui compile farpaitement avec g77. Une autre question ?
On 5 juil, 15:31, JKB wrote:1/ c'est _hors_ norme
Je sais bien que c'est hors norme. Seulement, à l'époque où la norme
Fortran ne fournissait *aucun* mécanisme d'allocation dynamique (avant
Fortran 90, donc) il fallait bien trouver des solutions. Respecter la
norme c'est très bien, mais par moment il faut être un peu
pragmatique...
Mais oui. Lorsqu'on code un truc dans son coin sur sa petite
machine, c'est bien. Lorsqu'on doit écrire du code pérenne, c'en est
une autre.
Ca tombe bien, je te parle de code pérenne, écrit au cours des 40
dernières années par des dizaines (peut-être plutôt centaines,
d'ailleurs) de développeurs (de métier ou pas), ayant été porté sur à
peu près toutes les plateformes imaginables à un moment où à un autre,
dépassant probablement le million de lignes. Tout le contraire d'un
"truc écrit dans son coin sur sa petite machine", on est bien
d'accord ?
Et bien tiens toi bien, on y trouve des extensions à la norme: les
pointeurs Cray, la syntaxe REAL*8, notamment. Ce qui ne pose aucun
quand cela se fait dans un cadre bien défini et contrôlé.
Et la syntaxe des pointeurs Cray s'était peu à peu imposée, au point
de devenir une extension "standard de fait", implémentée par tous les
grands constructeurs (en tous cas dans le monde Unix, je ne sais pas
pour VMS). Tout compilo ne proposant pas cette extension s'excluait
d'entrée du jeu dans les applis industrielles.
Là encore, non. Il y a de très bonnes raisons d'avoir une mémoire
_statique_ en FORTRAN.
Ni plus ni moins que dans d'autres langages. Et il y a parfois de très
bonnes raisons d'avoir besoin de mémoire dynamique.
La reproductibilité est un critère tellement évident que je n'ai même
pas songé à le citer. Un compilateur qui donne des résultats faux,
c'est direct poubelle :-)
Bon. On va commencer : IVF poubelle, CVF poubelle aussi. Il y a de
subtiles bugs dans la gestion des flottants IEEE.
La plupart des codes n'ont pas besoin d'avoir une reproductibilité au
bit près, mais à la précision numérique de la machine *et* des calculs
près. On se fiche bien d'avoir tous les bits identiques à partir du
moment où l'on sait que la précision en sortie des calculs n'est que
de 3 digits (par exemple) et que le reste n'est pas significatif.
Et je maintiens qu'en calcul scientifique, le critère de la vitesse
d'exécution est souvent LE premier critère.
Non. En calcul scientifique, on espère un résultat _reproductible_,
quitte à attendre un peu plus.
En effet on a besoin d'un résultat "juste". Une fois cette évidence
énoncée, on se préoccupe de vitesse, du moins en calcul lourd.Suivre la norme pour un compilo veut dire compiler tout code
respectant ladite norme. Ce qui n'empêche pas de compiler des
extensions à la norme.
Bien sûr, bien sûr... Sauf que ce qui est hors norme n'est pas
forcément implantable dans un compilateur qui doit fonctionner sur
certaines architectures baroques.
Je n'ai jamais dit qu'il fallait faire n'importe quoi dans le hors
norme.Encore une fois, à cause de certaines limitations importantes qu'à
longtemps eu le Fortran, de nombreuses applications écrites en Fortran
ont longtemps eu recours à certaines extensions. Ce code existe et il
faut en tenir compte.
Ah, si tu le dis. F77 était fait pour faire des calculs. J'ai
personnellement utilisé du F77 à la norme avec une gestion
_dynamique_ de la mémoire sans _jamais_ n'avoir utiliser un pointeur
Cray ou un autre truc hors norme.
Strictement dans le monde fermé F77 je ne vois pas comment c'est
possible.
On peut toujours ensuite trouver des moyens plus ou moins détournés
pour avoir une gestion plus ou moins dynamique de la mémoire, mais en
général liés à un environnement particulier et qui posent
potentiellement autant de problèmes de portabilité qu'une extension à
la norme.
Et je peux te dire que j'ai
quelques milliers de lignes de F77 derrière moi.
On joue à celui qui a la plus grosse ? Moi aussi...
On est en train de titiller la norme. Ton problème est gros comme
une maison, mais je te laisse chercher. En tout cas :
rayleigh:[/export/home/bertrand/tmp] > cat test.f90
program TEST
implicit none
integer*4 I
real*4 R
R = -1.0
I = transfer(R, 0)
write(*,*) I,R
end
rayleigh:[/export/home/bertrand/tmp] > gfortran test.f90
rayleigh:[/export/home/bertrand/tmp] > ./a.out
-1082130432 -1.000000
Et tu démontres quoi ici, à part que gfortran ne se plante pas tout le
temps ?
Je rajouterais que lorsqu'on ne connaît pas Fortran correctement, on
évite de raconter des conneries. Le problème n'est pas gfortran et
tu as de la chance que cela fonctionne avec d'autres compilos parce
que c'est plutôt un hasard.
Ben voyons... Mon exemple ne titille absolument pas la norme, la
syntaxe est *légale* jusqu'à preuve du contraire, et gfortran se
plante dessus. Point.
Quant à ne pas connaître Fortran, tu repasseras.
Si j'enlève l'affectation (locase=), ou bien si je compile la même
fonction en dehors du module, ça passe. Ce bout de code est pour moi
valide (et d'ailleurs même si il ne l'était pas, gfortran ne devrait
pas faire une 'internal compiler error')
Possible. Réfléchis bien à ce qu'est un module.
Explique-moi donc plutôt ce qui n'est pas légal dans le code que j'ai
posté. Et mieux, explique-moi donc pourquoi ça finit en "compiler
internal error" même à supposer qu'il ne serait pas légal.
On 5 juil, 15:31, JKB <knatsc...@koenigsberg.fr> wrote:
1/ c'est _hors_ norme
Je sais bien que c'est hors norme. Seulement, à l'époque où la norme
Fortran ne fournissait *aucun* mécanisme d'allocation dynamique (avant
Fortran 90, donc) il fallait bien trouver des solutions. Respecter la
norme c'est très bien, mais par moment il faut être un peu
pragmatique...
Mais oui. Lorsqu'on code un truc dans son coin sur sa petite
machine, c'est bien. Lorsqu'on doit écrire du code pérenne, c'en est
une autre.
Ca tombe bien, je te parle de code pérenne, écrit au cours des 40
dernières années par des dizaines (peut-être plutôt centaines,
d'ailleurs) de développeurs (de métier ou pas), ayant été porté sur à
peu près toutes les plateformes imaginables à un moment où à un autre,
dépassant probablement le million de lignes. Tout le contraire d'un
"truc écrit dans son coin sur sa petite machine", on est bien
d'accord ?
Et bien tiens toi bien, on y trouve des extensions à la norme: les
pointeurs Cray, la syntaxe REAL*8, notamment. Ce qui ne pose aucun
quand cela se fait dans un cadre bien défini et contrôlé.
Et la syntaxe des pointeurs Cray s'était peu à peu imposée, au point
de devenir une extension "standard de fait", implémentée par tous les
grands constructeurs (en tous cas dans le monde Unix, je ne sais pas
pour VMS). Tout compilo ne proposant pas cette extension s'excluait
d'entrée du jeu dans les applis industrielles.
Là encore, non. Il y a de très bonnes raisons d'avoir une mémoire
_statique_ en FORTRAN.
Ni plus ni moins que dans d'autres langages. Et il y a parfois de très
bonnes raisons d'avoir besoin de mémoire dynamique.
La reproductibilité est un critère tellement évident que je n'ai même
pas songé à le citer. Un compilateur qui donne des résultats faux,
c'est direct poubelle :-)
Bon. On va commencer : IVF poubelle, CVF poubelle aussi. Il y a de
subtiles bugs dans la gestion des flottants IEEE.
La plupart des codes n'ont pas besoin d'avoir une reproductibilité au
bit près, mais à la précision numérique de la machine *et* des calculs
près. On se fiche bien d'avoir tous les bits identiques à partir du
moment où l'on sait que la précision en sortie des calculs n'est que
de 3 digits (par exemple) et que le reste n'est pas significatif.
Et je maintiens qu'en calcul scientifique, le critère de la vitesse
d'exécution est souvent LE premier critère.
Non. En calcul scientifique, on espère un résultat _reproductible_,
quitte à attendre un peu plus.
En effet on a besoin d'un résultat "juste". Une fois cette évidence
énoncée, on se préoccupe de vitesse, du moins en calcul lourd.
Suivre la norme pour un compilo veut dire compiler tout code
respectant ladite norme. Ce qui n'empêche pas de compiler des
extensions à la norme.
Bien sûr, bien sûr... Sauf que ce qui est hors norme n'est pas
forcément implantable dans un compilateur qui doit fonctionner sur
certaines architectures baroques.
Je n'ai jamais dit qu'il fallait faire n'importe quoi dans le hors
norme.
Encore une fois, à cause de certaines limitations importantes qu'à
longtemps eu le Fortran, de nombreuses applications écrites en Fortran
ont longtemps eu recours à certaines extensions. Ce code existe et il
faut en tenir compte.
Ah, si tu le dis. F77 était fait pour faire des calculs. J'ai
personnellement utilisé du F77 à la norme avec une gestion
_dynamique_ de la mémoire sans _jamais_ n'avoir utiliser un pointeur
Cray ou un autre truc hors norme.
Strictement dans le monde fermé F77 je ne vois pas comment c'est
possible.
On peut toujours ensuite trouver des moyens plus ou moins détournés
pour avoir une gestion plus ou moins dynamique de la mémoire, mais en
général liés à un environnement particulier et qui posent
potentiellement autant de problèmes de portabilité qu'une extension à
la norme.
Et je peux te dire que j'ai
quelques milliers de lignes de F77 derrière moi.
On joue à celui qui a la plus grosse ? Moi aussi...
On est en train de titiller la norme. Ton problème est gros comme
une maison, mais je te laisse chercher. En tout cas :
rayleigh:[/export/home/bertrand/tmp] > cat test.f90
program TEST
implicit none
integer*4 I
real*4 R
R = -1.0
I = transfer(R, 0)
write(*,*) I,R
end
rayleigh:[/export/home/bertrand/tmp] > gfortran test.f90
rayleigh:[/export/home/bertrand/tmp] > ./a.out
-1082130432 -1.000000
Et tu démontres quoi ici, à part que gfortran ne se plante pas tout le
temps ?
Je rajouterais que lorsqu'on ne connaît pas Fortran correctement, on
évite de raconter des conneries. Le problème n'est pas gfortran et
tu as de la chance que cela fonctionne avec d'autres compilos parce
que c'est plutôt un hasard.
Ben voyons... Mon exemple ne titille absolument pas la norme, la
syntaxe est *légale* jusqu'à preuve du contraire, et gfortran se
plante dessus. Point.
Quant à ne pas connaître Fortran, tu repasseras.
Si j'enlève l'affectation (locase=), ou bien si je compile la même
fonction en dehors du module, ça passe. Ce bout de code est pour moi
valide (et d'ailleurs même si il ne l'était pas, gfortran ne devrait
pas faire une 'internal compiler error')
Possible. Réfléchis bien à ce qu'est un module.
Explique-moi donc plutôt ce qui n'est pas légal dans le code que j'ai
posté. Et mieux, explique-moi donc pourquoi ça finit en "compiler
internal error" même à supposer qu'il ne serait pas légal.
On 5 juil, 15:31, JKB wrote:1/ c'est _hors_ norme
Je sais bien que c'est hors norme. Seulement, à l'époque où la norme
Fortran ne fournissait *aucun* mécanisme d'allocation dynamique (avant
Fortran 90, donc) il fallait bien trouver des solutions. Respecter la
norme c'est très bien, mais par moment il faut être un peu
pragmatique...
Mais oui. Lorsqu'on code un truc dans son coin sur sa petite
machine, c'est bien. Lorsqu'on doit écrire du code pérenne, c'en est
une autre.
Ca tombe bien, je te parle de code pérenne, écrit au cours des 40
dernières années par des dizaines (peut-être plutôt centaines,
d'ailleurs) de développeurs (de métier ou pas), ayant été porté sur à
peu près toutes les plateformes imaginables à un moment où à un autre,
dépassant probablement le million de lignes. Tout le contraire d'un
"truc écrit dans son coin sur sa petite machine", on est bien
d'accord ?
Et bien tiens toi bien, on y trouve des extensions à la norme: les
pointeurs Cray, la syntaxe REAL*8, notamment. Ce qui ne pose aucun
quand cela se fait dans un cadre bien défini et contrôlé.
Et la syntaxe des pointeurs Cray s'était peu à peu imposée, au point
de devenir une extension "standard de fait", implémentée par tous les
grands constructeurs (en tous cas dans le monde Unix, je ne sais pas
pour VMS). Tout compilo ne proposant pas cette extension s'excluait
d'entrée du jeu dans les applis industrielles.
Là encore, non. Il y a de très bonnes raisons d'avoir une mémoire
_statique_ en FORTRAN.
Ni plus ni moins que dans d'autres langages. Et il y a parfois de très
bonnes raisons d'avoir besoin de mémoire dynamique.
La reproductibilité est un critère tellement évident que je n'ai même
pas songé à le citer. Un compilateur qui donne des résultats faux,
c'est direct poubelle :-)
Bon. On va commencer : IVF poubelle, CVF poubelle aussi. Il y a de
subtiles bugs dans la gestion des flottants IEEE.
La plupart des codes n'ont pas besoin d'avoir une reproductibilité au
bit près, mais à la précision numérique de la machine *et* des calculs
près. On se fiche bien d'avoir tous les bits identiques à partir du
moment où l'on sait que la précision en sortie des calculs n'est que
de 3 digits (par exemple) et que le reste n'est pas significatif.
Et je maintiens qu'en calcul scientifique, le critère de la vitesse
d'exécution est souvent LE premier critère.
Non. En calcul scientifique, on espère un résultat _reproductible_,
quitte à attendre un peu plus.
En effet on a besoin d'un résultat "juste". Une fois cette évidence
énoncée, on se préoccupe de vitesse, du moins en calcul lourd.Suivre la norme pour un compilo veut dire compiler tout code
respectant ladite norme. Ce qui n'empêche pas de compiler des
extensions à la norme.
Bien sûr, bien sûr... Sauf que ce qui est hors norme n'est pas
forcément implantable dans un compilateur qui doit fonctionner sur
certaines architectures baroques.
Je n'ai jamais dit qu'il fallait faire n'importe quoi dans le hors
norme.Encore une fois, à cause de certaines limitations importantes qu'à
longtemps eu le Fortran, de nombreuses applications écrites en Fortran
ont longtemps eu recours à certaines extensions. Ce code existe et il
faut en tenir compte.
Ah, si tu le dis. F77 était fait pour faire des calculs. J'ai
personnellement utilisé du F77 à la norme avec une gestion
_dynamique_ de la mémoire sans _jamais_ n'avoir utiliser un pointeur
Cray ou un autre truc hors norme.
Strictement dans le monde fermé F77 je ne vois pas comment c'est
possible.
On peut toujours ensuite trouver des moyens plus ou moins détournés
pour avoir une gestion plus ou moins dynamique de la mémoire, mais en
général liés à un environnement particulier et qui posent
potentiellement autant de problèmes de portabilité qu'une extension à
la norme.
Et je peux te dire que j'ai
quelques milliers de lignes de F77 derrière moi.
On joue à celui qui a la plus grosse ? Moi aussi...
On est en train de titiller la norme. Ton problème est gros comme
une maison, mais je te laisse chercher. En tout cas :
rayleigh:[/export/home/bertrand/tmp] > cat test.f90
program TEST
implicit none
integer*4 I
real*4 R
R = -1.0
I = transfer(R, 0)
write(*,*) I,R
end
rayleigh:[/export/home/bertrand/tmp] > gfortran test.f90
rayleigh:[/export/home/bertrand/tmp] > ./a.out
-1082130432 -1.000000
Et tu démontres quoi ici, à part que gfortran ne se plante pas tout le
temps ?
Je rajouterais que lorsqu'on ne connaît pas Fortran correctement, on
évite de raconter des conneries. Le problème n'est pas gfortran et
tu as de la chance que cela fonctionne avec d'autres compilos parce
que c'est plutôt un hasard.
Ben voyons... Mon exemple ne titille absolument pas la norme, la
syntaxe est *légale* jusqu'à preuve du contraire, et gfortran se
plante dessus. Point.
Quant à ne pas connaître Fortran, tu repasseras.
Si j'enlève l'affectation (locase=), ou bien si je compile la même
fonction en dehors du module, ça passe. Ce bout de code est pour moi
valide (et d'ailleurs même si il ne l'était pas, gfortran ne devrait
pas faire une 'internal compiler error')
Possible. Réfléchis bien à ce qu'est un module.
Explique-moi donc plutôt ce qui n'est pas légal dans le code que j'ai
posté. Et mieux, explique-moi donc pourquoi ça finit en "compiler
internal error" même à supposer qu'il ne serait pas légal.
On 5 juil, 18:19, JKB wrote:Le 05-07-2007, à propos de
Re: fortran, linux,
thierry écrivait dans fr.comp.os.linux.debats :2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)
Je veux bien voir ça ;-)
HEAP__1 = %LOC(HEAP__)
Qui compile farpaitement avec g77. Une autre question ?
Oui: c'est dans la norme Fortran, %LOC() ? :-)
On 5 juil, 18:19, JKB <knatsc...@koenigsberg.fr> wrote:
Le 05-07-2007, à propos de
Re: fortran, linux,
thierry écrivait dans fr.comp.os.linux.debats :
2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)
Je veux bien voir ça ;-)
HEAP__1 = %LOC(HEAP__)
Qui compile farpaitement avec g77. Une autre question ?
Oui: c'est dans la norme Fortran, %LOC() ? :-)
On 5 juil, 18:19, JKB wrote:Le 05-07-2007, à propos de
Re: fortran, linux,
thierry écrivait dans fr.comp.os.linux.debats :2/ les pointeurs existent dans g77 (cf l'utilisation faite par
vastf90 que je dois encore avoir sur une disquette)
Je veux bien voir ça ;-)
HEAP__1 = %LOC(HEAP__)
Qui compile farpaitement avec g77. Une autre question ?
Oui: c'est dans la norme Fortran, %LOC() ? :-)
Ca tombe bien, je te parle de code pérenne, écrit au cours des 40
dernières années par des dizaines (peut-être plutôt centaines,
d'ailleurs) de développeurs (de métier ou pas), ayant été porté sur à
peu près toutes les plateformes imaginables à un moment où à un
autre, dépassant probablement le million de lignes. Tout le
contraire d'un "truc écrit dans son coin sur sa petite machine", on
est bien d'accord ?
Non. On n'est pas d'accord et on ne le sera jamais.
Un code bien
écrit se satisfait de la norme, ce qui permet de le porter aisément.
Des codes comme ça, figure-toi que j'en ai eu dans les pattes (entre
autre écrit par des ingés de Thomson depuis les années 60). Les
types suivaient _scrupuleusement_ la norme (quitte à utiliser un
préprocesseur) pour n'avoir _aucun_ problème de portabilité. Et
crois-moi (ou ne me crois pasn je m'en fous royalement), lorsque
j'ai pris leur code et que je l'ai compilé sur mon alpha ev6 avec
g77 (gcc3), je n'ai eu _aucun_ problème et le seul truc que j'ai dû
rajouter au makefile, c'est l'option de compilation pour compiler du
FORTRAN-IV. Tout autre code est mal écrit.
Et bien tiens toi bien, on y trouve des extensions à la norme: les
pointeurs Cray, la syntaxe REAL*8, notamment. Ce qui ne pose aucun
quand cela se fait dans un cadre bien défini et contrôlé.
Bien contrôlé, cela veut dire sur sa petite machine ou pour des
applications à environnement maîtrisé.
Et il y a une différence
notable entre les extension REAL*8 (qui provient des extensions VAX)
et les pointeurs.
D'ailleurs, trouve-moi un compilo Fortran77 qui
suivent toutes ces extensions VAX (en particulier le REAL*16 et le
COMPLEX*32).
Là encore, non. Il y a de très bonnes raisons d'avoir une
mémoire _statique_ en FORTRAN.
Ni plus ni moins que dans d'autres langages. Et il y a parfois de
très bonnes raisons d'avoir besoin de mémoire dynamique.
Mais tu es un abruti ! Je t'ai dit plus haut qu'il était tout à fait
possible d'utiliser en Fortran77 de la mémoire dynamque,
mais qu'il
y avait une raison pour laquelle la mémoire était gérée de façon
statique dans une unité de programme.
La plupart des codes n'ont pas besoin d'avoir une reproductibilité au
bit près, mais à la précision numérique de la machine *et* des
calculs près. On se fiche bien d'avoir tous les bits identiques à
partir du moment où l'on sait que la précision en sortie des calculs
n'est que de 3 digits (par exemple) et que le reste n'est pas
significatif.
Toi, tu n'as jamais fait d'analyse numérique. Tu n'as jamais bossé
sur des codes faisant des calculs longs et fastidieux où la plus
petite dérive est problématique parce que source de divergence !
On se contrefiche de la précision des calculs ! On veut simplement
que si l'on obtient un résultat A sur une machine, on obtienne le
même résultat A sur une autre.
Ah, si tu le dis. F77 était fait pour faire des calculs.
J'ai personnellement utilisé du F77 à la norme avec une
gestion _dynamique_ de la mémoire sans _jamais_ n'avoir
utiliser un pointeur Cray ou un autre truc hors norme.
Strictement dans le monde fermé F77 je ne vois pas comment c'est
possible.
Tu n'as _jamais_ appelé de bibliothèques externes ?
On peut toujours ensuite trouver des moyens plus ou moins détournés
pour avoir une gestion plus ou moins dynamique de la mémoire, mais en
général liés à un environnement particulier et qui posent
potentiellement autant de problèmes de portabilité qu'une extension à
la norme.
Non.
On joue à celui qui a la plus grosse ? Moi aussi...
On ne dirait pourtant pas.
Et tu démontres quoi ici, à part que gfortran ne se plante pas tout
le temps ?
Que tu as tout faux parce que ton _code_ est faux.
Ben voyons... Mon exemple ne titille absolument pas la norme, la
syntaxe est *légale* jusqu'à preuve du contraire, et gfortran se
plante dessus. Point.
Non. Ton appel est foireux
et c'est pour cela que gfortran râle.
Et je maintiens que le fait que les autres compilent est plus dû au
hasard qu'à autre chose.
Quant à ne pas connaître Fortran, tu repasseras.
Tu m'excuseras, mais se dire spécialiste et ne pas voir l'erreur
dans ton appel de fonction, cela me fait doucement rigoler.
Explique-moi donc plutôt ce qui n'est pas légal dans le code que j'ai
posté. Et mieux, explique-moi donc pourquoi ça finit en "compiler
internal error" même à supposer qu'il ne serait pas légal.
Je n'ai pas dit que gfortran n'avait pas des problèmes. Je prétends
simplement qu'il est normal qu'il râle sur tes deux exemples. Tu
prétends que transfer() ne fonctionne pas,
je t'ai démontré le
contraire.
En tant que grand spécialiste du Fortran, tu devrais voir
immédiatement pourquoi ton transfer() à toi ne fonctionne pas.
Sinon, va reprendre des cours, il n'y a que cela. Le deuxième cas
est un peu plus complexe puisqu'il s'agit d'une histoire de gestion
de la mémoire. J'ai failli être bin, mais je n'ai franchement pas
envie d'aider un type comme toi. Va poser ta question sur fcf.
Ca tombe bien, je te parle de code pérenne, écrit au cours des 40
dernières années par des dizaines (peut-être plutôt centaines,
d'ailleurs) de développeurs (de métier ou pas), ayant été porté sur à
peu près toutes les plateformes imaginables à un moment où à un
autre, dépassant probablement le million de lignes. Tout le
contraire d'un "truc écrit dans son coin sur sa petite machine", on
est bien d'accord ?
Non. On n'est pas d'accord et on ne le sera jamais.
Un code bien
écrit se satisfait de la norme, ce qui permet de le porter aisément.
Des codes comme ça, figure-toi que j'en ai eu dans les pattes (entre
autre écrit par des ingés de Thomson depuis les années 60). Les
types suivaient _scrupuleusement_ la norme (quitte à utiliser un
préprocesseur) pour n'avoir _aucun_ problème de portabilité. Et
crois-moi (ou ne me crois pasn je m'en fous royalement), lorsque
j'ai pris leur code et que je l'ai compilé sur mon alpha ev6 avec
g77 (gcc3), je n'ai eu _aucun_ problème et le seul truc que j'ai dû
rajouter au makefile, c'est l'option de compilation pour compiler du
FORTRAN-IV. Tout autre code est mal écrit.
Et bien tiens toi bien, on y trouve des extensions à la norme: les
pointeurs Cray, la syntaxe REAL*8, notamment. Ce qui ne pose aucun
quand cela se fait dans un cadre bien défini et contrôlé.
Bien contrôlé, cela veut dire sur sa petite machine ou pour des
applications à environnement maîtrisé.
Et il y a une différence
notable entre les extension REAL*8 (qui provient des extensions VAX)
et les pointeurs.
D'ailleurs, trouve-moi un compilo Fortran77 qui
suivent toutes ces extensions VAX (en particulier le REAL*16 et le
COMPLEX*32).
Là encore, non. Il y a de très bonnes raisons d'avoir une
mémoire _statique_ en FORTRAN.
Ni plus ni moins que dans d'autres langages. Et il y a parfois de
très bonnes raisons d'avoir besoin de mémoire dynamique.
Mais tu es un abruti ! Je t'ai dit plus haut qu'il était tout à fait
possible d'utiliser en Fortran77 de la mémoire dynamque,
mais qu'il
y avait une raison pour laquelle la mémoire était gérée de façon
statique dans une unité de programme.
La plupart des codes n'ont pas besoin d'avoir une reproductibilité au
bit près, mais à la précision numérique de la machine *et* des
calculs près. On se fiche bien d'avoir tous les bits identiques à
partir du moment où l'on sait que la précision en sortie des calculs
n'est que de 3 digits (par exemple) et que le reste n'est pas
significatif.
Toi, tu n'as jamais fait d'analyse numérique. Tu n'as jamais bossé
sur des codes faisant des calculs longs et fastidieux où la plus
petite dérive est problématique parce que source de divergence !
On se contrefiche de la précision des calculs ! On veut simplement
que si l'on obtient un résultat A sur une machine, on obtienne le
même résultat A sur une autre.
Ah, si tu le dis. F77 était fait pour faire des calculs.
J'ai personnellement utilisé du F77 à la norme avec une
gestion _dynamique_ de la mémoire sans _jamais_ n'avoir
utiliser un pointeur Cray ou un autre truc hors norme.
Strictement dans le monde fermé F77 je ne vois pas comment c'est
possible.
Tu n'as _jamais_ appelé de bibliothèques externes ?
On peut toujours ensuite trouver des moyens plus ou moins détournés
pour avoir une gestion plus ou moins dynamique de la mémoire, mais en
général liés à un environnement particulier et qui posent
potentiellement autant de problèmes de portabilité qu'une extension à
la norme.
Non.
On joue à celui qui a la plus grosse ? Moi aussi...
On ne dirait pourtant pas.
Et tu démontres quoi ici, à part que gfortran ne se plante pas tout
le temps ?
Que tu as tout faux parce que ton _code_ est faux.
Ben voyons... Mon exemple ne titille absolument pas la norme, la
syntaxe est *légale* jusqu'à preuve du contraire, et gfortran se
plante dessus. Point.
Non. Ton appel est foireux
et c'est pour cela que gfortran râle.
Et je maintiens que le fait que les autres compilent est plus dû au
hasard qu'à autre chose.
Quant à ne pas connaître Fortran, tu repasseras.
Tu m'excuseras, mais se dire spécialiste et ne pas voir l'erreur
dans ton appel de fonction, cela me fait doucement rigoler.
Explique-moi donc plutôt ce qui n'est pas légal dans le code que j'ai
posté. Et mieux, explique-moi donc pourquoi ça finit en "compiler
internal error" même à supposer qu'il ne serait pas légal.
Je n'ai pas dit que gfortran n'avait pas des problèmes. Je prétends
simplement qu'il est normal qu'il râle sur tes deux exemples. Tu
prétends que transfer() ne fonctionne pas,
je t'ai démontré le
contraire.
En tant que grand spécialiste du Fortran, tu devrais voir
immédiatement pourquoi ton transfer() à toi ne fonctionne pas.
Sinon, va reprendre des cours, il n'y a que cela. Le deuxième cas
est un peu plus complexe puisqu'il s'agit d'une histoire de gestion
de la mémoire. J'ai failli être bin, mais je n'ai franchement pas
envie d'aider un type comme toi. Va poser ta question sur fcf.
Ca tombe bien, je te parle de code pérenne, écrit au cours des 40
dernières années par des dizaines (peut-être plutôt centaines,
d'ailleurs) de développeurs (de métier ou pas), ayant été porté sur à
peu près toutes les plateformes imaginables à un moment où à un
autre, dépassant probablement le million de lignes. Tout le
contraire d'un "truc écrit dans son coin sur sa petite machine", on
est bien d'accord ?
Non. On n'est pas d'accord et on ne le sera jamais.
Un code bien
écrit se satisfait de la norme, ce qui permet de le porter aisément.
Des codes comme ça, figure-toi que j'en ai eu dans les pattes (entre
autre écrit par des ingés de Thomson depuis les années 60). Les
types suivaient _scrupuleusement_ la norme (quitte à utiliser un
préprocesseur) pour n'avoir _aucun_ problème de portabilité. Et
crois-moi (ou ne me crois pasn je m'en fous royalement), lorsque
j'ai pris leur code et que je l'ai compilé sur mon alpha ev6 avec
g77 (gcc3), je n'ai eu _aucun_ problème et le seul truc que j'ai dû
rajouter au makefile, c'est l'option de compilation pour compiler du
FORTRAN-IV. Tout autre code est mal écrit.
Et bien tiens toi bien, on y trouve des extensions à la norme: les
pointeurs Cray, la syntaxe REAL*8, notamment. Ce qui ne pose aucun
quand cela se fait dans un cadre bien défini et contrôlé.
Bien contrôlé, cela veut dire sur sa petite machine ou pour des
applications à environnement maîtrisé.
Et il y a une différence
notable entre les extension REAL*8 (qui provient des extensions VAX)
et les pointeurs.
D'ailleurs, trouve-moi un compilo Fortran77 qui
suivent toutes ces extensions VAX (en particulier le REAL*16 et le
COMPLEX*32).
Là encore, non. Il y a de très bonnes raisons d'avoir une
mémoire _statique_ en FORTRAN.
Ni plus ni moins que dans d'autres langages. Et il y a parfois de
très bonnes raisons d'avoir besoin de mémoire dynamique.
Mais tu es un abruti ! Je t'ai dit plus haut qu'il était tout à fait
possible d'utiliser en Fortran77 de la mémoire dynamque,
mais qu'il
y avait une raison pour laquelle la mémoire était gérée de façon
statique dans une unité de programme.
La plupart des codes n'ont pas besoin d'avoir une reproductibilité au
bit près, mais à la précision numérique de la machine *et* des
calculs près. On se fiche bien d'avoir tous les bits identiques à
partir du moment où l'on sait que la précision en sortie des calculs
n'est que de 3 digits (par exemple) et que le reste n'est pas
significatif.
Toi, tu n'as jamais fait d'analyse numérique. Tu n'as jamais bossé
sur des codes faisant des calculs longs et fastidieux où la plus
petite dérive est problématique parce que source de divergence !
On se contrefiche de la précision des calculs ! On veut simplement
que si l'on obtient un résultat A sur une machine, on obtienne le
même résultat A sur une autre.
Ah, si tu le dis. F77 était fait pour faire des calculs.
J'ai personnellement utilisé du F77 à la norme avec une
gestion _dynamique_ de la mémoire sans _jamais_ n'avoir
utiliser un pointeur Cray ou un autre truc hors norme.
Strictement dans le monde fermé F77 je ne vois pas comment c'est
possible.
Tu n'as _jamais_ appelé de bibliothèques externes ?
On peut toujours ensuite trouver des moyens plus ou moins détournés
pour avoir une gestion plus ou moins dynamique de la mémoire, mais en
général liés à un environnement particulier et qui posent
potentiellement autant de problèmes de portabilité qu'une extension à
la norme.
Non.
On joue à celui qui a la plus grosse ? Moi aussi...
On ne dirait pourtant pas.
Et tu démontres quoi ici, à part que gfortran ne se plante pas tout
le temps ?
Que tu as tout faux parce que ton _code_ est faux.
Ben voyons... Mon exemple ne titille absolument pas la norme, la
syntaxe est *légale* jusqu'à preuve du contraire, et gfortran se
plante dessus. Point.
Non. Ton appel est foireux
et c'est pour cela que gfortran râle.
Et je maintiens que le fait que les autres compilent est plus dû au
hasard qu'à autre chose.
Quant à ne pas connaître Fortran, tu repasseras.
Tu m'excuseras, mais se dire spécialiste et ne pas voir l'erreur
dans ton appel de fonction, cela me fait doucement rigoler.
Explique-moi donc plutôt ce qui n'est pas légal dans le code que j'ai
posté. Et mieux, explique-moi donc pourquoi ça finit en "compiler
internal error" même à supposer qu'il ne serait pas légal.
Je n'ai pas dit que gfortran n'avait pas des problèmes. Je prétends
simplement qu'il est normal qu'il râle sur tes deux exemples. Tu
prétends que transfer() ne fonctionne pas,
je t'ai démontré le
contraire.
En tant que grand spécialiste du Fortran, tu devrais voir
immédiatement pourquoi ton transfer() à toi ne fonctionne pas.
Sinon, va reprendre des cours, il n'y a que cela. Le deuxième cas
est un peu plus complexe puisqu'il s'agit d'une histoire de gestion
de la mémoire. J'ai failli être bin, mais je n'ai franchement pas
envie d'aider un type comme toi. Va poser ta question sur fcf.
"JKB" a écrit dans le message de news:Un code bien
écrit se satisfait de la norme, ce qui permet de le porter aisément.
Des codes comme ça, figure-toi que j'en ai eu dans les pattes (entre
autre écrit par des ingés de Thomson depuis les années 60). Les
types suivaient _scrupuleusement_ la norme (quitte à utiliser un
préprocesseur) pour n'avoir _aucun_ problème de portabilité. Et
crois-moi (ou ne me crois pasn je m'en fous royalement), lorsque
j'ai pris leur code et que je l'ai compilé sur mon alpha ev6 avec
g77 (gcc3), je n'ai eu _aucun_ problème et le seul truc que j'ai dû
rajouter au makefile, c'est l'option de compilation pour compiler du
FORTRAN-IV. Tout autre code est mal écrit.
Position complètement intégriste.
Avec certaines extensions bien choisies, la portabilité n'a jamais été un
réel problème non plus. En ce sens que quelque soit la plate-forme on trouve
toujours un compilo qui gère les extensions (et accessoirement l'expérience
montre que les bons compilos sont aussi ceux qui gèrent le plus
d'extensions).
Et bien tiens toi bien, on y trouve des extensions à la norme: les
pointeurs Cray, la syntaxe REAL*8, notamment. Ce qui ne pose aucun
quand cela se fait dans un cadre bien défini et contrôlé.
Bien contrôlé, cela veut dire sur sa petite machine ou pour des
applications à environnement maîtrisé.
A environnement maîtrisé en effet. Mais néanmoins sur de très nombreuses
plateformes (donc pas sur sa petite machine). Et l'environnement maîtrisé
est la règle en milieu industriel.
Et il y a une différence
notable entre les extension REAL*8 (qui provient des extensions VAX)
et les pointeurs.
Sans blague ?D'ailleurs, trouve-moi un compilo Fortran77 qui
suivent toutes ces extensions VAX (en particulier le REAL*16 et le
COMPLEX*32).
J'ai parlé de REAL*16 ? Non.
REAL*8 est une extension "raisonnable" car présente sur à peu près tous les
compilateurs sérieux (sinon tous). REAL*16 ne l'est pas, par contre, donc
effectivement je ne la recommenderais.
Là encore, non. Il y a de très bonnes raisons d'avoir une
mémoire _statique_ en FORTRAN.
Ni plus ni moins que dans d'autres langages. Et il y a parfois de
très bonnes raisons d'avoir besoin de mémoire dynamique.
Mais tu es un abruti ! Je t'ai dit plus haut qu'il était tout à fait
possible d'utiliser en Fortran77 de la mémoire dynamque,
En restant purement dans le monde F77 évidemment que non.
mais qu'il
y avait une raison pour laquelle la mémoire était gérée de façon
statique dans une unité de programme.
Il n'y a pas de raison "universelle". Juste une absence de fonctionnalité
pour le faire en F77.
La plupart des codes n'ont pas besoin d'avoir une reproductibilité au
bit près, mais à la précision numérique de la machine *et* des
calculs près. On se fiche bien d'avoir tous les bits identiques à
partir du moment où l'on sait que la précision en sortie des calculs
n'est que de 3 digits (par exemple) et que le reste n'est pas
significatif.
Toi, tu n'as jamais fait d'analyse numérique. Tu n'as jamais bossé
sur des codes faisant des calculs longs et fastidieux où la plus
petite dérive est problématique parce que source de divergence !
On se contrefiche de la précision des calculs ! On veut simplement
que si l'on obtient un résultat A sur une machine, on obtienne le
même résultat A sur une autre.
Ah bien sûr si on se contrefiche de la précision des calculs, dans ce cas
évidemment :-) !!!
Et tu me demandes si j'ai fait de l'analyse numérique :-) ?
Ton souci est donc d'avoir toujours le même résultat, même si il est faux.
Ca peut être une préoccupation intéressante dans certains cas, mais en
général on est surtout intéressé de savoir quelle est la précision du
résultat...
Ah, si tu le dis. F77 était fait pour faire des calculs.
J'ai personnellement utilisé du F77 à la norme avec une
gestion _dynamique_ de la mémoire sans _jamais_ n'avoir
utiliser un pointeur Cray ou un autre truc hors norme.
Strictement dans le monde fermé F77 je ne vois pas comment c'est
possible.
Tu n'as _jamais_ appelé de bibliothèques externes ?
Ecrites en quoi ? En C j'imagine ?
Question: l'interfaçage C/Fortran est-il décrit dans la norme F77 ?
On peut toujours ensuite trouver des moyens plus ou moins détournés
pour avoir une gestion plus ou moins dynamique de la mémoire, mais en
général liés à un environnement particulier et qui posent
potentiellement autant de problèmes de portabilité qu'une extension à
la norme.
Non.
L'interfaçage C/Fortran n'a jamais posé aucun problème de portabilité ?
On joue à celui qui a la plus grosse ? Moi aussi...
On ne dirait pourtant pas.
Je n'étais pas en érection...
Et tu démontres quoi ici, à part que gfortran ne se plante pas tout
le temps ?
Que tu as tout faux parce que ton _code_ est faux.
Tu es un rigolo, toi... Je post un code qui ne compile pas, tu postes un
autre code qui compile: je ne vois pas en quoi cela démontre que mon code
est faux. Tu as un problème de logique.
Ben voyons... Mon exemple ne titille absolument pas la norme, la
syntaxe est *légale* jusqu'à preuve du contraire, et gfortran se
plante dessus. Point.
Non. Ton appel est foireux
Prouve-le. J'ai cherché un peu, et je n'ai rien trouvé qui dise que le
premier argument de transfer() ne peut pas être un scalaire ou une
constante.
et c'est pour cela que gfortran râle.
En l'occurence gfortran ne dit pas que la syntaxe est illégale, mais que la
fonctionnalité "n'est pas implémentée" :-)
Et je maintiens que le fait que les autres compilent est plus dû au
hasard qu'à autre chose.
La hasard à 10 contre 1, hein...
Quant à ne pas connaître Fortran, tu repasseras.
Tu m'excuseras, mais se dire spécialiste et ne pas voir l'erreur
dans ton appel de fonction, cela me fait doucement rigoler.
Quelle erreur ? J'attends encore...
Explique-moi donc plutôt ce qui n'est pas légal dans le code que j'ai
posté. Et mieux, explique-moi donc pourquoi ça finit en "compiler
internal error" même à supposer qu'il ne serait pas légal.
Je n'ai pas dit que gfortran n'avait pas des problèmes. Je prétends
simplement qu'il est normal qu'il râle sur tes deux exemples. Tu
prétends que transfer() ne fonctionne pas,
Non, je prétends que transfer(-1.0,0) ne fonctionne pas, nuance.
je t'ai démontré le
contraire.
Tu as juste montré un exemple de transfer() qui fonctionne. Et alors ?
En tant que grand spécialiste du Fortran, tu devrais voir
immédiatement pourquoi ton transfer() à toi ne fonctionne pas.
J'attends une explication.
Sinon, va reprendre des cours, il n'y a que cela. Le deuxième cas
est un peu plus complexe puisqu'il s'agit d'une histoire de gestion
de la mémoire. J'ai failli être bin, mais je n'ai franchement pas
envie d'aider un type comme toi. Va poser ta question sur fcf.
Les mecs qui disent "je t'expliquerais bien mais j'ai pas le temps", en
général ils ne savent pas :-)
Et d'ailleurs sur le deuxième exemple gfortran ne râle pas, il se plante
carrément. Mais tu as sûrement une explication que tu ne veux pas donner à
cela aussi :-)
"JKB" <knatschke@koenigsberg.fr> a écrit dans le message de news:
Un code bien
écrit se satisfait de la norme, ce qui permet de le porter aisément.
Des codes comme ça, figure-toi que j'en ai eu dans les pattes (entre
autre écrit par des ingés de Thomson depuis les années 60). Les
types suivaient _scrupuleusement_ la norme (quitte à utiliser un
préprocesseur) pour n'avoir _aucun_ problème de portabilité. Et
crois-moi (ou ne me crois pasn je m'en fous royalement), lorsque
j'ai pris leur code et que je l'ai compilé sur mon alpha ev6 avec
g77 (gcc3), je n'ai eu _aucun_ problème et le seul truc que j'ai dû
rajouter au makefile, c'est l'option de compilation pour compiler du
FORTRAN-IV. Tout autre code est mal écrit.
Position complètement intégriste.
Avec certaines extensions bien choisies, la portabilité n'a jamais été un
réel problème non plus. En ce sens que quelque soit la plate-forme on trouve
toujours un compilo qui gère les extensions (et accessoirement l'expérience
montre que les bons compilos sont aussi ceux qui gèrent le plus
d'extensions).
Et bien tiens toi bien, on y trouve des extensions à la norme: les
pointeurs Cray, la syntaxe REAL*8, notamment. Ce qui ne pose aucun
quand cela se fait dans un cadre bien défini et contrôlé.
Bien contrôlé, cela veut dire sur sa petite machine ou pour des
applications à environnement maîtrisé.
A environnement maîtrisé en effet. Mais néanmoins sur de très nombreuses
plateformes (donc pas sur sa petite machine). Et l'environnement maîtrisé
est la règle en milieu industriel.
Et il y a une différence
notable entre les extension REAL*8 (qui provient des extensions VAX)
et les pointeurs.
Sans blague ?
D'ailleurs, trouve-moi un compilo Fortran77 qui
suivent toutes ces extensions VAX (en particulier le REAL*16 et le
COMPLEX*32).
J'ai parlé de REAL*16 ? Non.
REAL*8 est une extension "raisonnable" car présente sur à peu près tous les
compilateurs sérieux (sinon tous). REAL*16 ne l'est pas, par contre, donc
effectivement je ne la recommenderais.
Là encore, non. Il y a de très bonnes raisons d'avoir une
mémoire _statique_ en FORTRAN.
Ni plus ni moins que dans d'autres langages. Et il y a parfois de
très bonnes raisons d'avoir besoin de mémoire dynamique.
Mais tu es un abruti ! Je t'ai dit plus haut qu'il était tout à fait
possible d'utiliser en Fortran77 de la mémoire dynamque,
En restant purement dans le monde F77 évidemment que non.
mais qu'il
y avait une raison pour laquelle la mémoire était gérée de façon
statique dans une unité de programme.
Il n'y a pas de raison "universelle". Juste une absence de fonctionnalité
pour le faire en F77.
La plupart des codes n'ont pas besoin d'avoir une reproductibilité au
bit près, mais à la précision numérique de la machine *et* des
calculs près. On se fiche bien d'avoir tous les bits identiques à
partir du moment où l'on sait que la précision en sortie des calculs
n'est que de 3 digits (par exemple) et que le reste n'est pas
significatif.
Toi, tu n'as jamais fait d'analyse numérique. Tu n'as jamais bossé
sur des codes faisant des calculs longs et fastidieux où la plus
petite dérive est problématique parce que source de divergence !
On se contrefiche de la précision des calculs ! On veut simplement
que si l'on obtient un résultat A sur une machine, on obtienne le
même résultat A sur une autre.
Ah bien sûr si on se contrefiche de la précision des calculs, dans ce cas
évidemment :-) !!!
Et tu me demandes si j'ai fait de l'analyse numérique :-) ?
Ton souci est donc d'avoir toujours le même résultat, même si il est faux.
Ca peut être une préoccupation intéressante dans certains cas, mais en
général on est surtout intéressé de savoir quelle est la précision du
résultat...
Ah, si tu le dis. F77 était fait pour faire des calculs.
J'ai personnellement utilisé du F77 à la norme avec une
gestion _dynamique_ de la mémoire sans _jamais_ n'avoir
utiliser un pointeur Cray ou un autre truc hors norme.
Strictement dans le monde fermé F77 je ne vois pas comment c'est
possible.
Tu n'as _jamais_ appelé de bibliothèques externes ?
Ecrites en quoi ? En C j'imagine ?
Question: l'interfaçage C/Fortran est-il décrit dans la norme F77 ?
On peut toujours ensuite trouver des moyens plus ou moins détournés
pour avoir une gestion plus ou moins dynamique de la mémoire, mais en
général liés à un environnement particulier et qui posent
potentiellement autant de problèmes de portabilité qu'une extension à
la norme.
Non.
L'interfaçage C/Fortran n'a jamais posé aucun problème de portabilité ?
On joue à celui qui a la plus grosse ? Moi aussi...
On ne dirait pourtant pas.
Je n'étais pas en érection...
Et tu démontres quoi ici, à part que gfortran ne se plante pas tout
le temps ?
Que tu as tout faux parce que ton _code_ est faux.
Tu es un rigolo, toi... Je post un code qui ne compile pas, tu postes un
autre code qui compile: je ne vois pas en quoi cela démontre que mon code
est faux. Tu as un problème de logique.
Ben voyons... Mon exemple ne titille absolument pas la norme, la
syntaxe est *légale* jusqu'à preuve du contraire, et gfortran se
plante dessus. Point.
Non. Ton appel est foireux
Prouve-le. J'ai cherché un peu, et je n'ai rien trouvé qui dise que le
premier argument de transfer() ne peut pas être un scalaire ou une
constante.
et c'est pour cela que gfortran râle.
En l'occurence gfortran ne dit pas que la syntaxe est illégale, mais que la
fonctionnalité "n'est pas implémentée" :-)
Et je maintiens que le fait que les autres compilent est plus dû au
hasard qu'à autre chose.
La hasard à 10 contre 1, hein...
Quant à ne pas connaître Fortran, tu repasseras.
Tu m'excuseras, mais se dire spécialiste et ne pas voir l'erreur
dans ton appel de fonction, cela me fait doucement rigoler.
Quelle erreur ? J'attends encore...
Explique-moi donc plutôt ce qui n'est pas légal dans le code que j'ai
posté. Et mieux, explique-moi donc pourquoi ça finit en "compiler
internal error" même à supposer qu'il ne serait pas légal.
Je n'ai pas dit que gfortran n'avait pas des problèmes. Je prétends
simplement qu'il est normal qu'il râle sur tes deux exemples. Tu
prétends que transfer() ne fonctionne pas,
Non, je prétends que transfer(-1.0,0) ne fonctionne pas, nuance.
je t'ai démontré le
contraire.
Tu as juste montré un exemple de transfer() qui fonctionne. Et alors ?
En tant que grand spécialiste du Fortran, tu devrais voir
immédiatement pourquoi ton transfer() à toi ne fonctionne pas.
J'attends une explication.
Sinon, va reprendre des cours, il n'y a que cela. Le deuxième cas
est un peu plus complexe puisqu'il s'agit d'une histoire de gestion
de la mémoire. J'ai failli être bin, mais je n'ai franchement pas
envie d'aider un type comme toi. Va poser ta question sur fcf.
Les mecs qui disent "je t'expliquerais bien mais j'ai pas le temps", en
général ils ne savent pas :-)
Et d'ailleurs sur le deuxième exemple gfortran ne râle pas, il se plante
carrément. Mais tu as sûrement une explication que tu ne veux pas donner à
cela aussi :-)
"JKB" a écrit dans le message de news:Un code bien
écrit se satisfait de la norme, ce qui permet de le porter aisément.
Des codes comme ça, figure-toi que j'en ai eu dans les pattes (entre
autre écrit par des ingés de Thomson depuis les années 60). Les
types suivaient _scrupuleusement_ la norme (quitte à utiliser un
préprocesseur) pour n'avoir _aucun_ problème de portabilité. Et
crois-moi (ou ne me crois pasn je m'en fous royalement), lorsque
j'ai pris leur code et que je l'ai compilé sur mon alpha ev6 avec
g77 (gcc3), je n'ai eu _aucun_ problème et le seul truc que j'ai dû
rajouter au makefile, c'est l'option de compilation pour compiler du
FORTRAN-IV. Tout autre code est mal écrit.
Position complètement intégriste.
Avec certaines extensions bien choisies, la portabilité n'a jamais été un
réel problème non plus. En ce sens que quelque soit la plate-forme on trouve
toujours un compilo qui gère les extensions (et accessoirement l'expérience
montre que les bons compilos sont aussi ceux qui gèrent le plus
d'extensions).
Et bien tiens toi bien, on y trouve des extensions à la norme: les
pointeurs Cray, la syntaxe REAL*8, notamment. Ce qui ne pose aucun
quand cela se fait dans un cadre bien défini et contrôlé.
Bien contrôlé, cela veut dire sur sa petite machine ou pour des
applications à environnement maîtrisé.
A environnement maîtrisé en effet. Mais néanmoins sur de très nombreuses
plateformes (donc pas sur sa petite machine). Et l'environnement maîtrisé
est la règle en milieu industriel.
Et il y a une différence
notable entre les extension REAL*8 (qui provient des extensions VAX)
et les pointeurs.
Sans blague ?D'ailleurs, trouve-moi un compilo Fortran77 qui
suivent toutes ces extensions VAX (en particulier le REAL*16 et le
COMPLEX*32).
J'ai parlé de REAL*16 ? Non.
REAL*8 est une extension "raisonnable" car présente sur à peu près tous les
compilateurs sérieux (sinon tous). REAL*16 ne l'est pas, par contre, donc
effectivement je ne la recommenderais.
Là encore, non. Il y a de très bonnes raisons d'avoir une
mémoire _statique_ en FORTRAN.
Ni plus ni moins que dans d'autres langages. Et il y a parfois de
très bonnes raisons d'avoir besoin de mémoire dynamique.
Mais tu es un abruti ! Je t'ai dit plus haut qu'il était tout à fait
possible d'utiliser en Fortran77 de la mémoire dynamque,
En restant purement dans le monde F77 évidemment que non.
mais qu'il
y avait une raison pour laquelle la mémoire était gérée de façon
statique dans une unité de programme.
Il n'y a pas de raison "universelle". Juste une absence de fonctionnalité
pour le faire en F77.
La plupart des codes n'ont pas besoin d'avoir une reproductibilité au
bit près, mais à la précision numérique de la machine *et* des
calculs près. On se fiche bien d'avoir tous les bits identiques à
partir du moment où l'on sait que la précision en sortie des calculs
n'est que de 3 digits (par exemple) et que le reste n'est pas
significatif.
Toi, tu n'as jamais fait d'analyse numérique. Tu n'as jamais bossé
sur des codes faisant des calculs longs et fastidieux où la plus
petite dérive est problématique parce que source de divergence !
On se contrefiche de la précision des calculs ! On veut simplement
que si l'on obtient un résultat A sur une machine, on obtienne le
même résultat A sur une autre.
Ah bien sûr si on se contrefiche de la précision des calculs, dans ce cas
évidemment :-) !!!
Et tu me demandes si j'ai fait de l'analyse numérique :-) ?
Ton souci est donc d'avoir toujours le même résultat, même si il est faux.
Ca peut être une préoccupation intéressante dans certains cas, mais en
général on est surtout intéressé de savoir quelle est la précision du
résultat...
Ah, si tu le dis. F77 était fait pour faire des calculs.
J'ai personnellement utilisé du F77 à la norme avec une
gestion _dynamique_ de la mémoire sans _jamais_ n'avoir
utiliser un pointeur Cray ou un autre truc hors norme.
Strictement dans le monde fermé F77 je ne vois pas comment c'est
possible.
Tu n'as _jamais_ appelé de bibliothèques externes ?
Ecrites en quoi ? En C j'imagine ?
Question: l'interfaçage C/Fortran est-il décrit dans la norme F77 ?
On peut toujours ensuite trouver des moyens plus ou moins détournés
pour avoir une gestion plus ou moins dynamique de la mémoire, mais en
général liés à un environnement particulier et qui posent
potentiellement autant de problèmes de portabilité qu'une extension à
la norme.
Non.
L'interfaçage C/Fortran n'a jamais posé aucun problème de portabilité ?
On joue à celui qui a la plus grosse ? Moi aussi...
On ne dirait pourtant pas.
Je n'étais pas en érection...
Et tu démontres quoi ici, à part que gfortran ne se plante pas tout
le temps ?
Que tu as tout faux parce que ton _code_ est faux.
Tu es un rigolo, toi... Je post un code qui ne compile pas, tu postes un
autre code qui compile: je ne vois pas en quoi cela démontre que mon code
est faux. Tu as un problème de logique.
Ben voyons... Mon exemple ne titille absolument pas la norme, la
syntaxe est *légale* jusqu'à preuve du contraire, et gfortran se
plante dessus. Point.
Non. Ton appel est foireux
Prouve-le. J'ai cherché un peu, et je n'ai rien trouvé qui dise que le
premier argument de transfer() ne peut pas être un scalaire ou une
constante.
et c'est pour cela que gfortran râle.
En l'occurence gfortran ne dit pas que la syntaxe est illégale, mais que la
fonctionnalité "n'est pas implémentée" :-)
Et je maintiens que le fait que les autres compilent est plus dû au
hasard qu'à autre chose.
La hasard à 10 contre 1, hein...
Quant à ne pas connaître Fortran, tu repasseras.
Tu m'excuseras, mais se dire spécialiste et ne pas voir l'erreur
dans ton appel de fonction, cela me fait doucement rigoler.
Quelle erreur ? J'attends encore...
Explique-moi donc plutôt ce qui n'est pas légal dans le code que j'ai
posté. Et mieux, explique-moi donc pourquoi ça finit en "compiler
internal error" même à supposer qu'il ne serait pas légal.
Je n'ai pas dit que gfortran n'avait pas des problèmes. Je prétends
simplement qu'il est normal qu'il râle sur tes deux exemples. Tu
prétends que transfer() ne fonctionne pas,
Non, je prétends que transfer(-1.0,0) ne fonctionne pas, nuance.
je t'ai démontré le
contraire.
Tu as juste montré un exemple de transfer() qui fonctionne. Et alors ?
En tant que grand spécialiste du Fortran, tu devrais voir
immédiatement pourquoi ton transfer() à toi ne fonctionne pas.
J'attends une explication.
Sinon, va reprendre des cours, il n'y a que cela. Le deuxième cas
est un peu plus complexe puisqu'il s'agit d'une histoire de gestion
de la mémoire. J'ai failli être bin, mais je n'ai franchement pas
envie d'aider un type comme toi. Va poser ta question sur fcf.
Les mecs qui disent "je t'expliquerais bien mais j'ai pas le temps", en
général ils ne savent pas :-)
Et d'ailleurs sur le deuxième exemple gfortran ne râle pas, il se plante
carrément. Mais tu as sûrement une explication que tu ne veux pas donner à
cela aussi :-)
Position complètement intégriste.
Non.
Avec certaines extensions bien choisies, la portabilité n'a jamais
été un réel problème non plus. En ce sens que quelque soit la
plate-forme on trouve toujours un compilo qui gère les extensions
(et accessoirement l'expérience montre que les bons compilos sont
aussi ceux qui gèrent le plus d'extensions).
Celle-là, je l'encadre.
A environnement maîtrisé en effet. Mais néanmoins sur de très
nombreuses plateformes (donc pas sur sa petite machine). Et
l'environnement maîtrisé est la règle en milieu industriel.
Je l'encadre aussi. Dis, sur quels genres de projets bosses-tu ?
J'espère que ce n'est pas sur des centrales nucléaires !
J'ai parlé de REAL*16 ? Non.
Non, c'est moi qui en ait parlé. Parce que si tu utilises les
extensions, il faut pouvoir les utiliser _toutes_.
REAL*8 est une extension "raisonnable" car présente sur à peu près
tous les compilateurs sérieux (sinon tous). REAL*16 ne l'est pas,
par contre, donc effectivement je ne la recommenderais.
Tu nous prends pour des cons, oui ou non !? Si tu prends le
Mircosoft Fortran 5.x, il connaît les extensions VAX, mais pas
REAL*16. Est-ce que tu imagines les implications de ce truc ?
Il n'y a pas de raison "universelle". Juste une absence de
fonctionnalité pour le faire en F77.
Non. Les types qui ont sorti la norme F77 avait une bonne raison de
ne pas mettre de mémoire gérée dynamiquement et pour une bonne
raison (qui peut se discuter). Générer des exécutables _statiques_
de petite taille sur des capacités mémoires réduites en évitant les
problèmes de débordement mémoire et de dépassement de pile (parce
que cela joue aussi sur la récursivité). Et ce choix était
_délibéré_.
Lorsque les capacités mémoire ont augmenté, le problème
ne s'est plus posé de la même façon.
Toi, tu n'as jamais fait d'analyse numérique. Tu n'as jamais bossé
sur des codes faisant des calculs longs et fastidieux où la plus
petite dérive est problématique parce que source de divergence !
On se contrefiche de la précision des calculs ! On veut simplement
que si l'on obtient un résultat A sur une machine, on obtienne le
même résultat A sur une autre.
Ah bien sûr si on se contrefiche de la précision des calculs, dans
ce cas évidemment :-) !!!
Est-ce que j'ai écrit une seule fois ça ?
Lorsque tu écris des
algorithmes de traitement du signal qui mettent trois jours à
décoder 40 ms de signal, tu espères que la démodulation sera la même
sur ton alpha que sur les Sun de Thomson et les PC de l'université
de Nantes. Non seulement tu veux un résultat aussi fidèle que
possible, pais tu veux _aussi_ qu'il soit reproductible !
Ton souci est donc d'avoir toujours le même résultat, même si il est
faux.
Non.Ca peut être une préoccupation intéressante dans certains cas, mais
en général on est surtout intéressé de savoir quelle est la
précision du résultat...
Mékilékon. Je te parle de résultat à partir d'un algorithme
_débuggué_, ce qui veut dire qu'on a déjà intégré la précision du
résultat.
Je cherche seulement à te dire que 10000 lignes de F77 à
la norme sur une architecture doivent donner la même chose sur une
autre architecture (voire avec un autre compilo dans le cas idéal,
mais il ne faut pas rêver !).
Ecrites en quoi ? En C j'imagine ?
Et alors ?Question: l'interfaçage C/Fortran est-il décrit dans la norme F77 ?
Tu viens de prouver que tu ne connais pas le C non plus. Mes
routines sont écrites en C et utilisent des #define pour qu'elles
fonctionnent avec g77 (et tous les compilo f77 rencontrés sous Unix)
_et_ VisualFortran sous Windows...
Non.
L'interfaçage C/Fortran n'a jamais posé aucun problème de
portabilité ?
Non, pas si on fait les choses proprement.
Tu es un rigolo, toi... Je post un code qui ne compile pas, tu
postes un autre code qui compile: je ne vois pas en quoi cela
démontre que mon code est faux. Tu as un problème de logique.
Non. Tu gueules sur gfortran qui d'après toi est buggué parce que la
fonction transfert ne permet pas d'avoir un scalaire comme premier
argument.
Je te prouve le contraire et tu n'es pas content.
Imbécile, va !
Prouve-le. J'ai cherché un peu, et je n'ai rien trouvé qui dise que
le premier argument de transfer() ne peut pas être un scalaire ou une
constante.
Il ne s'agit pas d'un problème de constante, m*rde, mais d'un
problème de type par défaut.
Le hasard pas au sens variable aléatoire. C'est dû au hasard parce
que les autres compilos font un truc dans ton dos, regarde bien ton
code qui fait gueuler gfortran !
Quelle erreur ? J'attends encore...
Juste une histoire de transtypage dans ton dos, ce qui prouve que tu
n'as rien compris à l'appel de fonctions en Fortran (et encore moins
aux types par défaut).
Non, je prétends que transfer(-1.0,0) ne fonctionne pas, nuance.
Et moi je prétends que si, exemple à l'appui.
Allez, je suis bon
prince. Essaye transfer(-1D0,0). Avec mon gfortran, ça marche.
Maintenant, à toi de comprendre pourquoi.
Tu as juste montré un exemple de transfer() qui fonctionne. Et alors
?
Alors, à partir du moment où tu écris un truc en titillant la norme,
tu ne peux pas venir te plaindre.
J'attends une explication.
RTFM.
Les mecs qui disent "je t'expliquerais bien mais j'ai pas le temps",
en général ils ne savent pas :-)
Et d'ailleurs sur le deuxième exemple gfortran ne râle pas, il se
plante carrément. Mais tu as sûrement une explication que tu ne veux
pas donner à cela aussi :-)
1. Je n'insulte pas les gens.
2. Depuis que j'écris des bouts de code soit depuis plus de 25 ans,
j'ai en tout et pour tout trouvé trois bugs dans des compilateurs (un
sur le Turbo Basic de Borland version 1.0, un dans gcc-2.7.2.3 sur
des passages de paramètres sur sparc32 avec les registres rotatifs des
processeurs RISC lors d'un dépassement de pile, et un
troisième avec gcc-3.0 sur des problèmes d'allocation de tableaux
statiques). Tous les autres problèmes étaient dans mon code.
3. Lorsque j'ai un tel comportement, je commence par chercher
pourquoi j'ai ce comportement avant de gueuler comme un goret.
Fin de la discussion.
Position complètement intégriste.
Non.
Avec certaines extensions bien choisies, la portabilité n'a jamais
été un réel problème non plus. En ce sens que quelque soit la
plate-forme on trouve toujours un compilo qui gère les extensions
(et accessoirement l'expérience montre que les bons compilos sont
aussi ceux qui gèrent le plus d'extensions).
Celle-là, je l'encadre.
A environnement maîtrisé en effet. Mais néanmoins sur de très
nombreuses plateformes (donc pas sur sa petite machine). Et
l'environnement maîtrisé est la règle en milieu industriel.
Je l'encadre aussi. Dis, sur quels genres de projets bosses-tu ?
J'espère que ce n'est pas sur des centrales nucléaires !
J'ai parlé de REAL*16 ? Non.
Non, c'est moi qui en ait parlé. Parce que si tu utilises les
extensions, il faut pouvoir les utiliser _toutes_.
REAL*8 est une extension "raisonnable" car présente sur à peu près
tous les compilateurs sérieux (sinon tous). REAL*16 ne l'est pas,
par contre, donc effectivement je ne la recommenderais.
Tu nous prends pour des cons, oui ou non !? Si tu prends le
Mircosoft Fortran 5.x, il connaît les extensions VAX, mais pas
REAL*16. Est-ce que tu imagines les implications de ce truc ?
Il n'y a pas de raison "universelle". Juste une absence de
fonctionnalité pour le faire en F77.
Non. Les types qui ont sorti la norme F77 avait une bonne raison de
ne pas mettre de mémoire gérée dynamiquement et pour une bonne
raison (qui peut se discuter). Générer des exécutables _statiques_
de petite taille sur des capacités mémoires réduites en évitant les
problèmes de débordement mémoire et de dépassement de pile (parce
que cela joue aussi sur la récursivité). Et ce choix était
_délibéré_.
Lorsque les capacités mémoire ont augmenté, le problème
ne s'est plus posé de la même façon.
Toi, tu n'as jamais fait d'analyse numérique. Tu n'as jamais bossé
sur des codes faisant des calculs longs et fastidieux où la plus
petite dérive est problématique parce que source de divergence !
On se contrefiche de la précision des calculs ! On veut simplement
que si l'on obtient un résultat A sur une machine, on obtienne le
même résultat A sur une autre.
Ah bien sûr si on se contrefiche de la précision des calculs, dans
ce cas évidemment :-) !!!
Est-ce que j'ai écrit une seule fois ça ?
Lorsque tu écris des
algorithmes de traitement du signal qui mettent trois jours à
décoder 40 ms de signal, tu espères que la démodulation sera la même
sur ton alpha que sur les Sun de Thomson et les PC de l'université
de Nantes. Non seulement tu veux un résultat aussi fidèle que
possible, pais tu veux _aussi_ qu'il soit reproductible !
Ton souci est donc d'avoir toujours le même résultat, même si il est
faux.
Non.
Ca peut être une préoccupation intéressante dans certains cas, mais
en général on est surtout intéressé de savoir quelle est la
précision du résultat...
Mékilékon. Je te parle de résultat à partir d'un algorithme
_débuggué_, ce qui veut dire qu'on a déjà intégré la précision du
résultat.
Je cherche seulement à te dire que 10000 lignes de F77 à
la norme sur une architecture doivent donner la même chose sur une
autre architecture (voire avec un autre compilo dans le cas idéal,
mais il ne faut pas rêver !).
Ecrites en quoi ? En C j'imagine ?
Et alors ?
Question: l'interfaçage C/Fortran est-il décrit dans la norme F77 ?
Tu viens de prouver que tu ne connais pas le C non plus. Mes
routines sont écrites en C et utilisent des #define pour qu'elles
fonctionnent avec g77 (et tous les compilo f77 rencontrés sous Unix)
_et_ VisualFortran sous Windows...
Non.
L'interfaçage C/Fortran n'a jamais posé aucun problème de
portabilité ?
Non, pas si on fait les choses proprement.
Tu es un rigolo, toi... Je post un code qui ne compile pas, tu
postes un autre code qui compile: je ne vois pas en quoi cela
démontre que mon code est faux. Tu as un problème de logique.
Non. Tu gueules sur gfortran qui d'après toi est buggué parce que la
fonction transfert ne permet pas d'avoir un scalaire comme premier
argument.
Je te prouve le contraire et tu n'es pas content.
Imbécile, va !
Prouve-le. J'ai cherché un peu, et je n'ai rien trouvé qui dise que
le premier argument de transfer() ne peut pas être un scalaire ou une
constante.
Il ne s'agit pas d'un problème de constante, m*rde, mais d'un
problème de type par défaut.
Le hasard pas au sens variable aléatoire. C'est dû au hasard parce
que les autres compilos font un truc dans ton dos, regarde bien ton
code qui fait gueuler gfortran !
Quelle erreur ? J'attends encore...
Juste une histoire de transtypage dans ton dos, ce qui prouve que tu
n'as rien compris à l'appel de fonctions en Fortran (et encore moins
aux types par défaut).
Non, je prétends que transfer(-1.0,0) ne fonctionne pas, nuance.
Et moi je prétends que si, exemple à l'appui.
Allez, je suis bon
prince. Essaye transfer(-1D0,0). Avec mon gfortran, ça marche.
Maintenant, à toi de comprendre pourquoi.
Tu as juste montré un exemple de transfer() qui fonctionne. Et alors
?
Alors, à partir du moment où tu écris un truc en titillant la norme,
tu ne peux pas venir te plaindre.
J'attends une explication.
RTFM.
Les mecs qui disent "je t'expliquerais bien mais j'ai pas le temps",
en général ils ne savent pas :-)
Et d'ailleurs sur le deuxième exemple gfortran ne râle pas, il se
plante carrément. Mais tu as sûrement une explication que tu ne veux
pas donner à cela aussi :-)
1. Je n'insulte pas les gens.
2. Depuis que j'écris des bouts de code soit depuis plus de 25 ans,
j'ai en tout et pour tout trouvé trois bugs dans des compilateurs (un
sur le Turbo Basic de Borland version 1.0, un dans gcc-2.7.2.3 sur
des passages de paramètres sur sparc32 avec les registres rotatifs des
processeurs RISC lors d'un dépassement de pile, et un
troisième avec gcc-3.0 sur des problèmes d'allocation de tableaux
statiques). Tous les autres problèmes étaient dans mon code.
3. Lorsque j'ai un tel comportement, je commence par chercher
pourquoi j'ai ce comportement avant de gueuler comme un goret.
Fin de la discussion.
Position complètement intégriste.
Non.
Avec certaines extensions bien choisies, la portabilité n'a jamais
été un réel problème non plus. En ce sens que quelque soit la
plate-forme on trouve toujours un compilo qui gère les extensions
(et accessoirement l'expérience montre que les bons compilos sont
aussi ceux qui gèrent le plus d'extensions).
Celle-là, je l'encadre.
A environnement maîtrisé en effet. Mais néanmoins sur de très
nombreuses plateformes (donc pas sur sa petite machine). Et
l'environnement maîtrisé est la règle en milieu industriel.
Je l'encadre aussi. Dis, sur quels genres de projets bosses-tu ?
J'espère que ce n'est pas sur des centrales nucléaires !
J'ai parlé de REAL*16 ? Non.
Non, c'est moi qui en ait parlé. Parce que si tu utilises les
extensions, il faut pouvoir les utiliser _toutes_.
REAL*8 est une extension "raisonnable" car présente sur à peu près
tous les compilateurs sérieux (sinon tous). REAL*16 ne l'est pas,
par contre, donc effectivement je ne la recommenderais.
Tu nous prends pour des cons, oui ou non !? Si tu prends le
Mircosoft Fortran 5.x, il connaît les extensions VAX, mais pas
REAL*16. Est-ce que tu imagines les implications de ce truc ?
Il n'y a pas de raison "universelle". Juste une absence de
fonctionnalité pour le faire en F77.
Non. Les types qui ont sorti la norme F77 avait une bonne raison de
ne pas mettre de mémoire gérée dynamiquement et pour une bonne
raison (qui peut se discuter). Générer des exécutables _statiques_
de petite taille sur des capacités mémoires réduites en évitant les
problèmes de débordement mémoire et de dépassement de pile (parce
que cela joue aussi sur la récursivité). Et ce choix était
_délibéré_.
Lorsque les capacités mémoire ont augmenté, le problème
ne s'est plus posé de la même façon.
Toi, tu n'as jamais fait d'analyse numérique. Tu n'as jamais bossé
sur des codes faisant des calculs longs et fastidieux où la plus
petite dérive est problématique parce que source de divergence !
On se contrefiche de la précision des calculs ! On veut simplement
que si l'on obtient un résultat A sur une machine, on obtienne le
même résultat A sur une autre.
Ah bien sûr si on se contrefiche de la précision des calculs, dans
ce cas évidemment :-) !!!
Est-ce que j'ai écrit une seule fois ça ?
Lorsque tu écris des
algorithmes de traitement du signal qui mettent trois jours à
décoder 40 ms de signal, tu espères que la démodulation sera la même
sur ton alpha que sur les Sun de Thomson et les PC de l'université
de Nantes. Non seulement tu veux un résultat aussi fidèle que
possible, pais tu veux _aussi_ qu'il soit reproductible !
Ton souci est donc d'avoir toujours le même résultat, même si il est
faux.
Non.Ca peut être une préoccupation intéressante dans certains cas, mais
en général on est surtout intéressé de savoir quelle est la
précision du résultat...
Mékilékon. Je te parle de résultat à partir d'un algorithme
_débuggué_, ce qui veut dire qu'on a déjà intégré la précision du
résultat.
Je cherche seulement à te dire que 10000 lignes de F77 à
la norme sur une architecture doivent donner la même chose sur une
autre architecture (voire avec un autre compilo dans le cas idéal,
mais il ne faut pas rêver !).
Ecrites en quoi ? En C j'imagine ?
Et alors ?Question: l'interfaçage C/Fortran est-il décrit dans la norme F77 ?
Tu viens de prouver que tu ne connais pas le C non plus. Mes
routines sont écrites en C et utilisent des #define pour qu'elles
fonctionnent avec g77 (et tous les compilo f77 rencontrés sous Unix)
_et_ VisualFortran sous Windows...
Non.
L'interfaçage C/Fortran n'a jamais posé aucun problème de
portabilité ?
Non, pas si on fait les choses proprement.
Tu es un rigolo, toi... Je post un code qui ne compile pas, tu
postes un autre code qui compile: je ne vois pas en quoi cela
démontre que mon code est faux. Tu as un problème de logique.
Non. Tu gueules sur gfortran qui d'après toi est buggué parce que la
fonction transfert ne permet pas d'avoir un scalaire comme premier
argument.
Je te prouve le contraire et tu n'es pas content.
Imbécile, va !
Prouve-le. J'ai cherché un peu, et je n'ai rien trouvé qui dise que
le premier argument de transfer() ne peut pas être un scalaire ou une
constante.
Il ne s'agit pas d'un problème de constante, m*rde, mais d'un
problème de type par défaut.
Le hasard pas au sens variable aléatoire. C'est dû au hasard parce
que les autres compilos font un truc dans ton dos, regarde bien ton
code qui fait gueuler gfortran !
Quelle erreur ? J'attends encore...
Juste une histoire de transtypage dans ton dos, ce qui prouve que tu
n'as rien compris à l'appel de fonctions en Fortran (et encore moins
aux types par défaut).
Non, je prétends que transfer(-1.0,0) ne fonctionne pas, nuance.
Et moi je prétends que si, exemple à l'appui.
Allez, je suis bon
prince. Essaye transfer(-1D0,0). Avec mon gfortran, ça marche.
Maintenant, à toi de comprendre pourquoi.
Tu as juste montré un exemple de transfer() qui fonctionne. Et alors
?
Alors, à partir du moment où tu écris un truc en titillant la norme,
tu ne peux pas venir te plaindre.
J'attends une explication.
RTFM.
Les mecs qui disent "je t'expliquerais bien mais j'ai pas le temps",
en général ils ne savent pas :-)
Et d'ailleurs sur le deuxième exemple gfortran ne râle pas, il se
plante carrément. Mais tu as sûrement une explication que tu ne veux
pas donner à cela aussi :-)
1. Je n'insulte pas les gens.
2. Depuis que j'écris des bouts de code soit depuis plus de 25 ans,
j'ai en tout et pour tout trouvé trois bugs dans des compilateurs (un
sur le Turbo Basic de Borland version 1.0, un dans gcc-2.7.2.3 sur
des passages de paramètres sur sparc32 avec les registres rotatifs des
processeurs RISC lors d'un dépassement de pile, et un
troisième avec gcc-3.0 sur des problèmes d'allocation de tableaux
statiques). Tous les autres problèmes étaient dans mon code.
3. Lorsque j'ai un tel comportement, je commence par chercher
pourquoi j'ai ce comportement avant de gueuler comme un goret.
Fin de la discussion.
Alors, pour le premier fichier, la compilation plante sur
l'instruction:
des% trbuff(14) = transfer(-1.0, 0)
Le compilo se plaint que le premier argument de transfer() est un
scalaire. Or dans ce que je comprends de la norme, rien ne dit que ce
premier argument ne puisse pas être un scalaire. Et sur une dizaine
de compilos, seul gfortran se plante dessus.
On est en train de titiller la norme. Ton problème est gros comme
une maison, mais je te laisse chercher.
is the following statement legal in f90 ?
integer :: foo
foo = transfer(-1.0,0)
(the issue is about the first argument that is a constant scalar)
Alors, pour le premier fichier, la compilation plante sur
l'instruction:
des% trbuff(14) = transfer(-1.0, 0)
Le compilo se plaint que le premier argument de transfer() est un
scalaire. Or dans ce que je comprends de la norme, rien ne dit que ce
premier argument ne puisse pas être un scalaire. Et sur une dizaine
de compilos, seul gfortran se plante dessus.
On est en train de titiller la norme. Ton problème est gros comme
une maison, mais je te laisse chercher.
is the following statement legal in f90 ?
integer :: foo
foo = transfer(-1.0,0)
(the issue is about the first argument that is a constant scalar)
Alors, pour le premier fichier, la compilation plante sur
l'instruction:
des% trbuff(14) = transfer(-1.0, 0)
Le compilo se plaint que le premier argument de transfer() est un
scalaire. Or dans ce que je comprends de la norme, rien ne dit que ce
premier argument ne puisse pas être un scalaire. Et sur une dizaine
de compilos, seul gfortran se plante dessus.
On est en train de titiller la norme. Ton problème est gros comme
une maison, mais je te laisse chercher.
is the following statement legal in f90 ?
integer :: foo
foo = transfer(-1.0,0)
(the issue is about the first argument that is a constant scalar)
Alors, par acquis de conscience j'ai posé la question dans
comp.lang.fortran, et j'ai obtenu deux réponses
Alors, par acquis de conscience j'ai posé la question dans
comp.lang.fortran, et j'ai obtenu deux réponses
Alors, par acquis de conscience j'ai posé la question dans
comp.lang.fortran, et j'ai obtenu deux réponses
