HN user

CreRecombinase

359 karma

I find computation and biology to be a delicious peanut butter and chocolate combination. www.knobla.com

[ my public key: https://keybase.io/crerecombinase; my proof: https://keybase.io/crerecombinase/sigs/VGD62dHQ_CRawPoSlw66WgOXyhAx1STFJIpeQbLuE1I ]

Posts1
Comments91
View on HN

Why not just use a dictionary, or why not just leave the type unannotated? If you really can't (or don't want to) say anything about the type, then don't. Python is dynamically typed!

I turned this on and for most "general" use cases I found it useful, I also observed a downward biased in a family of "quantatitative estimation" tasks, so just remember when you have this kind of stuff turned on (always beware of mutating global state!)

It’s kind of wild how much work really smart people will do to get python to act like Fortran. This is why R is such a great language IMO. Get your data read and arrays in order in dynamic, scheme-like language, then just switch to Fortran and write actual Fortran like an adult.

Big Book of R 1 year ago

The comment you linked is a response to my comment where I tried (and failed) to articulate the world in which R is situated. I finally "RTFA" and the benchmark I think perfectly deomonstrates why conversations about R tend not to be very productive. The benchmark is of a hypothetical "sum" function. In R, if you pass a vector of numbers to the sum function, it will call a C function sum. That's it. In R when you want to do lispy tricky metaprogramming stuff you do that in R, when you want stuff to go fast you write C/C++/Rust extensions. These extensions are easy to write in a really performant way because R objects are often thinly wrapped contiguous arrays. I think in other programming language communitues, the existence of library code written in another language is some kind of sign of failure. R programmers just do not see the world that way.

Every two weeks or so I peruse github looking for something like this and I have to say this looks really promising. In statistical genetics we make really big scatterplots called Manhattan plots https://en.wikipedia.org/wiki/Manhattan_plot and we have to use all this highly specialized software to visualize at different scales (for a sense of what this looks like: https://my.locuszoom.org/gwas/236887/). Excited to try this out

R was heavily inspired by scheme, and I think that's a big part of why it's so popular in the scientific community (it's a great language for authoring DSLs). In fact, DSLs are so good in R that lots of midwit CS bros love to dunk on R the language, not realizing that what they're complaining about is in fact some library function. I like to tell people that R is "scheme on the streets, FORTRAN in the sheets". Just like Clojure deviated from I think R was very much developed as a Lisp designed to facilitate complex and flexible scientific applications (with an emphasis on statistical computing). I think you could develop a compelling analogy that Clojure:JVM::R:Numerics-oriented C/FORTRAN

ChatGPT Pro 2 years ago

This is what's so brilliant about the Microsoft "partnership". OpenAI gets the Microsoft enterprise legitimacy, meanwhile Microsoft can build interfaces on top of ChatGPT that they can swap out later for whatever they want when it suits them

I spend most of my time in the parallel universe that is scientific computing/HPC. In this alternate reality SQL (not to mention databases) never really took off. Instead of scalable, performant databases, we have only the parallel filesystem. I'm convinced the reason contemporary scientific computing don't involve much SQL is sociological/path-dependency, but there are also very good technical reasons. Optimizing software in scientific computing involves two steps: 1) Think hard about your problem until you can frame it as one or more matrix multiplications 2) Plug that into a numerical linear algebra library The SQL abstraction (in my experience) takes you very much in the opposite direction.

These MPI-based scientific computing applications make up a bulk of the compute hours on hpc clusters, but there is a crazy long tail of scientists who have workloads that can’t (or shouldn’t) run on their personal computers. The other option is HPC. This sucks for a ton of reasons, but I think the biggest one is that it’s more or less impossible to set up a persistent service of any kind. So no databases; if you want spark, be ready to spin it up from nothing every day (also no HDFS unless you spin that up in your SLURM job too). This makes getting work done harder but it also means that it makes integrating existing work so much harder because everyone’s workflow involves reinventing everything, and everyone does it in subtly incompatible ways; there are no natural (common) abstraction layers because there are no services.

I often feel like bioinformatics is like this steampunk alternate reality where, because HPC clusters don't generally do database administration, all the technology and the ecosystem has developed has been built on flat files. Let me tell you, it's not great.

That's a bummer. I have an Intel 700 series I got several years ago that I've been torturing on and off for years. Still no problems. I think it was their first NVMe/PCIe drive too. Hell, the haswell era i7 and the god-knows-when era quadro feel much more "long in the tooth".

R some very lispy meta-programming features. Very briefly, if I'm a function (go with me here) `foo <- function(x,y){whatever}`,and someone calls me, `foo(bar,baz)` I get to know that `baz` is "bound" to `y`. The caller doesn't even have to have a `baz` in scope; substituting `y` for `baz` is done lazily, if the function never asks for the actual value of `y`, there's no problem. You can read more about this here http://adv-r.had.co.nz/Computing-on-the-language.html