Just in case, this is my library and I didn't post this to the HN, because I didn't think this is that HN-worthy. Ask me anything anyway.
My main motivation to port libbf was to see if it is faster than usual libraries available in Rust, and yes, some operations are indeed faster than others, but it was tough to compare against Rug which uses MPFR under the hood. I did fully design the library API beforehand and explicitly directed the documentation, testing and benchmark tasks, but of course all the brilliance of the library comes from Fabrice Bellard and not me.
Beeg is just a respelled version of "big" ("ee" for /i:/). Apparently it is also a name of a certain questionable website (I didn't know!), but it is a common enough word that such unfortunate conflicts are to be expected.
You can say something similar if someone had hand written it and reimplemented an existing library in new language. "This is just a reimplementation of existing library to Rust, I don't have anything new to add myself."
Also its never as simple as a single prompt, it goes beyond it if the user really cares.
The Red Queen's Race is real, though. Compilers keep moving, platforms keep moving, users of the library (I mean programs importing/linking them) keep moving, assumptions keep moving.
One can argue that some algorithm library written in the early 1980s using F77 is as good as it was at the time of writing, but I highly doubt anyone is using it as it is.
Rust compiler is famously backward compatible all the way to 1.0 (after almost a decade of zero guarantees). My codes targeting early 1.x releases still work in the modern Rust, though the convention may significantly differ from the modern Rust. Your point might be true for some other languages but there is a good reason to refute that for Rust.
Ah, and many F77 libraries are still in active use. Nowadays they are used via C or Python wrapper, and I guess you said "using it as it is" to disregard that, but we were talking about what original maintainers are expected to do and the original F77 authors have nothing to do in order to stay relevant here.
Just in case, this is my library and I didn't post this to the HN, because I didn't think this is that HN-worthy. Ask me anything anyway.
My main motivation to port libbf was to see if it is faster than usual libraries available in Rust, and yes, some operations are indeed faster than others, but it was tough to compare against Rug which uses MPFR under the hood. I did fully design the library API beforehand and explicitly directed the documentation, testing and benchmark tasks, but of course all the brilliance of the library comes from Fabrice Bellard and not me.
EDIT: I see that libbf implements faithful rounding of operations. Nice. TIL.
See also: Jean-Michel Muller's books: "Handbook of Floating Point Arithmetic," and "Elementary Functions."
https://www.sollya.org/
uh... that title... don't search for what the hell a "Beeg" is. apparently this was just sloppy spelling for beef
Beeg is just a respelled version of "big" ("ee" for /i:/). Apparently it is also a name of a certain questionable website (I didn't know!), but it is a common enough word that such unfortunate conflicts are to be expected.
You can simply check Wiktionary, like you can with most words.
"Dear HN, I pointed Claude at another existing codebase and told it to port it to Rust. I don't have anything new to add myself. Please lap this up."
The submitter isn’t the library author.
You can say something similar if someone had hand written it and reimplemented an existing library in new language. "This is just a reimplementation of existing library to Rust, I don't have anything new to add myself." Also its never as simple as a single prompt, it goes beyond it if the user really cares.
The expectation of ongoing maintenance for oneshotted LLM rewrites is zero or negative.
It wasn't one-shotted by the way, but if you have a provably correct and comprehensive library there are not many things to maintain anyway.
The Red Queen's Race is real, though. Compilers keep moving, platforms keep moving, users of the library (I mean programs importing/linking them) keep moving, assumptions keep moving.
One can argue that some algorithm library written in the early 1980s using F77 is as good as it was at the time of writing, but I highly doubt anyone is using it as it is.
Rust compiler is famously backward compatible all the way to 1.0 (after almost a decade of zero guarantees). My codes targeting early 1.x releases still work in the modern Rust, though the convention may significantly differ from the modern Rust. Your point might be true for some other languages but there is a good reason to refute that for Rust.
Ah, and many F77 libraries are still in active use. Nowadays they are used via C or Python wrapper, and I guess you said "using it as it is" to disregard that, but we were talking about what original maintainers are expected to do and the original F77 authors have nothing to do in order to stay relevant here.