On why you need to specify precision in numeric literals: https://randomascii.wordpress.com/2012/06/26/doubles-are-not-floats-so-dont-compare-them/ … A cool modern Fortran feature is defining a numeric 'kind' then tagging all your numeric literals with it. integer, parameter :: WP = 8 real (kind=WP) :: x x = 0.1_WP is not the same as x = 0.1
-
Show this thread
-
Of course, all the cool kids use iso_fortran_env instead of specifying double-precision with a (somewhat) random integer via: use, intrinsic :: iso_fortran_env, only: WP => REAL64
1 reply 0 retweets 1 likeShow this thread -
Why this is cool: change WP from pointing at REAL64 to REAL32 and you switch all reals defined as kind=WP from double to single precision, no hidden compiler flags necessary. Or go the other way to quad precision with REAL128.
1 reply 0 retweets 1 likeShow this thread -
IMO, it's better to do this in-source than with a compiler flag because nobody working with Fortran ever documents or backs up their build environment or compiler flags. It doesn't exist unless it's in a source file. Future generations will thank you.
1 reply 0 retweets 5 likesShow this thread -
Fortran programmers learn very quickly that 1 is not the same as 1.0. Python2 programmers did too until Python3 'fixed' things to become more Perlish. And at least Perl told you up front that math was done in double precision
1 reply 2 retweets 8 likesShow this thread -
Replying to @jhripley
Python2 gives 1 / 2 = 0 (Fortran-ish) vs 0.5 for Python3 (Perl-ish). I typically specify real numbers when I want a real result, but that's out of habit by being burned early by Fortran. It's also why I'm religious about 'from __future__ import division'
1 reply 0 retweets 1 like
Of course, python3 does have // for when you really want integer division. The behaviour you'd want by default depends on what domain you work in I guess.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.