Macs are *nix. Going from macs, to SGI to linux to all sorts of *nix systems is just as simple as starting from linux.

GNU runs just fine on macs, thus so does fortran. I use it all the time. I specifically found it easier to write portable simd and gpu code in fortran on mac. I could do it on linux boxes but it ported poorly because everyones compile environment was different.

yes there are loads and loads of linux web site, that will offer you solutions that don't work on you configuration or maybe one of them will. But you don't know that till you try and find the problem has morphed requiring debugging all over again. Likewise when you come back to code years later and find it just won't build anymore on your new computer or the new distro you migrated to. I've wasted tonnes of time on that road. It's why I use macs whenever I can.

I've been very very productive on Linux too, but that was when I was in large groups that enforced a common setup and had a sys admin to handle all the networking and commonality of configurations. In such a situation, yeah you can get answers quickly from your neighbor for your linux mysteries. Outside that I've always found it slows me down and I spend too much time on the getting-it-to-work, and keeping it patched and not enough on the physics. If all you are doing is working in a company where you are writing c code and eating your own dog food (libraries) then perhaps that's fine. But if you are reading research papers and want to try out all sorts of different home built systems it gets hard to work on your own, this is where linux's diversity and obscurity kills it. There's problems with macs too I fully admit. That's where virtual box saves your ass. Sure you can fire up virtual box on linux too, but the one OS you can't get on the linux VM is the mac and all it's application goodness , easy updates and hardware compatibility.

As far as the tangential educational benefits from ones day trips into linux comment sites trying to figure something out, well macs are *nix too. So to the extent that things behave the same the linux sites are useful for mac-heads as well. And I suppose you know that mac osx compilers do cover multiple architectures including ARM.

Whether mathematic matters to you or not depends on what line of physics you are in. for mathematically oriented genres sometimes its a lingua franca. Others use matlab (especially in things like remote sensing or accoustics where coupling to hardware and rapid interface building is useful). Some just grind numbers on clusters and write their own codes for that. Just depends. Personally I don't use it anymore.

So yes, seriously!
I've never found it useful in the slightest to run the Linux just because the big cluster I use runs linux. The networking environment on the cluster is always so distinct that its as different as the Mac anyhow. It's easier just to Xwindows into the cluster or one of the develpment nodes set up like the cluster and just use that.

Perhaps the best part is that if you can't figure something out on your mac, you can ask someone. With Linux you have to find someone with a setup just like yours, and if you google it you will find a proliferation of solutions none of which work for your rig.

Devo could easily have been describing linux when they wrote: What you got is freedom of choice [But] what you want is freedom from choice.

Standards are good. Macs don't really box you in they just reduce the proliferation of options of how to do something. It's not unlike how C++ is super poweful but python's simplicity lets you focus on the creative part more.

if you are doing serious heavy lifting on a GPU then you have graduated beyond a laptop anyhow. Simply having a GPU however is great for development and interoperability, if you are doing GPU work. No need for big iron in your little laptop. Its a waste silence, battery, heat, weight and size.

First I'd just get a mac. the Unix environment is highly standard (yes the sysadmin is very different, but she's not going to be doing that). It will cost a bit more than a dell but not much and it will likely have a high resale value. What you get is highly worry free compared to running your own linux box which is worth it, especially for the circumstances you describe. There's also lots of distro and libs for the mac and the compilers are top notch. Ive noticed Many mathlibs are already compiled for SIMD or GPU on macs probably because of how standardized the environment and hardware is-- i certainly don't find it as inconsistent as Linux platforms.

And if you do absolutely have to run Windows or Linux at some point well it turns out that Virtual Box create a more standard environment for those platforms than any hardware platform.

And if you just can't abide the mac OS then wipe it an install Linux. That's effectively what Linus did (he now uses a Chomebook Pixel but just because it's well made-- he still uses Linux). Or get a companion for it: raspberry Pi 2 for $50. the new ones come with Free Windows 10, Free Wolfram/Mathematica and it's easy to run X-windows or a remote screen from the mac to the Rapsberry pi.

As we saw with Dolly the Sheep, a clone is not an exact copy of an animal. It may contain nearly all the DNA information but first this DNA may be damaged (if nothing else, shortened telomers) and second it may not contain all the exact matrilineal content. This include both midocondral DNA as well as an epigenetic controls the mother's cell line places on its DNA. It is possible someone could have take those into account and made the best possible approximation to those. But it also possible that the crucial developmental characteristics of a quarter horse are in those missing elements.

Thus at a minimum the Quarter horse association could reasonably say that unless the donor cell line is from a quarter horse, it is not a quarter horse. It would also be someone reasonable to say that even with that precaution the shortened telomers mean this is a genetically damaged quarter horse and they want to exclude it from breeding with genetically healthy quarter horses.

Try not thinking about this next time you tick the "organ donor" checkbox on your driver's license form.

I never thought there would be a time the phrase "I wouldn't fuck her with your dick" might stand a chance of being modded insightful.

Fortran Compilers I have worked with caught these at compile time not run time. C compilers, at least some of them miss this. In C including the headers.h files is what is supposed to catch this, but if you declare the header wrong, or don't use a header but instead use extern then this doesn't get caught.

google f2py and you will find lots of tutorials. but it not complicated and after you customize the paths and options for your particular compiler then compiling from within python takes just a couple lines, and then you import the result.

almost any compiler can work in principle. I used open source compilers because 1) I wanted to be able to share my work 2) numpy and scipy come distributed that way. but I know from the mail lists people used commerical compilers as well such as compaq visual fortran. I did once use a commercially curated distribution called enthought. Since I didn't want to have to maintain two compliers I made the choice to use the one I used to compile scipy or numpy, which is almost any, but on your specific computer you have probably installed numpy in either binary or source form using some package manager, or if its a mac the one that came with the computer. f2py is in most package managers. By using the package manager route this also simplified getting the paths to libraries set up correctly as well-- but that's just a general property of package managers not specific to f2py.

I've done this now using different package managers and different compilers and the only problems I've had were in the package managers themselves when dependencies got broken, but again that's the packagemanager woe no specific to f2py.

You can do all the sorcery right from scipy itself. since scipy and numpy can use fortran order arrays, you can pass things in and out directly without thinking about them as objects. they just show up as fortran arrays.

google F2Py. You will find lots of tutorials. Most significantly you may notice that f2py is integral to scipy.

as for compiling fortran on the fly, this can be done through scipy as well or you can use system calls. Exactly how you do it depends on what compiler your system used.

Sure but why the hell allow look alike syntaxes and allow simple typos to compile? Most other languages have avoided that so it's quite peculiar to C.

For me, the example I gave is an example that comes up when you read some one elses dialect of C-coding. I take great pains never to use one of those forms. I'll split it over two lines of type definition and array declaration if I need to. Running array declaration and two diffierent type declarations on a single line is confusing to anyone who has a different c- dialect. This also comes up when your just a little sleepy. A missed parens can mean hours of run time debugging.

My larger issue however was the title of my post. It's not that these things can't be read correctly, it's that typos that convert one into the other both compile.

this is where the inexpert C-programmer ends up writing crap code. It's not the experts I worry about. the subject of this is why Crap code proliferates. C is just a great way to do that.

I have discovered late in the game that Python + Fortran is almost magical. It's better than Python C++. when you are needing fast algorithms or code close the metal (SIMD or GPU) then fortran provides all the muscle that you need without all the baggage of c++. You offload complex class and memory allocation to the python.

The amazing thing I really like about the fortran is that it compiles so damn fast compared to C++ that it's easy to write a python program that generates optimized fortran and then compile it at run time rather than simply pre-compile a C++ library to include. The fortran is cleaner looking and its hard to make typos. The limits and ugly bits of fortran are pretty much not a concern since those chores can be offloaded to the python.

gahh. I just typoed my example!!! oops.
int (*foo)[20];
int *foo[20];

But I bet that error would even compile!

C itself has so many pitfalls. For the best tour review the underhanded C contest. "features" like automatic concatenation of consecutive character strings means that if you leave out a comma in a list, the adjacent array element entries are concatenated rather than throwing a syntax error. That list will now not match the declared array size (one short, so there's a null or random pointer in the last element) but the compiler allows initialization listed mismatched to the array sizes. Character strings have to be declared one longer than the initialization string length (room for the unstated \0) but are accepted by the compiler if they don't giving an unbounded string length.

it's mind boggling to realize that
int (*int)[20];
int *int[20];
are different things.

the number of different ways an array argument in a function can be written makes code hard to grasp: is it a pointer, an array, a reference? many work alike but then fail in different ways.

The most common of all pitfalls and hard to read codes are the in-line initializations that pop up in function arguments and what not. this leads to classic blunder of writing = when you mean ==.

Perhaps the most insane thing is that If you declare an external function with the wrong prototype then any mismatch in the argument count leaves or takes something off the stack. Holy cow..... I mean what the hell? Why would any language ever ever ever let you leave a orphan argument on the stack, or worse pop one off that was not yours? This is very useful for the underhanded C folks however.

While I know there's little love for fortran, it's worth noting that none of those things is even possible in Fortran, so its an existence proof that there's not any necessity for those to exist and that it doesn't limit the power of the language to remove them. It's very fair to say that no simple typo will ever compile in fortran (yes very complicated offsetting typos can compile).