Since there're independent Lightness values set for each section (I'd say quadrant but there are 6 of them), I wonder if two bits can be shaved from the `L` value from the base color. It'd take some reshuffling and might not play well with color customization in mainly flat images, but I think it could work.
I'm also curious to see that they're doing solely grayscale radial gradients over the base color instead of tweaking the base color's `L` value and using that as the radial gradient's center, I'd imagine you'd be doing more math that way in the OKLab colorspace which might give prettier results(?).
Tempted to play around with this myself, it's a really creative idea with a lot of potential. Maybe even try moving the centers (picking from a list of pre-defined options with the two bits stolen from the base color's L channel), to account for varying patterns (person portraits, quadrant-based compositions, etc).
As someone pretty firmly in the anti-AI camp, I'm genuinely glad that you've personally found AI a useful tool to polish text and help you communicate.
I think that just because someone might be more or less eloquent than someone else, the value of their thoughts and contributions shouldn't be weighed any differently. In a way, AI formatting and grammar assistance could be a step towards a more equitable future, one where ideas are judged on inherent merits rather than superficial junk like spel;ng or idk typos n shi.t
However, I think what the parent commenter (and I) might be saying is that it seems you're relying on AI for more than just help expressing yourself—it seems you're relying on it to do the thinking too. I'd urge you to consider if that's what you really want from a tool you use. That said, I'm just some random preachy-judgy stranger on the internet, you don't owe me shit, lol
(Side notes I couldn't help but include: I think talking about AI and language is way more complicated (and fascinating) than just that aspect, including things I'm absolutely unqualified to comment on—discrimination against AAVE use, classism, and racism can't and shouldn't be addressed by a magic-wand spell-checker that "fixes" everyone's speech to be "correct" (as if a sole cultural hegemony or way of speech is somehow better than any other))
> As someone pretty firmly in the anti-AI camp, I'm genuinely glad that you've personally found AI a useful tool to polish text and help you communicate.
> I think that just because someone might be more or less eloquent than someone else, the value of their thoughts and contributions shouldn't be weighed any differently. In a way, AI formatting and grammar assistance could be a step towards a more equitable future, one where ideas are judged on inherent merits rather than superficial junk like spel;ng or idk typos n shi.t
I guess I must come clean that my reply was sarcasm which obviously fell flat and caused you to come to the defense of those who can't spell - I swear I don't have anything against them.
> However, I think what the parent commenter (and I) might be saying is that it seems you're relying on AI for more than just help expressing yourself—it seems you're relying on it to do the thinking too. I'd urge you to consider if that's what you really want from a tool you use. That said, I'm just some random preachy-judgy stranger on the internet, you don't owe me shit, lol
You and presumably the parent commenter have missed the main point of the retort - you are assuming I am relying on AI for my content or its style. It is neither - I like writing point-wise in a systematic manner, always have, always will - AI or no-AI be damned. It is the all-knowing veil-piercing eagle-eyed deduction of random preachy-judgy strangers on the internet about something being AI-generated/aided just because it follows structure, that is annoying.
The winning submission [0] was discussed on HN recently [1]. It's highly impressive from both technical decisions and graphic design viewpoints, it somehow elegantly visualizes 2 billion books (in a way that resembles a bookcase no less).
(Timestamp to skip alternative methods' background info: [0])
An algorithm that yields a computationally precise (no compounding floating point errors from small deltas like with a numerical evaluation) derivative function for all differentiable functions by evaluating it once, with no need for AST parsing or complicated rule compositions (think chain rule, quotient rule, etc. [1] used in symbolic differentiation).
The trick is dual numbers [2] (like a sibling of complex numbers), which have an epsilon component (analogous to complex numbers' i) with rules that ɛ != 0 and ɛ*ɛ = 0.
A property of dual numbers is that f'(x) = the dual only component of the result of evaluating f(x + 1ɛ). It's honestly harder to explain in english than it is to write the code.
The one catch is that you do need to implement dual handling for all mathematical operations your functions will need (just *, +, and / get you really far though). It's not hard though, multiplication is (a, b) => {real: (a.real*b.real), epsilon: (a.real*b.epsilon + b.real*a.epsilon)}, which naturally follows from foil-ing and the two epsilon rules. Trig is a little more complicated, yet easy enough to look up [3].
From there, differentiation is just (f, x) => (f({real: x, epsilon: 1}).epsilon). Given that practically every language supports custom operator implementations for classes (or whatever the language's equivalent terminology is), after a little setup you don't even need to change the syntax you use to write functions, you just get free differentiation handed to you.
Bivectors and higher show up a lot in the math of 4D+ geometry, too. There's a fascinating SIGRAPH 2020 talk [0] (with a paper [1]) by the maker of 4D Toys [2] and Miegakure (a 4D game in the works, [3]) explaining 4D geometry collision physics (with a good bivector intro in addition to the collision math). It's a great read and/or watch that smoothly covers everything from building basic intuitions to the gritty technical math of extending standard physics models to N-D spaces.
A small native iOS feature that supports customized recognition (eg recognize an apartment buzzer or specific laundry machine chime).
I don't have an iPhone to experiment with so I don't know what all is supported, yet I could see this being used to pass specific sounds only through noise cancelling (or rewrite them to use a different chime), or by leaving your phone somewhere out of hearing range to "tunnel" to a notification onto your desktop (if that's supported).
EDIT: I was wrong and misunderstanding how these options interact, this doesn't solve the stated problem. Still good to have in your config but not as powerful as desired, sorry. Keeping comment contents mostly for posterity's sake.
Under the hood `git pull` is just `git fetch`+`git merge` so these two configs together would ideally enable the behavior requested (but unfortunately don't):
[fetch]
all = true
[pull]
ff = only
I also disable fast-forwarding with `git merge` since I prefer the branch topology you get without it. This doesn't break natural `git pull` fast-forwarding either, thanks to the above config:
The fast-forward is on branch A. I'd like the git pull to also fast-forward branch B (and branches C,D,Etc.).
They're usually by other devs, I don't usually check these, but when I do, I could save an extra command when switching if git just moved the branch head with the data it already has.
You're right that doesn't fix it and it is annoying. I just learned something about git, thanks!
Thinking on this more I think I'd prefer changing `git checkout/switch <branch>` to automatically use `origin/<branch>` instead (like mook mentions in a sibling comment), rather than changing the `git pull` behavior.
Keeping the local branch refs in place after `git pull` lets you still easily see the local vs remote differences when running `git log`. Changing the behavior of `git checkout` or whatever you use to switch branches to auto fast-forward seems to be a way to have your cake and eat it too, almost.
But, clearly you've thought more on this than I have (having just learned about it lol), what do you think?
These aren't branches I commit regularly to, but I'd rather avoid the detached head state when using 'origin/'. Auto fast-forwarding on switch would be good enough for me.
(personally I think Difftastic's treesitter based approach is superior to Delta, yet I always appreciate it when people link alternatives when discussing apps so thought I'd add this for completeness' sake)
I'm also curious to see that they're doing solely grayscale radial gradients over the base color instead of tweaking the base color's `L` value and using that as the radial gradient's center, I'd imagine you'd be doing more math that way in the OKLab colorspace which might give prettier results(?).
Tempted to play around with this myself, it's a really creative idea with a lot of potential. Maybe even try moving the centers (picking from a list of pre-defined options with the two bits stolen from the base color's L channel), to account for varying patterns (person portraits, quadrant-based compositions, etc).