Am I understanding this correctly that dynamic programming == breaking a problem into smaller (reoccurring) sub-problems and using caching to improve performance?
this post was submitted on 14 Jan 2024
28 points (86.8% liked)
Programming
17492 readers
28 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
It's slightly more nuanced than that, but you've got the basic idea.
The caching is kind of mandatory as the sub-problems interact.
That is conceptually how dynamic programming works, but in practice the way you build the cache is from the bottom up rather than from the top down. It's a bit like how you can implement computation of the Fibonacci sequence in a top-down manner using a recursive function with caching, but it is a lot more efficient to instead build it in a bottom-up manner.
“Daemon”, for a process that is detached from your terminal
That's factually incorrect. Daemons are often spawned from "early" processes whose ancestors are not TTYs.
“Cascading Style Sheets”, just to mean that properties can be overridden
This one is really wrong too. But I think his overall point is made clear by other examples. Nomenclature tends toward jargon in software culture.
But that's true in any field.
No, seriously. Article probably means background processes. Maybe aplies to session-daemons or user-daemons. Other daemons (udev, logrotate) were started long before there was any shell.
The only application I can still remember is the backpack problem