Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fortran.io – a Fortran Web Framework

fortran.io

Post reply on HN
Print view View original

201–210 of 255 posts

Re: Fortran.io – a Fortran Web Framework

#201

Post by tomrod »

7thaccount wrote: post #162
jofer wrote: post #109

Earlier quoted context omitted.

Numpy actually explicitly doesn't need fortran. It will use some fortran lapack libraries for optimizations if they're present, but it doesn't depend on fortran at all. Scipy is a different story. The need for a fortran compiler was a big part of the original rationale for the divide of numpy and scipy when they replaced numeric. Numpy was meant to be the lighweight/core version of things, and scipy was the full-fled…

I'd like to write some Fortran, but there are a few libraries I need like database access and I'd be set.

I wonder if we can use a Python wrapper for that?

Re: Fortran.io – a Fortran Web Framework

#202

Post by 7thaccount »

tomrod wrote: post #201
7thaccount wrote: post #162

Earlier quoted context omitted.

I'd like to write some Fortran, but there are a few libraries I need like database access and I'd be set.

I wonder if we can use a Python wrapper for that?

At that point I'd just use Python.

Re: Fortran.io – a Fortran Web Framework

#203

Post by palae »

the_af wrote: post #196
myrryr wrote: post #182

Earlier quoted context omitted.

Well, things like... you have 2, 2 dimensional arrays of the same size, A and B. You want to make a new array, where each cell in A is added to the same cell in B. So you are going to do a loop over 2 variables, right? in FORTRAN the code is... C = A + B in Julia the code is C = A .+ B

Interesting. Does it result in a compile error if you try arrays of different sizes? (If it's just a run time error, I don't see how it's different to implementing this with operator overloading in any language that supports it).

Sure, if you try with non conformable arrays, gfortran for example would tell you something like this:

  Different shape for array assignment at (1) on dimension 1
Note that a scalar is conformable to any array, so that A = 2 for example would work for any shape of A, and would fill A with 2's.

Re: Fortran.io – a Fortran Web Framework

#204

Post by biswaroop »

tobmlt wrote: post #191
jofer wrote: post #109

Earlier quoted context omitted.

Numpy actually explicitly doesn't need fortran. It will use some fortran lapack libraries for optimizations if they're present, but it doesn't depend on fortran at all. Scipy is a different story. The need for a fortran compiler was a big part of the original rationale for the divide of numpy and scipy when they replaced numeric. Numpy was meant to be the lighweight/core version of things, and scipy was the full-fled…

Yep! Seconding what you said: A key aspect is that it’s very easy to write fast matrix math in Fortran. Vectorized operations are downright pythonic! I was amazed how much more complex things were when moving to C++ (as opposed to C or C written in cpp files which you’ll find in academia and some books). Of course, that ease is a hazard when all the modern (i.e. fun) sci-eng software development is in C++. Do not gro…

> Do not grow complacent in school, ye numerical methods researchers! Write your stuff in C++. The job market awaits.

Could you elaborate a bit on this? I think I know what you mean, but I'd like to hear more if you don't mind.

Re: Fortran.io – a Fortran Web Framework

#205

Post by [deleted] »

School-Cotton wrote: post #197
favorited wrote: post #194

Earlier quoted context omitted.

I think that's pretty disingenuous. The fact that my cousins and myself are around doesn't mean that my grandparents aren't dead. Latin is certainly a dead language, even though it has living descendants.

Is 1900-AD English "a dead language" because nobody who spoke it natively is still alive? What about 1800, 1700, or 1000? What year did English die and if it did indeed die, what are we speaking now? The reasons for considering English circa 1000 and English circa 2020 to be "different stages of the same language" but Latin and French to be "different languages" are an arbitrary cultural distinction not rooted in sci…

[deleted]

Re: Fortran.io – a Fortran Web Framework

#206

Post by djannzjkzxn »

School-Cotton wrote: post #197
favorited wrote: post #194

Earlier quoted context omitted.

I think that's pretty disingenuous. The fact that my cousins and myself are around doesn't mean that my grandparents aren't dead. Latin is certainly a dead language, even though it has living descendants.

Is 1900-AD English "a dead language" because nobody who spoke it natively is still alive? What about 1800, 1700, or 1000? What year did English die and if it did indeed die, what are we speaking now? The reasons for considering English circa 1000 and English circa 2020 to be "different stages of the same language" but Latin and French to be "different languages" are an arbitrary cultural distinction not rooted in sci…

The natural conclusion to this argument is that everyone on earth is speaking the same language, because they all descended from the Mitochondrial Eve’s utterances 150000 years ago.

Re: Fortran.io – a Fortran Web Framework

#207

Post by edgyquant »

jofer wrote: post #109
throwaway2048 wrote: post #61

Earlier quoted context omitted.

Lots of number crunching code relies on Fortran libraries even today. Install numpy, it will pull in Fortran stuff.

Numpy actually explicitly doesn't need fortran. It will use some fortran lapack libraries for optimizations if they're present, but it doesn't depend on fortran at all. Scipy is a different story. The need for a fortran compiler was a big part of the original rationale for the divide of numpy and scipy when they replaced numeric. Numpy was meant to be the lighweight/core version of things, and scipy was the full-fled…

Thanks this makes sense. Somebody on Reddit told me the other day that numpy used Fortran and I couldn't figure out where they'd come up with that.

Re: Fortran.io – a Fortran Web Framework

#208

Post by brlewis »

umvi wrote: post #72
yingw787 wrote: post #43

Google has this thing called “Testing on the Toilet” where they post factoids about Google’s codebase and best practices. I read one and it said FORTRAN is a highly secure language (or there haven’t been any security vulnerabilities found in the language in a while). Devil’s advocate for not writing FORTRAN off completely at first sight.

Or is it just because no one uses it? Apple used to run ad campaigns about how Macs were immune to viruses and therefore highly secure. Turns out enough people just weren't using Mac, and viruses started popping up once it went mainstream.

Apple once advertised "Macs don't get PC viruses", which was true, but misleading. Microsoft often claimed that the reason there weren't Mac viruses was that it wasn't as attractive a target. They kept this trope going for a very long time. They said it for so long, that one would think hackers would want to crack MacOS just as a way to stand out from the crowd. The higher prevalence of PCs was never enough to explain the orders of magnitude difference in exploits. Macs may not have been super secure, but they were way more secure than Windows, and the number of viruses for Macs never "popped" in any way comparable.

Re: Fortran.io – a Fortran Web Framework

#209

Post by mindcrime »

runawaybottle wrote: post #12

Let’s all get good at Fortran in 3 Months get those cushy six figure salary jobs those Fortran devs make building web apps, sounds easy enough.

I'm not jumping on the Fortran bandwagon until it runs natively in the browser! No transpiling to Javascript or any other such monkey business either. I want a browser with true Fortran support built right in.

Re: Fortran.io – a Fortran Web Framework

#210

Post by nwallin »

myrryr wrote: post #182
badrequest wrote: post #166

Earlier quoted context omitted.

What are the highlights of Fortran's array manipulation capabilities?

Well, things like... you have 2, 2 dimensional arrays of the same size, A and B. You want to make a new array, where each cell in A is added to the same cell in B. So you are going to do a loop over 2 variables, right? in FORTRAN the code is... C = A + B in Julia the code is C = A .+ B

That's what I do in C++ with Eigen or boost::ublas or any other library. Operator overloading is not a feature limited to Fortran.

Fortran gets its performance from prohibition of aliasing, which is something that C++ admits as per the standard. One could enable the same performance boosts with a non standard compiler flag, but this breaks a lot of codebases, including the Linux kernel AFAIK.

Aliasing is a pox upon the world. There's a lot of work gone into stuff like UBSan for C++. I think aliasing should be added to stuff that it checks for. Dunno how much overhead that would be though.

Post reply on HN