3,134 karma · joined February 12, 2018
We can see for e.g. that frontier models have got really good at CAD sorts of tasks recently. That suggests benchmaxxing RL to a degree but it does mean they've suddenly got quite good at forming simple geometries in a step by step way.
It’s quirky because when you had kilobytes of RAM, storing the length of the string was memory you couldn’t afford. Arrays decaying into pointers similarly meant carrying a single pointer around rather than a fat struct. Magic integers for return codes were used because they’d fit into a single register. Compilers didn’t have the processing power or memory to track complex borrow rules or static analysis. They were slow even as they were! Old processor architectures were way more diverse and fragmented than now - and even 30 years ago endianness wasn’t a settled thing.
Things weren’t quirky because people “wanted” them to be, they were quirky because everything was way more constrained. Rust came into a way more rationalised environment and it’s a great language of course but the operating environment is so totally different it’s hard to compare.
There are two of us on here!
I was going to say that people encounter ferrimagnets more commonly than pure ferromagnets I think, since as we both know pure ferromagnets tend not to have very high anisotropy.
The one negative I'd say is that often autovectorisation is 'good enough' and this doesn't really tackle that gap.
Isn't that because they're still flat out on rolling fibre out? There's not that many telecoms engineers and if they spend tons of time removing the old, that slows down the new.
Me: "Parallelise this loop without changing the results."
AI: "I can't do that, because of floating point accumulation."
Me: "So spin out a temporary fixed-length array, accumulate into that thread-locally, and then do an ordered summation of that at the end."
AI: "Oh, you're right!"
It's a fantastic tool for automating the implementation grind, but you still have to hand-feed it the strategy. I guess it will get there at some point.
I'm not sure how; the UK is an Anglosphere country that uses A4 and desktop machines as far back as I can remember (mid 90s) also correctly defaulted to A4 when printing. I suspect it's more likely to be that there's been English (UK) and English (US) options in OS's for a long time and Aus got defaulted to English (US) rather than English (UK) which carried some settings that weren't correct by default.
I don't think this is true at all. A lot of people who work at places like OpenAI and Anthropic or any research lab really, aren't just CS people, there are a plenty of mathematicians and physicists, etc. and so the problems are interesting to them.
Turns out that's a particularly East Midlands thing!
Here's a similar impl from 1980 written in Fortran that also computes other properties like centroid: https://calgo.acm.org/550.zip Algorithm 550: Solid Polyhedron Measures A. M. Messner and G. Q. Taylor ACM Trans. Math. Softw., 6(1), Mar 1980, pp.121--130 Keywords: polyhedron, graphics, numerical integration Language: Fortran 66/77; Shar Index: Z; Gams: P File size: 19.1 KB;
But Messner published it first in: A. M. Messner, "A surface Integral method for computer calculation of mass properties", Paper No. 852, 29TH ANNUAL CONF. OF THE SOCIETY OF AERONAUTICAL WEIGHT ENGINEERS, Washington, D.C., May 1970.
I think
If you think of for e.g. some proprietary piece of software that wants to embed an LLM they've fine tuned or trained, they will want to make back some of their research cost right. So they are not going to want to put this on-device even if the hardware is there, unless there's some way of locking it down. I suspect we'll need on-hardware validation/verification and a way of preventing extraction of weights for this move to happen for many use cases.
I always preferred Mathematica for that to SymPy since it's baked in to the language much more. It was also way way faster than SymPy was for anything interesting.
Yes, but the privacy aspect means that for many, many applications slower local will still be preferable to faster remote so long as the actual model performance is the same.