"Bottomest vs toppest lines of the graph correspond to the range of an octave, so it’s important to accurately frame your grid then avoid scaling and translating the graph. Using numerical grid setting is the most robust way. Then, the 12 steps within this range correspond to the half-tones in the music scale. Of course you may try continuous variations too !" can u parse what this means, and how i can use this to make C?
@hyper-neutrino You might be able to use a sine wave generator at tbe same time on the same computer, which causes interference and makes a beat frequency
But yeah, if Y was 0 to 12 an increase by 1 would be the difference between A and B. If you had it go from -12 to 12 an increase in 1 would be the difference between A and A#, if I'm reading that right
Input variables:
(Names are just examples, they don't need to be named like this)
GrandTotal - integer to divide
SplitCount - number of output integers required
UpperLimit - highest valid value for any one output integer
LowerLimit - lowest valid value for any one output integer
Valid Output:
T...
using - to indicate that the previous note should stay held down through this beat as well:
actually i don't need to. going off of my previous message, every note is the same length except the ones before the comma are twice as long (and the last note)
> Advent of Code is an annual set of Christmas-themed computer programming challenges that follow an Advent calendar. It has been running since 2015. The programming puzzles cover a variety of skill sets and skill levels and can be solved using any programming language. Participants also compete based on speed on both global and private leaderboards.
it's a competition in which you stand no chance so 99% of people just do it for completion bragging rights
do aoc in desmos
each year's problems remain indefinitely open if you want to get a feel for it doing those
it's the project euler style of you just have to stick a numeric answer in a box (though your inputs are personalized here) so desmos would only be a problem to the extent that some of it could be less than convenient to implement
having limited, say, i/o facilities could actually be an asset psychologically in some odd circumstances
i remember there was one star in whatever the intcode year was where they actually gave you one of those brick breaker games and i spent like ten minutes actually playing it before i realized i could just automate keeping the paddle under the ball
yep, each day for 25 days there are two parts released, you need to solve the first half to unlock the second one, except day 25 part 2 is a freebie for all of the years so far
(correction: day 25 part 2's requirement is "have the other 49 stars")
or i can just sleep late; i almost always either finish within the first hour or am too late for leaderboard anyway and just give up and wait until the following day to do it
yeah speed of coding is the main metric but you need to know how to optimize and write efficient solutions otherwise your runtime will just be too long to compete (or even complete in a sensible amount of time)
let there be a grid of cells of N rows and M columns
there is a rat in the top-left corner and it wants to get to the bottom-right corner and it can only move one cell down or one cell to the right at each time
in K of these cells, there is a cat, meaning the rat may not pass through that cell
how many unique paths can the rat take?
exact I/O format does not matter but give this a shot and let me know what you come up with
and so the core idea here is that if we have solutions for smaller subsets of the problem, we can find the solution - in this case, if we know f(x - 1, y) and f(x, y - 1), we can compute f(x, y), and so starting from a base case (in this case, f(1, 1) = 1 and f(x, 1) = f(1, y) = 1 (unless there is a cat cage in that cell or above/to the left)), we can "build up" towards the final answer
a similar problem would be the fibonacci sequence - to calculate F(n) we do F(n - 1) + F(n - 2), but if you did it recursively (without memoization), it would take exponential time because you are recomputing values
you could cache, but the idea of dynamic programming would be F(1) = F(2) = 1 and then you iterate forwards (rather than recursing backwards) to then calculate F(3) = F(2) + F(1), then F(4) = F(3) + F(2), etc. which is linear
DP is definitely a pretty difficult concept to fully understand but if you'd like some practice with it you can look for problems with the DP problem type on DMOJ here and feel free to ask any questions here
yeah, identifying what approach to take is usually a significant part of the challenge
if you can identify a way to generalize the solution to a sub-solution (in this case, "get the total number of paths" is a specific form of the more general "get the number of paths to (x, y)") and break down each sub-solution into smaller parts, DP is potentially viable
@AidenChow no
the weakness of DP is that you compute every possibility when sometimes you need very little of your search space
ok huh i thought dynamic programming was just "backwards" recursion, where u start building off from base cases instead of going to base cases, is that the wrong notion
i felt like that was the case when i was making recursive solution vs dp solution for hyper neutrinos cat/mouse problem
recursion is just too time and space consuming even with memoization so DP is usually better when it can be used
so like
with the cat and mouse problem, recursion is able to get you a correct answer theoretically but in practice you'll just blow your stack
and for example with the chemistry-themed problem i linked you, some recursion problems cannot be solved via DP
thinking of DP as inverted recursion can be a helpful analogy but it is not actually just "reversed recursion" and thinking of it that way is something i'd recommend avoiding
it helped me understand what DP is and how to use it correctly but it's really a misrepresentation of what it is lol
@AidenChow DP is just DP - finding a way to break your problem into subsections where each sub-solution can be used to solve a slightly larger sub-solution, which can be used to solve a larger one etc. until you build up to the answer
with recursion you start at your final state and select specific sub-states to recurse to to compute
anyway, whether or not DP is reversed recursion isn't really all that important since you're right that it does seem like that and if it's easier to understand the approach that way then sure that's fine, it's just important to know that DP does not make recursion useless and the two have their strengths and weaknesses / problems that they can't be used on, and it's not always "DP > recursion"
@hyper-neutrino makes sense, tho the problem i think im gonna face is like, i know i need to do recursion for a particular problem, but is dynamic programming or regular recursion better.
DP is good if your solution will need every possible sub-state
recursion is good if your solution may handle really large values but only needs a few select values (for example if you have something like F(x) = F(x / 2) + F(x / 3) then it would be really wasteful to use DP which would calculate far more values than you need)
yeah this all makes sense, but i feel like its gonna be hard to reason this out in practice for someone as unexperienced like me (especially since i just learned about DP lmao)
