Add exercise knapsack

[siebenschlaefer]

Please feel free to comment and critique anything.

[ynfle]

Suggested change

	var dp = newSeq[int](maximumWeight + 1)
	var dp = newSeq(maximumWeight + 1)

I don't think this is needed

[siebenschlaefer]

Great, happy to make the change.
Do you happen to have a link to a resource where I can learn when I do and do not have to specify the template parameter?

[siebenschlaefer]

Now the five jobs of the CI fail. I will roll this back.
Maybe it's a version thing because on my computer with nim-2.0.0 I did indeed not need the template parameter.

[ynfle]

Weird!
I will try to take a look in the next couple of days

[siebenschlaefer]

@ynfle did you have the time to look at it?

[ynfle]

It was a mistaken suggestion. The [int] tells the compiler what is the type of the seq. It can not infer the type of the elements in the seq from the code because none of elements are given, yet

[ee7]

Suggested change

	type Item = tuple[weight: int, value: int]
	type Item* = object
	weight*: int
	value*: int

I think we should go with an object here, although it'll require some other changes.

To reduce the verbosity this would otherwise produce in the test file, I think I'd suggest adding a func there that takes an openArray[(int, int)] and returns a seq of Item. Thoughts?

[siebenschlaefer]

I'm not against this change, but as an inexperienced Nim programmer I want to learn:
Why do you prefer an object over a tuple in this case?

As for the verbosity: I don't think it's too bad currently but I'm fine with all the alternatives.

[ynfle]

For myself, the main reason to avoid tuples is because tuples are duck-typed. Consider the following example:

type
  a = tuple
    a: int
    b: int
  b = tuple
    a: int
    b: int
 
const
  c: a = (a: 1, b: 2)
  d: b = c

This would compile because a tuple just means a specific ordering of elements. The names of the field (or even if they have names) and the name of the type is not part of the type of the tuple.

The equivalent code for objects, however, would not compile because, even if they do have the same field names and types, because they are 2 different and separate definitions.

This can lead to confusion.

Consider a tuple representing an RGB color and a point in 3-D space. They are interchangeable with each other but don't represent equal values. An object, however, is not interchangeable as such and is therefore not subject to being mistakenly converted

[siebenschlaefer]

I agree, tuples can be problematic if they get constructed without field names or accessed with an index: With (12, 34) it's not immediately obvious which of the two is the weight and which the value, and item[1] doesn't tell the reader that it accesses the value.

But otherwise, frankly, I'm not convinced: The two tuples in your example can only be assigned to each other because they have the same number of fields, with the same types and names.
If I have an RGB color tuple[r, g, b: int] and a 3D point tuple[x, y, z: int] they are not interchangeable because their fields have different names.
And wouldn't that argument apply to all uses of tuples, anywhere?

But I'm OK with making them objects if you think that's better. The only downside would be that the tests would need the typename for each construction of an Item.
Creating a helper function would allow us to shorten that but wouldn't we bring back the ambiguity in return?