It's common in graphics and audio programming. In audio, maybe you're synthesizing noise or any of the myriad synthesis techniques that require noise. In graphics you have lighting, textures, etc that can use this. And when you're doing something every audio sample or every pixel, "extremely fast" is desirable. The question of whether to use a pre-rendered lookup table or a fast algorithm often comes up (and has no universal answer... though I always go for the latter)
I love how this site immediately confronts you with the differences between translations, which quickly reveals how much skill and creativity can be in the translations themselves. Especially for poetry, a good translation is not just an imperfect copy, it's an artistic work where the authorship is shared between the original author and the translator.
I'm sure Baudelaire himself would have a few things to say on the topic. His translations of Edgar Allan Poe's works are notorious examples of art in translation. If you've got the French level, they are very much worth reading even if you've read the originals.
In 1968 a British newspaper ran a competition for English translations of "Spleen - Je suis comme le roi..." The poet Nicholas Moore - motivated by a belief that translating poetry was impossible and the project futile - sent in 31 different entries, by post, under false names and with varying levels of absurdity. He didn't win.
You can find them at https://www.ubu.com/ubu/pdf/moore_spleen.pdf, or in his published Selected Poems, along with an essay (written afterwards) about translation. Worth looking out.
(I particularly admire the sarcastic one that begins "I'm like The Winner of The Competition / The one who wrote the strong, rewarding phrase...")
Representing undo/redo history as a tree is quite different from representing the code structure as a tree. On the one hand I'm surprised no one seems to care that a response has nothing to do with the question... on the other hand, these AI tooling threads are always full of people talking right past each other and being very excited about it, so I guess it fits.
They certainly can be quite different things and in all current systems I know of the two are unrelated, but in my system they are one and the same.
That's possible because the source of truth for the IDE's state is an immutable concrete syntax tree. It can be immutable without ruining our costs because it has btree amortization built into it. So basically you can always
construct a new tree with some changes by reusing most of the nodes from an old tree. A version history would simply be a stack of these tree references.
Well, yeah. The filtering is a joke. And, in reality, it's all moot anyways - the whole concept of LLM jailbreaking is mostly just for fun and demonstration. If you actually need an uncensored model, you can just use an uncensored model (many open source ones are available). If you want an API without filtering, many companies offer APIs that perform no filtering.
It's not really security theater because there is no security threat. It's some variation of self importance or hyperbole, claiming that information poses a "danger" to make AI seem more powerful than it is. All of these "dangers" would essentially apply to wikipedia.
Thanks, I thought the whole investigation was really interesting. Unfortunately discussion on HN tends to stop once the article is off the front page, but your responses here will be valuable for anyone who finds this while searching.
Sounds like a typical investigation to me. You go down a few rabbit holes which turn out to be dead ends, and eventually realize the solution was right under your nose this whole time (this may sound familiar if you've done enough debugging as well). I also suspect the solution wasn't as obvious as the article makes it seem. For sure it should be framed more as a group effort, but that's just the writing style being weird.
Or they could have read the article and be arguing that a relationship with one side helping the other when necessary doesn’t fit theft.
A plant maximizing growth might then be able to supply more energy in the future. Assuming the fungi had an abundance of energy it might also prefer a long term strategy.
I always appreciate someone coining a useful expression, but I gotta say, sometimes these coiners are trying a bit too hard, no? I think I'll stick with "exploration-based", "exploratory" or "explorative" programming, which are commonly used and all sound less awkward to me than than "discovery coding". But hey, if that's what people flock to I'll get with the times! I've always used a combination of both approaches and the descriptions made here are great.
I agree, "exploration" style ... learning. Exploration is what we are in control of. Discovery is the natural and expected result, but isn't in our control.
Exploration style "learning" applies to anything.
But the phrase "exploration oriented development" does make sense. Given the useful and growing list of "X oriented development" paradigms that have been identified.
Exploration is especially good for:
1. Learning how to create things for fun.
2. Building solutions in unfamiliar areas.
3. For the most challenging greenfield problems and solutions.
In all cases, jump in, try things. Iterate as fast as possible to identify the most significant problem, define it as clearly as possible, find the smallest possible version of it, and try every angle to solve that. Then reorient and repeat.
Exploration is the right word, because you are letting the terrain guide you to unexpected problem perspectives, solutions, and means. From a learning goal standpoint, it is extremely efficient, and the specifics and wisdom discovered are often original.
I have spent my career doing greenfield work, chosen by me, which must be rare. Every day I push as hard as I can on the smallest problem surface I can find. The downside is that rate of progress is unpredictable, chaotic with very high deviation. And sometimes you expend a lot of time working your way into a real dead end. Another is the amount of code discarded can dwarf the final code by orders of magnitude.
reply