akdas

> when I hire someone who isn’t fresh out of college, I only care about experience / interview skills / references

If everyone who _did_ hire fresh college grads gave preference only to those coming from exclusive schools, only those from exclusive schools end up with the experience, interview skills and references you look for. In this way, exclusivity perpetuates itself.

The best way to _actually_ focus on hiring for skill? Find those who haven't been given a chance before, such as not having attended a top-name school and subsequently didn't end up at top-name firms, then invest in them. It's more expensive to do, but a lot of the top talent doesn't have the experience, interview skills and references you may be looking for.

I must have missed the real-time adaptation of seam carving, so thanks for bringing it to my attention! I'll certainly take a look at it.

In the first paper, the authors discuss what happens if you take the lowest energy pixel from each seam. The problem is that visual coherence is not maintained, because there is no connection between the removed pixel.

What you're talking about--expanding the number of pixels the seam can move from row to row--is certainly possible. This will require more computational resources, as each seam can continue from five different seams (or more if you choose to widen your slope parameter). And, I'm not sure you'd get enough visual coherence from these types of seams.

That said, the best way for to know for certain to is to try it out!

You're absolutely right that RGB differences are not very meaningful to humans. I chose to stick with the easiest approach for educational purposes, but I'd love to hear if anyone tries out a different color difference function.

Note that the authors tried other types of energy functions in their original papers, ones that didn't simply use color differences. No one energy function seemed to be perfect across a variety of images.

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.

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.

100% agreed! I came at it from the angle of someone asking me about real-world applications of dynamic programming. DP is usually covered only in an academic setting, so there's one more plus for seam carving.

I just literally published an article on that yesterday :) https://avikdas.com/2019/06/24/dynamic-programming-for-machi...

Agreed, it's basically the same algorithm.

Thanks so much for pointing that out! I've updated the article.

> apply a facial detection algorithm, then boost the energy for the regions where faces are detected.

Great intuition! The original paper actually goes into this, and they come up with that solution.

This solution is a special case of allowing the user to apply positive and negative penalties as they wish. The latter allows targeted object removal.

The algorithm definitely has issues with faces.

One part I didn't get into is artificial weights. The original paper discusses "painting" certain regions of the image as high energy, driving seams away from those regions. This ties into faces when the paper suggests face detection to automatically paint faces with high energy, avoiding these issues in the first place!

> If you don't like programming and if you don't like learning, then are you really gonna like Google?

There are also many people who are great at programming, wh love it, who are terrible at interviewing. After all, these are two related, but ultimately different skills. You talked about it yourself in your last paragraph, ending with:

> But there's something wrong about having to play a game to get the job.

Sounds like the fault is on the employer that makes you play the game, not on "people want to be employed without becoming employable".

Glad I was able to reach you at the right time :)

You're absolutely right about figuring out the subproblems and the recurrence relation. I've found that knowing how you're going to use the recurrence relation is a first step to coming up with the right relation. For example, knowing you'll cache the results in a table means you're on the lookout for a function that has integer inputs, because you want the values to be indexed and ordered.

After that, as you said, practice is key. I'm working on a follow-up article that'll show some tougher examples, which should help provide more exposure. Forget three sub problems; one problem, the chain matrix multiplication problem, uses O(n) subproblems!

Hi, author of the article here.

I'm definitely a fan of structured education. After all, what I learned about DP I learned from a fantastic college course. Glad to hear there are online resources for people to get that kind of education, so thanks for sharing!

Hopefully, an article like mine can help those who are not able invest in more lengthy study, or just need an additional perspective.

This is awesome! One thing I really appreciate is building up the mathematical concepts. For example, instead of providing a ray-sphere intersection formula, the tutorial talks about representing a ray and a sphere, and how the two representations must match at intersection points.

When I was asked to teach a workshop on computer graphics, I wanted to make the concepts accessible to those who were either rusty, or hadn't even encountered the necessary math. Given a limited amount of teaching time, I introduced only the most relevant math, but did so from first principles. Hopefully my treatment can be useful to others: https://avik-das.github.io/build-your-own-raytracer

I haven't even looked at the git source code. My implementation was based mostly on the official docs. The docs include a section on the internals: https://git-scm.com/book/en/v1/Git-Internals

I love to see people reimplementing existing tools on their own, because I find that to be a great way to learn more about those tools. I started on a Git implementation in Rust as well, though I haven't worked on it in a while: https://github.com/avik-das/gitters

> what drives the majority of lurkers that are the majority of said growth?

Not the author, but my take on it: since status is a scarce resource, the majority of people are not able or willing to put in the work to acquire status. Instead, they live vicariously through the status of others.

This is part of an ongoing series where I'm documenting everything I'm learning as I create a heads-up display on my Raspberry Pi. Because I was using the Pi as a server before, I didn't want to install a full desktop environment just for one application. This in turn has taken me down a path of learning more about building lightweight applications, and I wanted to share what I've learned with others.

Note: I've been publishing to Medium and mirroring on my own blog until I get the styling on my blog worked out. I know folks on HN aren't big fans of Medium, so I submitted the version on my blog.

Original medium link in case the styling on my blog has issues: https://medium.com/@avik.das/creating-raspberry-pi-applicati...

Scratchapixel is a really comprehensive resource. I referred to it frequently while working on a 2-day workshop on writing a raytracer.

What I've always found missing are resources that cover both the foundational theory and the implementation details, in a way that connects the two ends. That's why, when developing that workshop, I created a resource that goes over the theory of raytracing--including the relevant math--and walks you through a series of practical projects.

I put up the resource online: https://avik-das.github.io/build-your-own-raytracer

The page also links to two reference implementations in Java and Javascript, so learners can follow along.

I'll plug the materials for the one-weekend class I taught on computer graphics: https://avik-das.github.io/build-your-own-raytracer/

I didn't assume a particular mathematical background for the students, so I introduced the relevant math in what I hope was a motivated way. Hopefully it can help others as well.

Oops! I searched for the article, then picked one of the results. I didn't realize the one I linked wasn't the original because I only looked through it enough to make sure the right content was present.

Thanks for the correction!

Timings are usually documented as well, usually at the clock cycle level.

Beyond that, you have to worry about hardware peculiarities that happen to affect maybe a few games, and at that point, you might start reverse engineering the behavior of those games!

Take a look at this article talking about exactly those thinking issues: https://www.tested.com/tech/gaming/2712-why-perfect-hardware...

> I understand a lot of it is the process of translating machine code from, say, the GB processor to x86, but I’d love to learn more!

You don't really need to translate to x86 per se. You can start off with an interpreter that takes in the 6502 or Z80 instructions (as represented by the binary data in the input ROM), then immediately perform operations based on those instructions. For example, if you're holding onto an in-memory representation of the GB registers, and you encounter an "add" instruction, you would perform the addition and update the registers.

And if you're writing the emulator in a high-level language, you never really think about x86 instructions.

The hard part, then, is timing. You need to make sure the different operations that would be happening in hardware--namely performing the CPU instructions, alongside audio and video operations that would normally happen "in the background"--happen in sync. But that's a later step after you start on your first prototype!

With only the functions you've defined, how do you calculate the second derivative?

If the `deriv` function instead returned a function instead of a number, you could apply the `deriv` function twice.

    Class foo = String.class;

(Though `Class` is actually a generic type, so you'd want to include the type parameter in actual code.)

I love the focus on implementation. That really connects the underlying ideas with working code.

For those interested in a gentle introduction to those underlying ideas, including a refresher on the required math, I taught a class on how to implement a ray tracer. All the materials are available: https://avik-das.github.io/build-your-own-raytracer/

And still I see folks in this thread rationalizing the behavior of companies, explaining how there's no discrimination happening and how age-related patterns are due to some form of "merit".

It's no surprise so many people deny the less overt racism and sexism!

For context, I agree with you that understanding compilers is very important to a deep understanding of the tools used by programmers. Knowing how languages are implemented sheds light into why certain design decisions are made and why certain language features behave the way they do.

That said...

> Also, compilers is a basic core course you have to take to get a CS degree. How is something everyone has to learn elitist?

Not everyone is lucky enough to get a CS degree.

Some people come from backgrounds where CS was not in their worldview growing up. Or they were discouraged from pursuing CS despite the subject being interesting to them. Or they tried taking CS, but they had to deal with external factors that prevented them from continuing.

To discount these individuals from making meaningful contributions to a programming endeavor is short-sighted. Their particular experience may allow them to be better at implementing the correct solution, even if they are not as strong of a programmer. Or they may be a very fast learner, and given more time and mentorship, they will learn about compilers, but they can be strong contributors until then.

I learned Vim after switching to Dvorak, so the Dvorak positions of hjkl are what I'm used to. I don't have to think about the key I pressed.