Ah nice for noticing d!=0 is d>0. Not sure how I missed the multiplication to get rid of the vector form; I guess I was too obsessed with the x-x trick...
I added your changes to the Shadertoy version with your HN nickname. I'll integrate it to the original later.
I saw that you used `float z;` to later use `z` instead of the constant `0.`.
You can also apply that to get a zero vector: `vec3 y;` and use `y` in place of `p-p`.
It seems that leaving the obsession behind some more can save another byte.
Especially in HPC there are lots of workloads that do not benefit from SMT. Such workloads are almost always bottlenecked on either memory bandwidth or vector execution ports. These are exactly the resources that are shared between the sibling threads.
So now you have a choice of either disabling SMT in the bios, or make sure the application correctly interprets the CPU topology and only spawns one thread per physical core. The former is often the easier option, both from software development and system administration perspective.
>Especially in HPC there are lots of workloads that do not benefit from SMT...So now you have a choice of either disabling SMT in the bios
Thats madness. Theyre cheaper than their all-core equivalent. Why even buy one in the first place if HT slows down the CPU? Youre still better off with them enabled.
In addition to needing SMT to get full performance, there were a lot of other small details you needed to get right on Xeon Phi to get close to the advertised performance. Think of AVX512 and the HBM.
For practical applications, it never really delivered.
I'm not sure what the OS on the X32 (or the Midas M32 sister model for that matter) is from factory.
The higher end Midas Pro consoles do definitely run on Linux though.
It is the performance win for similar looking results that I find improbable. For a box blur to look like gaussian blur, you would need multiple passes. Even though each pass is now O(1) instead of O(n) (with n the blur radius), due to caching effects I think a gaussian kernel would still be faster, especially for the small blur radius as described in the article.
That link is not a box filter, as it still uses weights to approximate a gaussian convolution kernel. It just uses some special hardware to do less texture fetches. But that is a constant 2x improvement over the full 1D convolution, not the box filter O(1) approach that the article suggests that browsers are using.
You've moved me a place of uncertainty here. I had some confirmation that _some_ browsers use box blurs for this effect, I _know_ some game engines use multiple box blurs to approximate Gaussian blur (having seen the code myself).
I updated a few sentences in the article to reflect that uncertainty. Thanks!
I noticed the blur only "sees" the underlying pixels directly below the glass surface. Any pixels outside that box, but within the blur radius do not get used in the gaussian filter. Probably the edge pixels are just repeated. You can see this when the light of the moon pops in to view when the edge of the rectangle starts to touch the moon. It would look more real if the light pixels from the moon start to through even when the box itself is still just over the dark area.
Would this be possible to achieve in CSS? I presume having a larger box with the blur, but clipping it to a smaller box or something like that.
> This can be solved with CSS. Extend the background blur all the way through the element and then use CSS masks to cut out the actual shape you want.
> With this, you can remove the border (or inset box shadow), and the edge of the glass will look much, much more real
I tried this and it works! One unfortunate impact is a loss in simplicity. In the example on the page you can apply the non-JavaScript version to pretty much any element and get a nice glass effect with `border-radius` and such still functioning as expected.
Using `clip-path` I'm able to consider background pixels more correctly but it looks like I'd need an extra div and/or some sizing tricks to get everything working exactly as expected.
I'll keep noodling on this and may add an update to the page if a simple solution comes to mind.
I don't think this is correct. I think colanderman's answer is the right one, which is that when we're descending, we generally spell out the pitches with flats. If this were ascending, then we could have I-#I-II. But as I noted, in jazz this particular descending pattern is fairly common.
I, bII, etc. are chords not pitches. II-bII-I is a chord change. Pitches may go up or down and voices may go away or arrive. They may be part of those chords or not. And there may not even be a root pitch.
Or if you want formal theory, chords are scales [1] and there ain't no such thing as a scale with a sharp I. If you sharp the one it’s a different scale starting in a different place.
The b in bII is not an accidental and bII is how to communicate the chord in passing. I/bII is also possible to communicate a modulation (as would be vii/II, etc. if the modulation is elsewhere).
There are “enharmonics” for chords that aren”t the root of course, e.g. #IV and bV depending on intent, convention, or playability. But #I will be marked wrong on the entrance exam and only raise you standing among an avant guard that isnt accepting new members.
> If you sharp the one it’s a different scale starting in a different place.
It depends on what's the function. If you want to use the tritone-substituted G7 to modulate to the sharp fourth, you'd write it C#7 and resolve it to F# (or F#-).
C#7 is the name of a chord not a pitch and not Roman Numeral Analysis. [0]
The Roman Numeral analysis would be V7/#IV if you are modulating in C. And something else if you aren't in C. Roman Numeral Analysis is independent of key or tonal center. The Roman Numeral Analysis would be bII if you are not modulating because that's how Roman Numeral Analysis communicates.
Thinking about Phrygian mode. The two is always a bII.
{0} As an aside, in The Common Practice the bII is often notated N6 (for Neapolitan 6th) to set up a perfect cadence, i.e. I-N6-V-I.
Nothing requires an ESOP to skip on a separate retirement fund for employees and expect them to retire from their share of the investment.
In the contrary, I expect the owners of an ESOP are very much in favor of having a well managed separate employee retirement fund. More so than in a publicly owned company.
But of course you are right that the risks factors of losing your income and losing your investment are pretty much 100% correlated for an ESOP. Some investment diversification is always a good idea.
