tomr_stargazer
Joined 12 years ago
Joined 12 years ago
"Manual hy-
phenation was not advised, either."
https://acoup.blog/2022/06/17/collections-total-generalship-...
In particular, the concept of 'drill' gets a lot of attention:
"Fundamentally the principle behind using drill to build synchronized discipline is that the way to get a whole lot of humans to act effectively in concert together is to force them to practice doing exactly the things they’ll be asked to do on the battlefield a lot until the motions are practically second nature. Indeed, the ideal in developing this kind of drill was often to ingrain the actions the soldiers were to perform so deeply that in the midst of the terror of battle when they couldn’t even really think straight those soldiers would fall back on simply mechanically performing the actions they were trained to perform. That in turn creates an important element of predictability: an individual soldier does not need to be checking their action or position against the others around them as much because they’ve done this very maneuver with these very fellows and so already know where everyone is going to be.... The context that drill tends to emerge in (this is an idea invented more than once) tends to give it a highly regimented, fairly brutal character. For instance in early modern Europe, the structure of drill for gunpowder armies was conditioned by elite snobbery: European officer-aristocrats (in many cases the direct continuation of the medieval aristocracy) had an extremely poor view of their common soldiers (drawn from the peasantry). Assuming they lacked any natural valor, harsh drill was settled upon as a solution to make the actions of battle merely mechanical, to reduce the man to a machine."
> My goal is to make Professor Powell 12’s solvers as accessible as possible to scientists, engineers, and algorithm researchers. I am not particularly in favor of or against any language. I hope that everyone can easily use Powell’s solvers in her/his favorite languages.
> The first implementation of PRIMA is in modern Fortran simply because Powell’s implementation was in Fortran 77. Using Fortran, I can systematically verify the bit-to-bit faithfulness of the modernized implementation (not only “faithful up to an epsilon”). In addition, the intrinsic support for matrix-vector calculations is a strong advantage when developing reference implementations (or templates) of numerical solvers — most numerical algorithms are combinations of such calculations anyway.
> The major motivation for developing the modern Fortran version is to provide a reference for the implementation in other languages, namely Python, MATLAB, C++, Julia, and R. A reference implementation must be structured, modularized, readable, understandable, and extendable. The original Fortran 77 code is a true masterpiece, but it is not proper at all for being used as a reference implementation. You do not want to use a spaghetti-style codebase with 244 GOTOs as a reference, or your implementation will be of the same style.
> Putting it more straightforwardly, I implemented the modern-Fortran version of PRIMA in order to develop versions that are entirely Fortran-free 3.
> Coming back to the point, I fully understand why the SciPy community has “little appetite for taking on more Fortran code”. The reputation of Fortran has been damaged over the years. I do not agree with the damaged reputation, and I feel sorry for those who do not have a chance to know (or refuse to know) modern Fortran due to this false reputation, but I do not blame them. It is the responsibility of the Fortran community to re-establish the reputation. I do not regard it as a bully to request non-Fortran implementations. It is not a question of surrendering or not.
> I do consider myself a member of the Fortran community. Taking my share of the aforementioned responsibilty, I will try to promote the usage of modern Fortran via the PRIMA project. There is nothing more convincing than a successful real-life project.
> For the inclusion of PRIMA in SciPy, I will keep communicating with both the SciPy and the Fortran community (e.g., those on this discourse), trying to find the best route. As pointed out by others, f2c is not an option due to its incapability of handling modern Fortran. Official C++ and Python implementations are being planned, but they will not be delivered in the near future. The most probable and practical solution, as suggested here and under the other thread, is to wrap the modern Fortran implementation of PRIMA using iso_c_bindings + ctypes or similar facilities. I hope the SciPy maintainers will accept this solution.
You've argued that the Sun's rate of motion across the sky should have a constant magnitude (under the assumption of an Earth analog with a perfectly circular orbit but still 23.5 degree obliquity). It's not clear to me why this should be the case; on the celestial sphere, I would have an easier time accepting that the Sun should have a constant "horizontal" (i.e., in the sense of right ascension) motion due to the Earth's constant orbital speed, and that the Sun's "vertical" (i.e. declination) motion should be purely sinusoidal: greatest at the equinoxes, zero at the solstices. Have I misunderstood something here?
As an extreme case, imagine a tidally locked planet on a circular orbit of 1 AU with 23.5 degree obliquity. An observer sitting on the equator would see the sun moving on a line overhead, crossing the zenith back and forth, with no figure 8 -- right?