Uphill Task

[E7-87-83]

Greetings to all teammates.

Do you want to have an extra-challenging task each month? Or, do you accept coding extra lines in order to solve an interesting task once a month?

Do you know an algorithm from your computer science study, would like to share with TWC teammates, but thought it might be relatively heavy? Or, do you like to share a practical technique or procedure applied in some widely-used Perl frameworks? Why don't propose the idea as a TWC task?

Or, has an intriguing question just popped in your mind? You simply want to share it.

It is Week 135 of the TWC Calendar and 287 tasks have been appeared. Different algorithms commonly-learnt by computer science students or programmers have been used in the vast amount of solutions. Sometimes some advanced algorithms or data structures were being used. Regular participating teammates may have an expectation of the demand(difficulty, lines needed, number of test cases) of the tasks and arrange a time-slot in their planner to solve the tasks. And some techniques have been used again for the third time and you might want to code more stuff in that week.

Secretly(?), I am a distance runner. Uphill training is a demanding but beneficial workout in distance running. Since it is so demanding, most leisure runners do not put this workout in their usual schedule, or take the workout less frequent than other types of workout. However nobody declines the benefits of uphill training brings. And usually you will have a great sense of satisfaction when it's done!

So, why don't accept AN EXTRA WORKLOAD coding challenge task regularly?

---

I suggest having an "Uphill Task 2" in the 2nd week of each month.

It can be fun:

• create an engine to solve a traditional board game;
• code about something that professional mathematicians in number theory haven't solved. (I just come up with one such kind of coding puzzles, but not to share here in order to keep with the discussion.)

It can be practical:

• interact with a database;
• apply support for a famous framework in Perl;
• design a mini-app according to the requirements;
• something like API tasks on Week 008 to Week 024 but more sophisticated.

It can be pedagogical:

• craft a simplified interpreter;
• simulate a Turing machine;
• introduce an advanced data structure or algorithm.

What do you think about "having an 'uphill task' in The Weekly Challenge once a month"? Would you think that it is better to make the "uphill task" as a "Task 3"?? (But a bit increase in administrative workload.) Do you have any related suggestions? :)

P.S. For an example of what an "uphill task" might look like, N Queens of Week 062 (Week 062 , RECAP) should be a candidate. Or you get other candidates. (I still like the Adventure of Knight, which I proposed, hahaha.)

-- from CY

[adamcrussell]

@E7-87-83 and I discussed this on Discord. some ideas from that discussion

• make the uphill challenges run for, say, a month
• understanding that this may add some extra administrative burden, it would be required to identify a volunteer to assemble and review the solutions, and even suggest the problems
• I'd be OK with suggesting some problems of this type to consider
• This could be a nice way to promote things such as SDL's Perl bindings for game development

@manwar Obviously none of this happens without your acceptance! I am not aware of all considerations involved, but can certainly try to help smooth anything out if I can.

[E7-87-83]

This is modified from a task 2 suggestion. Given a longer duration for coding, it would provide more fun and possibilities.

Uphill Task (Suggestion): Peg Solitaire

Write a script to solve a peg solitaire automatically and print out the movements.

Peg Solitaire is a game that a peg (denoted by "." below) can jump over another one peg into a hole, vertically or horizontally. The jumped-over peg will be removed from the board.

For the sake of flexibility, a movement of the peg going to one of its (usually 4) adjacent positions which is a hole (described as "translation" below), is also allowed in this task.

The traditional English setup for the peg solitaire is:

     . . .
     . . .
 . . . . . . . 
 . . . o . . . 
 . . . . . . . 
     . . .
     . . .

We are going to use a 7 × 7 square board as the board for the basic requirement of this task, and the starting board goes with a hole located at the center (thus 48 pegs initially).

The goal of the game is, after a series of jumps and translations, leaving only one peg on the board.

You may invent your notation or use the following notation:

 A B C D E F G 
 H I J K L M N
 O P Q R S T U
 V W X Y Z a b
 c d e f g h i
 j k l m n o p
 q r s t u v w

Example Starting board:

 . . . . . . .   
 . . . . . . .     
 . . . . . . . 
 . . . o . . . 
 . . . . . . . 
 . . . . . . .  
 . . . . . . .  

After the first action(jump) (KY):

 . . . . . . .     
 . . . o . . .   
 . . . o . . . 
 . . . . . . . 
 . . . . . . . 
 . . . . . . . 
 . . . . . . . 

After the second action(jump) (TR):

 . . . . . . . 
 . . . o . . .    
 . . . . o o .  
 . . . . . . . 
 . . . . . . . 
 . . . . . . . 
 . . . . . . . 

After the third action(translation) (LS):

 . . . . . . .  
 . . . o o . . 
 . . . . . o .    
 . . . . . . .  
 . . . . . . . 
 . . . . . . . 
 . . . . . . . 

After the fourth action(jump) (RT):

 . . . . . . .  
 . . . o o . . 
 . . . o o . .    
 . . . . . . .  
 . . . . . . . 
 . . . . . . . 
 . . . . . . . 

Basic requirement: (1) Write a script to complete a 7 × 7 square peg solitaire game. It need not output a minimal number of steps.

Extras:

(a) Write a script which completes the 7 × 7 square peg solitaire game with actions, the fewer actions the better.

(b) Write a script which completes the 7 × 7 square peg solitaire game with the fewer translations the better.

(c) Write a script which completes the traditional English peg solitaire game with jumps only.

(d) Write a script on a peg solitaire game with user-defined start setup in the 7 × 7 square board, and complete the game with the fewer translations the better.

(e) "Counting multiple jumps (of a same peg) as single moves", and minimizing number of moves, code (a) to (d) again. A complete and minimal solution of the traditional English game is provided on English Wikipedia page (https://en.wikipedia.org/wiki/Peg_solitaire).

[Abigail]

I don't mind having more challenging exercises (many of the current challenges are quite trivial). However I don't fancy all of the suggestions.

Database related stuff, is, IMO not appropriate. This would require people to set up a database, just to test out ones solution.

I would also have little interest in particular frameworks or SDLs. That feels too much like being shoehorned into a certain direction -- the challenges are supposed to be fun, not feel like work.

[adamcrussell]

My suggestion for things like SDL is coming from the perspective that PWC is something of a nice promotional opportunity for Perl. Certainly nothing else in recent memory has served to create so much positive content and blog posts and overall friendly discussion.

Sure, some people may find an SDL challenge to be work like. Others may find it a nice motivation to try something out. A dozen new small game programming examples in Perl would be the sort of thing that pays dividends down the road.

Also, if these bigger challenges are supposed to take a couple of weeks or a month then it seems, in my experience, that a good model for that is having a base problem (like make a simple game) and then extras that allow for people to explore new directions such as an adversarial AI for a computer opponent.

If an SDL challenge feels like "work" I fear that something a little less playful, like implementing an interpreter for some small language might feel too much like a university assignment for other people.

This point of discussion is premature. If there is sufficient acceptance of this proposal than give it a little time, maybe 2-3 iterations, with different styles of problems and measure engagement. If the idea takes off in any way, then great!

[adamcrussell]

@E7-87-83 I like the peg challenge idea. There is a lot of different directions that can be taken in while still solving the core requirements of the challenge.

That is one of the subtle things that makes PWC so much fun, the interpretability of the challenges sometimes. At first reading the challenges may be seem straightforward but often there is opportunity to stretch things a bit like "oh, hey, I'll parallelize this with threads just for the heck of it!".

[LaurentRosenfeld]

I agree with Abigail's comments. I'm not very much interested in setting up a database just for the sake of a coding challenge. I also have little interest in having to use a framework.

[Abigail]

The "problem" with something like the peg challenge is that this has already been analyzed, and you can just grab the solution from the internet. The weekly challenge is already full of challenges like this: anytime when we're asked to generate the first N numbers from an OEIS sequence for instance.

The Adventures of Knight suffered from a similar problem: it doesn't take input, hence the program is expected to print a fixed output. And in the given problem, it was much easier to show what the optimal path was than to write a program doing the calculations. IMO, such problem aren't much of a challenge -- they're just glorified "hello world" programs.

But it's nearly December. Advent of Code is coming, with a challenge every day.

[adamcrussell]

@Abigail those are all fair points regarding how those specific problems might not be the best selections. I think the idea itself to have longer "marathon vs sprint" challenges has merit. To me it makes sense to just discuss that itself, and not get distracted by any specific details of the examples.

1. Should there be "uphill" challenges?
2. What would the first problem be?

If Mohammed agrees that the answer to (1) is yes only then proceed to examining (2) and suggesting some problems. That said, part of the answer to (1) maybe should be some guardrails such as "low external dependency requirements" and "problem statement should not be an obvious classic problem".