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!
HN user
CreRecombinase
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 ]
Have you tried this yet? Looks like it uses the ms graph API https://github.com/jgunthorpe/cloud_mdir_sync
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.
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
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
QR decomposition isn’t in BLAS, you’re probably thinking of LAPACK.
No. OTOF is the gene symbol. Referring to the gene as otoferlin is perfectly legitimate
That’s certainly not true in scientific computing. For us, dynamic is very much the exception rather than the rule.
How might one go about making the nuclear family a universal?
That’s absolutely not true about Microsoft. They’re very clear about how they use your data. If they’re mining data in secret against their own terms that’s felonious criminal behavior.
I think what it comes down to is that it's very difficult to divorce modeling from inference.
It's absolutely not "on the way out". Lots of very slow moving, very deep pocketed organizations working on very long time horizons are heavily invested in HDF5. The same can't be said for any of the flavor-of-the-week ML "cloud-native" file formats.
Does pigz offer any advantages over bgzip?
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.
How often do you have markup in the middle of a phrase you're searching for? It seems to me like if that's really important to you, then just don't use a lot of markup?
I've never seen a 15x difference in density between gzip and zstd on genomic data in an apples-to-apples comparison; I'd be really curious to learn more about how you achieved that.
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.
Roaring bitmaps are compressed bitmaps and they're pretty great. https://roaringbitmap.org/about/
You have to understand that many R users don't have root access the the machines they're working on.
R packages on CRAN need to be able to install without internet connection so I'm skeptical that that's the case. CRAN packages also don't allow for dependency on R packages that are (only) on github.
I would argue that if "reasonably competent" means "gets in accidents less frequently and has fewer moving violations", the "idiot" in the minivan is very likely more competent than the joy rider. Also one person's scenic route is another person's shortest route, or maybe only route.
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.
2 properties at 1 million will probably require more time and effort though, right? Like they may be better off buying 10 200k houses, but the mob lawyer has more important things to do
I think the worst thing you could do in this situation is put the redesign people on the infrastructure team
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".
Joe Derisi is a really incredible scientist. A "founding father" of genomics.
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