> Isn't that what everyone is doing, or are we Frenchmen the exception?
> For reference if the author reads this, we write the latin x exactly like the cyrillic х, i.e. reverse c, bottom-left to top-right diagonal, normal c.
I was taught script in the US and Italy as a child, and never learned it like this.
I write it with a descending curve, then go back and cross it with an ascending diagonal line when crossing t's / dotting i's/j's. Like this: https://www.youtube.com/watch?v=Cel3GtSOzow. I think that's pretty standard in English cursives.
Yes; I learned it that way as well but I was never able to write them smoothly or legibly. I consciously practiced cursive in adulthood and only then discovered the mirrored-c technique, which always looks right and flows far better. There are a lot of problems IMHO with the D'Nealian method that US pupils were prescribed, likely responsible for the huge backlash against cursive in general.
I had this argument with people working on VR headsets, where a physical parameter was designed to cover the 5th to 95th percentile. I had to point out that flat-out excluding 10% of the population is a pretty crappy starting point...
In most amateur imaging you can trade time for quality. By stacking enough images, satellite trails get averaged out of the final image.
Very high end amateurs get pissy about it because they paid a lot of money for high end equipment to minimize imaging times, but for the rest of us it’s not a huge impediment as we already needed lots of subframes to get high SNR anyways.
Averaging isn't the only option. It's possible to use other image-processing techniques which look at outlier values. This is way outside my area of expertise, but I believe sigma clipping is one of the standard go-tos, see:
This applies not only to satellite tracks, but meteors, cosmic rays, and other artefacts introduced into image capture. The techniques should be generally applicable, though for those who are specifically exploring transitory phenomena, this introduces additional challenges.
That’s an option. However, these satellites provide a predictable path so you don’t needed to detect them from image data. Which means you can even prevent them from showing up on long analog film exposures.
In balance, shorter exposures, stacking, and track-removal is technically easier.
Long exposures made sense when photgraphic plates were a scarce resource, and replacing them risked disturbing the observation.
Stacking is premised on the idea that individual exposures are cheap, and that noise tends to affect a small number of those exposures, in small regions. The same predictability of satellite tracks you name means that they can be removed through image processing rather than brute force (avoiding sky regions, physical masking, interrupting exposures during overflights, etc.).
And the other phenomena I mention (meteors, cosmic rays) are not predictable, and also degrade deep-space images.
Image processing is a great way to get clean pictures but takes you further from direct observation. You could if extremely unlucky remove a supernova from your image not just meteors and cosmic rays.
A supernova peaks over the course of days, and fades slowly over months to years. They also remain static relative to the background stars, as do all astronomical phenomena outside our Solar System, even over the span of a day.[1]
Even a very-rapidly-peaking kilonova (neutron-neutron star collision) though they peak quite rapidly (short gamma-ray bursts, or SGBs, last about two seconds) have durable remnants lasting weeks.
The transient phenomena discussed here occur largely at the scale of a few seconds at most, often far less, and most move across a significant span of sky within that time.
More likely is that a meteor impact on the Moon (or other Solar System body) might be missed, but those are sufficiently small targets that interference such as we're discussing would not be a significant noise source. Space-based observation of, e.g., comet collisions with Jupiter or Saturn would eliminate LEO satellite noise entirely, though cosmic ray interference would remain a concern.
________________________________
Notes:
1. An object moving at 0.99c at the distance of the nearest star, 4 light years, would cover slightly less than 0.04 degrees per day. Much of the Universe is at somewhat greater distance than even this.
You’d be amazed what even a small smart telescope can see even in Bortle 9 urban skies.
I have one of the mentioned SeeStar smart telescopes, and have been quite successful in taking photos of both galaxies and nebulas from the rooftop of my apartment building in the middle of a city.
Sure, it takes time. Sure, it would be faster/better under darker skies. But it’s not impossible!
iTelescope does exactly what you’re outlining. There used to be a few others but I think they have mostly died out. I assume the economics don’t really work out.
It feels like a relatively small market niche, they're aiming for people interested enough in astronomy to pay for telescope time but not interested enough or unable to own their own scope in either their back yard or at a remote dark sky site.
Also also, AMD’s play has always been to produce HW that offers good performance/$, with the downside of having much weaker SW offerings to go with it.
Consoles are always pressured to minimize upfront purchase costs, and they generally replace the vendor-provider SW stack with their own anyways.
And they’ve been in a rough spot at various times in the past, which probably made them willing to negotiate with the console companies.
Actually looking at this thread, there’s a lot of good reasons they were the go-tos for consoles. Consoles seem to be in rough shape at the moment, I wonder if part of that is that AMD has been doing too well since Zen, haha.
> It might be that regalloc needs to be taught to rematerialize
It knows how to rematerialize, and has for a long time, but the backend is generally more local/has less visibility than the optimizer. This causes it to struggle to consistently undo bad decisions LICM may have made.
> but the backend is generally more local/has less visibility than the optimizer
I don't really buy that. It's operating on SSA, so it has exactly the same view as LICM in practice (to my knowledge LICM doesn't cross function boundary).
LICM can't possibly know the cost of hoisting. Regalloc does have decent visibility into cost. Hence why this feels like a regalloc remat problem to me
Sure. Any pass that is scoped to functions (or even loops, or basic blocks) will have increased scope if run after inlining, and most passes run after inlining.
In the context of this thread, your observation is not meaningful. The point is: LICM doesn't cross function boundary and neither does regalloc, so LICM has no greater scope than regalloc.
Really? I read the same sentence (as an American) and immediately thought that they must be referring to British English. Certainly nobody says brilliant as an affirmation here.
And "no problem" and "not bad" are both common colloquial statements in American English.
Apple has neglected the iTunes store for years. Yes, you can still buy tracks, but it's really crappy. 1) The catalog is nowhere near as extensive as Apple Music. 2) It's AAC 256kbps format only. Not lossless.
Apple goes along with the enshitification of everything and wants you to rent your music, not own it.
I was taught script in the US and Italy as a child, and never learned it like this.