Is the algorithm run from scratch each time a seam is removed? I.e. energy function computed again on the resized image, all seams recomputed, then only the lowest energy seam is removed.. and repeat.
Or are all the seams from the first calculation used for resizing?
Good question. I talked about it in my previous article, but the gist is I compute the energy (or costs in this case), then use dynamic programming to find the new lowest energy seam each time. This allows a subsequent seam to pass through an earlier seam, as seams are found based on the latest images, where pixels have been pushed together from previous removals.
However, you'll notice that the costs are only changed in a small area around the removed seam, so if I optimized the process, I could avoid recomputing costs for the majority of pixels.
I'm using dynamic programming, but I'm still computing seams from scratch on each "frame" (each time I resize the image). Dynamic programming is useful for solving the seam finding problem on each frame, but it's an orthogonal concern to what computation can be saved on the next frame.
For illustrative purposes, I didn't optimize storing the cost data across frames, but that's something I could do.
For what it’s worth, I think I actually like the idea of mandating a 2-part namespace, as the way to force “long” names (where “long” means “with enough context to make forking easier and more obvious”). I just wanted to call out that “force namespacing” isn’t a silver bullet for the issue.
A better feature-add might be supporting dependency replacements. For example, pre-modules, Go had an issue where if you had a dependency and I forked it, I had to go through all my code and replace references to your import path with mine. If I depended on something that depended on you, I was out of luck (or had to vendor and regex or a variety of other hacks). Now, with go modules, I can do a “replace” in my go.mod and sub in my fork for yours. That has enabled me to be much more flexible with my use of forked repositories, and most languages don’t have a direct parallel.
Everyday people are “segregated” based on their wealth in some way. What area you can afford to live in, the car you drive, what restaurants you can afford to eat in, which fruits you can afford in the supermarket etc..
What makes housing special? Must social housing necessarily be located in one of the worlds most expensive areas in central London?
Are you criticizing capitalism in general？
I was referring to this specific case. In this housing example, extra infrastructure is being built for the purpose of segregating people. In your examples the segregation emerges less deliberately.
My previous implied question is still unaddressed. I.e. will this kind of segregation actually spur them on in a positive way, or is a negative effect possible (e.g. lowered self esteem, etc.)?
Interesting article and interesting opinion. I particularly like this quote: "Employers can get away with paying workers less when those workers don’t talk about money." I find it to be very true.
"he noted that some combination locks allow for wiggle-room and if this one had a three-digit leeway, Mr Rosenthal put the chances at 1 in 8,000, "which is still a small chance"."
If this is the case, and there have been museum visitors having a go at opening the safe each day... this becomes a non story, right?
It would be unusual not to check the performance of the model at predicting the target variable, which would validate whether or not the derived feature is useful.
Is the algorithm run from scratch each time a seam is removed? I.e. energy function computed again on the resized image, all seams recomputed, then only the lowest energy seam is removed.. and repeat.
Or are all the seams from the first calculation used for resizing?