In my mind, I equate "passing by reference" as passing the memory location of the first element to a function, and passing by value as making a copy, then passing that to the function/subroutine.
If the array being passed consumes almost all of the memory of the machine (very common in scientific computing), then making a copy first would leave you dead in the water.
Please, go back and look at my previous comments. I said "consistent" and not "exact". Now, you have called "bullshit" on me, and so it's time to go to source to back up what I have said. I choose "Modern Fortran Explained" by Metcalf, Reid, and Cohen, specifically Chapter 11 which covers the Fortran implementation of IEEE 754-1985 and IEC (ISO) 559. These guys are associated with the likes CERN and NAG.
IEEE arithmetic has ~nothing~ to do with Fortran per se (see my comment above) -- the Fortran standard demands its implementation. You accusing Fortran users of "being stuck in its ways" is blatantly stupid -- as any language that implements IEEE is guilty of the same crime. A "type" is more than its storage -- a type is the union of its storage with its operators. In Fortran, (to the best of my knowledge) using IEEE arithmetic alters these operators, including essentials like +-*/ and including essentials like sqrt. (Aside: Note that GROMACS started life being a fast enough, precise enough, sqrt operator project due to its role in computing Euclidean distance. In my experience, it did not work out so well, unless a thermostat kept bleeding out the aberrant velocity build up.)
Since the FP types use finite width, no doubt there are still FP errors, as this is not exact arithmetic. Fortran does not fix this, and I never said it did. Again, I said IEEE, which Fortran implements, makes it "consistent."
Different CPUs have different performance characteristics for various operations. Where there is a preferred/faster order of operations, then the compiler can reorganize so that things run faster. This can be good and/or bad. From Metcalf, "Some computers perform division by inverting the denominator and then multiplying by the numerator. The additional round-off that this involves means that such an implementation does not conform with the IEEE standard."
My thoughts above were about ~different types~ of machines doing billions of operations in whichever way they please, thus leading to different results in long running simulations. It is possible to demand IEEE arithmetic and exception handling, in which case "Execution may be slowed on some processors by the support of some features."
Now, let's talk about your fuzzy thinking. You said "There is no physics based reason for insisting that a truncation error should always be the same": do you expect bitwise arithmetic to be different, provided that the same sequence of instructions with the same starting values? You also think/thought that scientists don't post their trajectories or snapshots. I'm actually starting to wonder about you.
This subthread had little to do with Fortran, except as an innocent bystander that has IEEE support. This had to do with the suggestion of the usefulness of consistent orders of operations that can lead to consistent results between different types of machines.
What you say is inconsistent with decades of work of my colleagues on the subject, and my own observations. (I have a few dozen papers in JACS and J Phys Chem)
a) The problem is that seemingly "stable" systems develop instability over time due to integration and floating point error. You mention chaos, and this is it -- sensitivity to minute change in initial conditions and accumulated tiny effects. But it's not randomness -- this chaos could be reproduced using well-defined arithmetic. b) people do publish trajectories in supporting information or on their web sites, perhaps only snapshots, but how would you ever get from snapshot to snapshot to prove that you had implemented their methodology correctly, or to demonstrate the reproduction of a phenomenon: perhaps interesting, perhaps evolution to a corner case thus demonstrating a theoretical/methodological error? If you are working on different processors/compilers, it's almost impossible to reproduce.
I agree that people tend not to do IEEE arithmetic with classical MD. Please go back a comment or two and read it this time to confirm it for yourself. I was trying to give an example of a case where exactly reproducible results could be useful in the field of MD, particularly in development.
I remain convinced that IEEE arithmetic is useful in many important (but perhaps comparatively rare) circumstances, and that FP error will always be a lingering issue that rears its ugly head. Fortran implements ways of dealing with it consistently.
First of all, please note that I said ~exact~ reproduction. You keep going back to some ensemble average as being "good enough." Secondly, what you are saying about the scientific topic is inconsistent with numerical analysis of MD simulations using e.g., the velocity Verlet algorithm.
Please see: http://chris.sweet.name/docs/s... for an example of floating point error in action (special attention to the single vs. double precision differences that appear once the simulation has run a long time.) One of the early criticisms of GROMACS (the fastest MD!) was that it ran really great in single precision. But everyone else (AMBER, CHARM, and homegrown codes) were criticizing it for floating point round-off error leading to trajectories that flew apart because they developed too much momentum.
These don't "appear" if you have slapped a thermostat on the simulation (NVT ensemble). This is why you should always run an equilibration run and then switch to constant energy (NVE ensemble) when you are generating results that you wish to report. Otherwise, you are sweeping all sorts of problems due to floating point arithmetic and integration error under the rug.
But I suppose that you are doing classical MD -- trying to draw some inference on e.g. protein dynamics based on interactions between van der Waals spheres. These simulations tend to be "right" half of the time -- they are wrong until you've cooked the force field enough to match the definitive experiment. Constraints go a long way in keeping the system together.
So, in this environment, where the primary interest is generating "ooh's and ahh's" from movies of dancing proteins as quickly as possible, you are probably safe using single point arithmetic and hiding all of your sins with a nice, strongly coupled thermostat and barostat.
just to correct my comment: computed goto was ~usually~ done with integer arithmetic. I made my comment based on your use of X, Y, and Z which I am sure were declared using IMPLICIT DOUBLE PRECISION (A-H,O-Z):-)
Most people learned Fortran in a class intended to teach scientific programming. I have never, ever, ever seen a course catalog that lists CS 201 FORTRAN PROGRAMMING. It has always been about getting the scientific result -- it just so happens that Fortran has been pretty good at it and actually pretty simple -- and so it has often times been used.
That being said, C almost killed Fortran (77) because they waited so damned long to bring out Fortran 90. People were sick and tired of waiting for dynamic memory allocation and free form input, and so many people who were past entry-level programming started jumping to C (...which I would never relish to teach to a beginner who has no solid interest in computer programming).
Missing out on what, the wonders and simplicity of using git? (/sarcasm)
Many Fortran programmers are academics, and academics are often times (not always) concerned with one-off programs that demonstrate a computer-based solution to a novel phenomenon. Often times, the investigator works alone. Once that is done, sometimes the code is never visited again. In these cases, anything more than VMS-style versioning is total overkill.
I agree that version control is important and often ignored. But this is not specific to Fortran -- but rather that the fact that version control adds overhead both in using and learning -- and academics are often putting all of their efforts into the science.
No, you are wrong by being terribly incomplete. People who use Fortran (or any language for that matter) are interested in getting the correct answer, in the fastest reasonable time, with the shortest amount of developer work (and perhaps cost matters). In the scientific domain, Fortran remains competitive. The precise cost function that balances these considerations depends on many variables and is precisely why we have so many languages today.
No loss. IF should expect to be supplied by a boolean:.TRUE. or.FALSE. Also, how dangerous is it to assume that one would ever get 0.000000 condition what with round off error? It may have been useful shorthand when faced with punching out the more explicit if else if's but those days are computer science archaeology.
I think it is unfair to say that a group of unpaid developers actively took a role in killing anything. You have to remember the times -- GNU was barely off the ground with gcc, let alone g77. (In fact, g95 filled the role of gfortran) Today, I would argue that gfortran has SAVED Fortran, by making it accessible to low-budget ($0) developers who's salaries are probably less than a Power7/xlc/xlf/essl stack.
You're right Fortran won't protect you from ~inconsistent~ round off errors, but the lower performance IEEE data types that Fortran (natively) and a few other languages implement through heavy add-ons will.
May I suggest that you consider applications in domains outside of your own. If you have any interest in computer forensics, e.g. why did the ODE screw up and crash the lander, why did the airplane software malfunction, nuclear reactor meltdown, etc. etc. then you might start to care much more deeply about being able to reproduce the precise values that existed during the course of the evaluation. (As well as consistently handling the numerical exceptions that tend to arise. I'm no expert in IEEE, please consult a reference.)
In your own domain -- Molecular Dynamics -- you might wish to send your initial configuration (position and velocities) to a colleague/reviewer who is using a different compiler. He could, in principle, reproduce your trajectory exactly. (Otherwise, there is a compiler error.)
You might not wish to routinely run with IEEE arithmetic, because it is slower. But for those folks who need it, it is right there at their fingertips and totally and completely (ANSI/ISO) standard.
1) Modern Fortran is not all uppercase 2) Modern Fortran does not have to start on column 7 3) Modern Fortran has dynamic memory allocation 4) Modern Fortran can use the same types as C (maximizes interoperability), hence can be called where C might be called 5) Modern Fortran has an objects, polymorphism, etc. 6) Modern Fortran has (a limited form of) pointers 7) Modern Fortran has concise array/vector/matrix operations 8) Modern Fortran has dynamically allocatable, multidimensional arrays that can be indexed starting with any integer 8) Modern Fortran supports the complex type without higgery-jiggery 9) Modern Fortran doesn't *need *pointers *in *all *the *places *that &C does, pass by reference is the norm 10) Modern Fortran is blazingly fast and designed for sciene....
Some folks still write in Fortran 77, and the tired tales of woe that are bound to come from a language specification that is many decades old.
But, that code/style still works, and who am I to judge how you want to get your work done?
I am wondering if the rift between Debian GNU/Linux and the GFDL could ever be healed. For example, the Emacs documentation (GFDL) is deemed to be outside the bounds of the Debian Social Contract.
This leads one to have to enable the non-free repositories in order to install the Emacs documentation, unless one has to resort to compiling from source.
What steps must Debian take in order to come into compliance with the FSF? Would the FSF modify the GFDL to remove the objections of the Debian community? I wish that the FSF could come to complete terms with a community who actually acknowledges their lineage.
To be fair, I think the guy should be removed from office. The problem as I see it is that Congress demands that every appointee be removed if they make any mistake, no matter how minor or (as in this case) serious.
I agree that there are (probably) grounds to remove him from office.
But there is absolutely no evidence to show that Congress does not demand that every appointee be removed: if Congress demanded it, then the impeachment/removal process would kick in, until the appointee in question was in fact removed from office.
Everyone makes mistakes. Congress has to weigh whether it is worth the time to remove someone for the crimes (real or imagined). I think that the bar is pretty high, given that a) Congress has a lot of things on its plate and b) the replacement may not be much better.
A president cannot do what Obama is doing in a "Constitutional Republic with checks-and-balances". Selective enforcement of law IS the checks and balances.
An executive who fails to faithfully live by/uphold the laws might give Congress the motivation to remove him from office.
This is the ultimate check and balance upon the executive. I'm pretty sure that every president has failed to uphold the laws of the land--but Congress has to-date failed to see sufficient cause to carry through with it.
I make a living supporting and extending the software that I write. Big house, three cars in a three car garage. I'm a proud FSF supporter.
The good news is that you can use my software, even if you don't have the money to pay for it. But if you think that you can take my code, doctor it up, and give/sell it to someone else without sharing -- think again.
Slashdot Mirror
In my mind, I equate "passing by reference" as passing the memory location of the first element to a function, and passing by value as making a copy, then passing that to the function/subroutine.
If the array being passed consumes almost all of the memory of the machine (very common in scientific computing), then making a copy first would leave you dead in the water.
I agree. I posted elsewhere on this thread saying essentially the same thing, especially about dynamic memory allocation and free-form input.
Please, go back and look at my previous comments. I said "consistent" and not "exact". Now, you have called "bullshit" on me, and so it's time to go to source to back up what I have said. I choose "Modern Fortran Explained" by Metcalf, Reid, and Cohen, specifically Chapter 11 which covers the Fortran implementation of IEEE 754-1985 and IEC (ISO) 559. These guys are associated with the likes CERN and NAG.
IEEE arithmetic has ~nothing~ to do with Fortran per se (see my comment above) -- the Fortran standard demands its implementation. You accusing Fortran users of "being stuck in its ways" is blatantly stupid -- as any language that implements IEEE is guilty of the same crime. A "type" is more than its storage -- a type is the union of its storage with its operators. In Fortran, (to the best of my knowledge) using IEEE arithmetic alters these operators, including essentials like +-*/ and including essentials like sqrt. (Aside: Note that GROMACS started life being a fast enough, precise enough, sqrt operator project due to its role in computing Euclidean distance. In my experience, it did not work out so well, unless a thermostat kept bleeding out the aberrant velocity build up.)
Since the FP types use finite width, no doubt there are still FP errors, as this is not exact arithmetic. Fortran does not fix this, and I never said it did. Again, I said IEEE, which Fortran implements, makes it "consistent."
Different CPUs have different performance characteristics for various operations. Where there is a preferred/faster order of operations, then the compiler can reorganize so that things run faster. This can be good and/or bad. From Metcalf, "Some computers perform division by inverting the denominator and then multiplying by the numerator. The additional round-off that this involves means that such an implementation does not conform with the IEEE standard."
My thoughts above were about ~different types~ of machines doing billions of operations in whichever way they please, thus leading to different results in long running simulations. It is possible to demand IEEE arithmetic and exception handling, in which case "Execution may be slowed on some processors by the support of some features."
Now, let's talk about your fuzzy thinking. You said "There is no physics based reason for insisting that a truncation error should always be the same": do you expect bitwise arithmetic to be different, provided that the same sequence of instructions with the same starting values? You also think/thought that scientists don't post their trajectories or snapshots. I'm actually starting to wonder about you.
This subthread had little to do with Fortran, except as an innocent bystander that has IEEE support. This had to do with the suggestion of the usefulness of consistent orders of operations that can lead to consistent results between different types of machines.
What you say is inconsistent with decades of work of my colleagues on the subject, and my own observations. (I have a few dozen papers in JACS and J Phys Chem)
a) The problem is that seemingly "stable" systems develop instability over time due to integration and floating point error. You mention chaos, and this is it -- sensitivity to minute change in initial conditions and accumulated tiny effects. But it's not randomness -- this chaos could be reproduced using well-defined arithmetic.
b) people do publish trajectories in supporting information or on their web sites, perhaps only snapshots, but how would you ever get from snapshot to snapshot to prove that you had implemented their methodology correctly, or to demonstrate the reproduction of a phenomenon: perhaps interesting, perhaps evolution to a corner case thus demonstrating a theoretical/methodological error? If you are working on different processors/compilers, it's almost impossible to reproduce.
I agree that people tend not to do IEEE arithmetic with classical MD. Please go back a comment or two and read it this time to confirm it for yourself. I was trying to give an example of a case where exactly reproducible results could be useful in the field of MD, particularly in development.
I remain convinced that IEEE arithmetic is useful in many important (but perhaps comparatively rare) circumstances, and that FP error will always be a lingering issue that rears its ugly head. Fortran implements ways of dealing with it consistently.
First of all, please note that I said ~exact~ reproduction. You keep going back to some ensemble average as being "good enough." Secondly, what you are saying about the scientific topic is inconsistent with numerical analysis of MD simulations using e.g., the velocity Verlet algorithm.
Please see: http://chris.sweet.name/docs/s... for an example of floating point error in action (special attention to the single vs. double precision differences that appear once the simulation has run a long time.) One of the early criticisms of GROMACS (the fastest MD!) was that it ran really great in single precision. But everyone else (AMBER, CHARM, and homegrown codes) were criticizing it for floating point round-off error leading to trajectories that flew apart because they developed too much momentum.
These don't "appear" if you have slapped a thermostat on the simulation (NVT ensemble). This is why you should always run an equilibration run and then switch to constant energy (NVE ensemble) when you are generating results that you wish to report. Otherwise, you are sweeping all sorts of problems due to floating point arithmetic and integration error under the rug.
But I suppose that you are doing classical MD -- trying to draw some inference on e.g. protein dynamics based on interactions between van der Waals spheres. These simulations tend to be "right" half of the time -- they are wrong until you've cooked the force field enough to match the definitive experiment. Constraints go a long way in keeping the system together.
So, in this environment, where the primary interest is generating "ooh's and ahh's" from movies of dancing proteins as quickly as possible, you are probably safe using single point arithmetic and hiding all of your sins with a nice, strongly coupled thermostat and barostat.
I am embarrassed. You cited my alma mater's course catalog and proved me wrong (a decade ahead of my time, though) :-)
just to correct my comment: computed goto was ~usually~ done with integer arithmetic. I made my comment based on your use of X, Y, and Z which I am sure were declared using IMPLICIT DOUBLE PRECISION (A-H,O-Z) :-)
Most people learned Fortran in a class intended to teach scientific programming. I have never, ever, ever seen a course catalog that lists CS 201 FORTRAN PROGRAMMING. It has always been about getting the scientific result -- it just so happens that Fortran has been pretty good at it and actually pretty simple -- and so it has often times been used.
That being said, C almost killed Fortran (77) because they waited so damned long to bring out Fortran 90. People were sick and tired of waiting for dynamic memory allocation and free form input, and so many people who were past entry-level programming started jumping to C (...which I would never relish to teach to a beginner who has no solid interest in computer programming).
...and i would like to see statistics on how many git branches are created, yet never merged back in.
Missing out on what, the wonders and simplicity of using git? (/sarcasm)
Many Fortran programmers are academics, and academics are often times (not always) concerned with one-off programs that demonstrate a computer-based solution to a novel phenomenon. Often times, the investigator works alone. Once that is done, sometimes the code is never visited again. In these cases, anything more than VMS-style versioning is total overkill.
I agree that version control is important and often ignored. But this is not specific to Fortran -- but rather that the fact that version control adds overhead both in using and learning -- and academics are often putting all of their efforts into the science.
No, you are wrong by being terribly incomplete. People who use Fortran (or any language for that matter) are interested in getting the correct answer, in the fastest reasonable time, with the shortest amount of developer work (and perhaps cost matters). In the scientific domain, Fortran remains competitive. The precise cost function that balances these considerations depends on many variables and is precisely why we have so many languages today.
No loss. IF should expect to be supplied by a boolean: .TRUE. or .FALSE. Also, how dangerous is it to assume that one would ever get 0.000000 condition what with round off error? It may have been useful shorthand when faced with punching out the more explicit if else if's but those days are computer science archaeology.
I think it is unfair to say that a group of unpaid developers actively took a role in killing anything. You have to remember the times -- GNU was barely off the ground with gcc, let alone g77. (In fact, g95 filled the role of gfortran) Today, I would argue that gfortran has SAVED Fortran, by making it accessible to low-budget ($0) developers who's salaries are probably less than a Power7/xlc/xlf/essl stack.
You're right Fortran won't protect you from ~inconsistent~ round off errors, but the lower performance IEEE data types that Fortran (natively) and a few other languages implement through heavy add-ons will.
May I suggest that you consider applications in domains outside of your own. If you have any interest in computer forensics, e.g. why did the ODE screw up and crash the lander, why did the airplane software malfunction, nuclear reactor meltdown, etc. etc. then you might start to care much more deeply about being able to reproduce the precise values that existed during the course of the evaluation. (As well as consistently handling the numerical exceptions that tend to arise. I'm no expert in IEEE, please consult a reference.)
In your own domain -- Molecular Dynamics -- you might wish to send your initial configuration (position and velocities) to a colleague/reviewer who is using a different compiler. He could, in principle, reproduce your trajectory exactly. (Otherwise, there is a compiler error.)
You might not wish to routinely run with IEEE arithmetic, because it is slower. But for those folks who need it, it is right there at their fingertips and totally and completely (ANSI/ISO) standard.
1) Modern Fortran is not all uppercase ....
2) Modern Fortran does not have to start on column 7
3) Modern Fortran has dynamic memory allocation
4) Modern Fortran can use the same types as C (maximizes interoperability), hence can be called where C might be called
5) Modern Fortran has an objects, polymorphism, etc.
6) Modern Fortran has (a limited form of) pointers
7) Modern Fortran has concise array/vector/matrix operations
8) Modern Fortran has dynamically allocatable, multidimensional arrays that can be indexed starting with any integer
8) Modern Fortran supports the complex type without higgery-jiggery
9) Modern Fortran doesn't *need *pointers *in *all *the *places *that &C does, pass by reference is the norm
10) Modern Fortran is blazingly fast and designed for sciene
Some folks still write in Fortran 77, and the tired tales of woe that are bound to come from a language specification that is many decades old.
But, that code/style still works, and who am I to judge how you want to get your work done?
Every time I read this headline, my eyes exchange the numbers...
These are pretty much all I need to execute and publish computer-based science.
Dear Dr. Stallman,
I am wondering if the rift between Debian GNU/Linux and the GFDL could ever be healed. For example, the Emacs documentation (GFDL) is deemed to be outside the bounds of the Debian Social Contract.
This leads one to have to enable the non-free repositories in order to install the Emacs documentation, unless one has to resort to compiling from source.
What steps must Debian take in order to come into compliance with the FSF? Would the FSF modify the GFDL to remove the objections of the Debian community? I wish that the FSF could come to complete terms with a community who actually acknowledges their lineage.
Thanks,
An Anonymous FSF Associate Member
"does not demand" should be "demands"
To be fair, I think the guy should be removed from office. The problem as I see it is that Congress demands that every appointee be removed if they make any mistake, no matter how minor or (as in this case) serious.
I agree that there are (probably) grounds to remove him from office.
But there is absolutely no evidence to show that Congress does not demand that every appointee be removed: if Congress demanded it, then the impeachment/removal process would kick in, until the appointee in question was in fact removed from office.
Everyone makes mistakes. Congress has to weigh whether it is worth the time to remove someone for the crimes (real or imagined). I think that the bar is pretty high, given that a) Congress has a lot of things on its plate and b) the replacement may not be much better.
Personally, my humble opinion is that the Executive Branch does have the authority to not enforce a law.
I agree with everything you say but this. There is such a thing as a writ of mandamus.
https://en.wikipedia.org/wiki/...
A president cannot do what Obama is doing in a "Constitutional Republic with checks-and-balances".
Selective enforcement of law IS the checks and balances.
An executive who fails to faithfully live by/uphold the laws might give Congress the motivation to remove him from office.
This is the ultimate check and balance upon the executive. I'm pretty sure that every president has failed to uphold the laws of the land--but Congress has to-date failed to see sufficient cause to carry through with it.
Have you even heard of FDR?
Can you explain why Linux (GPL) has a such a comparatively large developer community relative to the BSDs?
I make a living supporting and extending the software that I write. Big house, three cars in a three car garage. I'm a proud FSF supporter.
The good news is that you can use my software, even if you don't have the money to pay for it. But if you think that you can take my code, doctor it up, and give/sell it to someone else without sharing -- think again.