Table--Maker's dilemma [0] says that we probably can't get correct rounding for some functions. That said, you can still calculate every function within 1 ULP by using extended precision (for example the double-double arithmetic, which uses two doubles to represent a single fp number) and rounding.

But I don't think anyone does this in practice. Simulations don't need perfect precision, anything involving real data has to deal with measurement errors which are usually much larger than f64 ULP scales, and then there's configurable arbitrary-precision for when it's really needed.

[0]: https://people.eecs.berkeley.edu/~wkahan/LOG10HAF.TXT, which coincidentally is also about the log function

Yeah, those operations (+fma) are the only ones for which IEEE 754 mandates correct rounding.

Calculating correct rounding for other functions without hardware support is both challenging to implement and is often really slow. And that's before one gets into special functions. Or, even worse, inverses of special functions. Sometimes you might be lucky when those don't over/underflow around the edges of the domain

It's still challenging to implement with hardware support but you don't notice because it challenges Intel instead of you. There is a reason that no instruction set since x87 implements transcendentals - and x87 did them in microcode.

True!

Older numerical libraries such as cephes had to work with heterogeneous non-IEEE floating point implementations: you can still see remnants of VAX tests in the docs, for example. That, too, must've been quite a struggle

StageX does reproducible builds, so they are signed independently and can also be verified locally. I don't think it applies to Astral, but it's useful for packages with a single maintainer or a vulnerable CI, where there is only one point of failure.

But I also think it'd be nice if projects provided a first-party StageX build, like many do with a Dockerfile or a Nix flake.

Once we have better support for multiarch in stagex, since StageX is distributed as OCI images, you could just replace your existing Dockerfile bases with stagex.

The first programming language I learned was Java. And for us non-native speakers who didn't know English very well at that point public static void did indeed sound like a magic spell. It was behind both an understanding and a language barriers

When I first saw Java, I had already seen multiple dialects of BASIC, plus Turing (a Pascal dialect), HyperTalk (the scripting language of HyperCard, and predecessor of AppleScript), J (an APL derivative), C and C++. I'm also a native speaker of English.

Your perception is still warranted. It was clear enough to me what all of that meant, but I was well aware that static is an awkward, highly overloaded term, and I already had the sense that all this boilerplate is a negative.

One of the problems is that a lot of bioinformatics formats nowadays have to hold so much data that most text editors stop working properly. For example, FASTA splits DNA data into lines of 50-80 characters for readability. But in FASTQ, where the '>' and '+' characters collide with the quality scores, as far as I know, DNA and the quality data are always put into one line each. Trying to find a location in a 10k long line gets very awkward. And I'm sure some people can eyeball Phred scores from ASCII, but I think they are a minority, even among researchers.

Similarly, NEXUS files are also human-readable, but it'd be tough to discern the shape of inlined 200 node Newick trees.

When I was asking people who did actual bioinformatics (well, genomics) what some of their annoyances when working with the bioinf software were, having to do a bunch of busywork on files in-between pipeline steps (compressing/uncompressing, indexing) was one of the complaints mentioned.

I think there's a place in bioinformatics for a unified binary format which can take care of compression, indexing, and metadata. But with that list of requirements it'd have to be binary. Data analysis moved from CSVs and Excel files to Parquet, and I think there's a similar transition waiting to happen here

My hypothesis is that bioinformatics favors text files, because open source tools usually start as research code.

That means two things. First, the initial developers are rarely software engineers, and they have limited experience developing software. They use text files, because they are not familiar with the alternatives.

Second, the tools are usually intended to solve research problems. The developers rarely have a good idea what the tools eventually end up doing and what data the files need to store. Text-based formats are a convenient choice, as it's easy extend and change them. By the time anyone understands the problem well enough to write a useful specification, the existing file format may already be popular, and it's difficult to convince people to switch to a new format.

Yes, most bioinformatics tools are the result of research projects.

However, the most common bioinformatics file formats have actually been devised by excellent software engineers (e.g. SAM/BAM, VCF, BED).

I think it is just very convenient to have text-based formats as you don't need any special libraries to read/modify the files and can reach for basic Unix text-processing tools instead. Such modifications are often needed in a research context.

Also, space-efficient file formats (e.g. CRAM) are often within reach once disk space becomes a pressing issue. Now you only need to convince the team to use them. :)

Totally. A good chuck of the formats are just TSV files with some metadata in header. Setting aside the drawbacks, this approach is both straightforward and flexible.

I think we're seeing some change in that regard, though. VCF got BCF and SAM and got BAM

Yeah, I found `anyhow`'s `Contex` to be a great way of annotating bubbled up errors. The only problem is that using the lazy `with_context` can get somewhat unwieldy. For all the grief people give to Go's `if err != nil` Rust's method chaining can get out of hand too. One particular offender I wrote:

   match operator.propose(py).with_context(|| {
    anyhow!(
   "Operator {} failed while generating a proposal",
   operator.repr(py).unwrap()
  )
   })? {

Which is a combination of `rustfmt` giving up on long lines and also not formatting macros as well as functions

The dereference table allows allocations to fail:

https://arxiv.org/pdf/2501.02305#:~:text=If%20both%20buckets...

(the text fragment doesn't seem to work in a PDF, it's the 12th page, first paragraph)

Thanks! So I guess the best recourse then is to resize the table? Seems like it should be part of the analysis, even if it's low probability of it happening. I haven't read the paper, though, so no strong opinion here...

(By the way, the text fragment does works somewhat in Firefox. Not on the first load, but if load it, then focus the URL field and press enter)

Yeah, I presume so. At least that's what Swiss Tables do. The paper is focused more on the asymptotics rather than the real-world hardware performance, so I can see why they chose not to handle such edge cases

This bothered me too, reading it and the sample implementations I've found so far just bail out. I thought one of the benefits of hash tables was that they don't have a predefined size?

The hash tables a programmer interacts with generally very much have a fixed size, but resize on demand. The idea of a fixed size is very much a part of the open addressing style hash tables -- how else could they even talk of how full a hash table is?

A spreadsheet engine. It's a React app with a Rust backend, but it impressed me how snappy it was[0]. Of course, it's not nearly as feature rich as Google Sheets, not to mention Excel.

[0]: https://app.ironcalc.com/

"backend" seemed to imply it was contacting some server, but https://github.com/ironcalc/ironcalc#early-testing claims (and the network tab confirms) it is just Rust compiled to wasm, no "backend" required

MIT or Apache 2 (player's choice) if anyone else has grown deeply suspicious about any "open source" HN headlines of late

Right, I've made a mistake! I keep getting surprised by the fact it's possible to simply compile a Rust crate with a WASM target and run it in the browser.

backend does not imply server to me, it implies software that does the calculating engine work and does not concern itself with display refresh.

Backend is a general word, not limited to client-server or the web. You can have a rendering backend with various configurable choices, like in Matplotlib (https://matplotlib.org/stable/users/explain/figure/backends....), or the deep learning library Keras has a choice between PyTorch, JAX and TensorFlow backends.

we're talking about a spreadsheet engine, the backend is not going to be the Xserver displaying it

In code that typically runs in on e process, that's a plausible interpretation.

However, the browser, sorry, the Internet browser, is typically a distributed system and a more plausible interpretation of backend is server-side.

IMNSHO.

I wouldn't call it background unless maybe it's async or continues to process stuff while you're doing other things.

what's the backend of a spreadsheet engine going to be doing? updating the datastructures of the spreadsheet.

is it going to be local or remote? that's not part of the question.

is it foreground or background? that's an implementation choice. apple II, yeah, everything freezes while it recalcs. windows? recalcs when it can, don't let the mouse freeze.

It's running entirely on your browser unless you click share, download or import. The computation part is done in Rust compiled to wasm.

Thank you for posting!

Yep, I've misunderstood, realized it after seeing mdaniel's comment.

Thanks for making this in the first place! I saw IronCalc in the list of projects supported by NLnet and it grabbed my attention.

By the way, if You don't mind me asking, how'd Tuta end up sponsoring IronCalc? It seems that lately they and Proton have been trying to expand their business away from just email. The fact that Tuta is interested in IronCalc makes me think they want to have an office-like offering.

Tuta sponsors by providing us with free email accounts, that's all. I reached out months ago, they liked the project and were kind enough to help us out with the email.

I haven't have talks with them about integrating IronCalc, but it is something that is on my mind.

Ah, I see. Best of luck with that!

There are a few projects where I'd love to see a modern spreadsheet implementation. CryptPad comes to mind. They use OnlyOffice, which is quite featurefull, but takes awhile to load and isn't as responsive.

What Google Sheets functionality you're missing there?

Of course there's a lot missing, but what's interesting is what you've reached for and could not find.

How tightly coupled are the React app and the Rust backend?

I hope the backend engine can be used standalone embedded in other apps.

Contrary to the name, I don't think that it's very good. The whole thing is a canvas via WASM, so scrolling isn't smooth, selection doesn't work, and accessibility is seemingly non-existent.

But I think the technology itself is interesting. While most modern UI toolkits use HTML or React-like components, this uses a set of JSONs, which describe the page.

Is json a good file format for UI?

I haven't self-hosted any, but I enjoy using Flarum [0] forums. They load faster than Discourse ones and feel snappy.

[0]: https://flarum.org/