chalmerlowe/jarvis_ii

Data Analysis Tutorials created by The Dark Art of Coding

jarvis_ii's Issues

organize the sample puzzles... easy medium hard.

organize the sample puzzles... easy medium hard.

right now, there is no organization to the puzzles. need to reorg them in loose groupings of easy, medium and hard.

• easy: generally can be completed in 5-10 lines using no imports, no special tricks, no extensive logic or sophisticated algorithms
• medium: generally one import, read in data from a file, manipulate via multiple steps
• hard: generally one or more imports, read in data from multiple files, manipulate via multiple steps, heavy on the logic/algorithms

Rising/Falling tokens not evenly distributed RE: sample_puzzle 30

So right now, the code for making rising/falling tokens looks something like this:

def rising_falling(n=6, rising=True):
    '''Return a sequence of numbers that are rising (each subsequent number is
    equal to or larger than the previous number) OR falling (each subsequent
    number is equal to or smaller than the previous number).
    '''
    
    token = []
    if rising:
        current = 0
    else: 
        current = 9
    for digit in range(n):
        next = randint(0, 9)
        if rising:
            while next < current:
                next = randint(0, 9)
        else:
            while next > current:
                next = randint(0, 9)
        token.append(next)
        current = next        
    return token

I ran this 1000 times and I noticed the least significant digits of each token tend to group up around 0 if the token is falling or 9 if the token is rising. e.g. 199999 459999 999999 100000 320000 440000 I think this is due to the fact that the range of possible digits is randomly constricted in one direction on each iteration. If there were some way to make a weighted choice in which randint is more likely to pick a value closer to current we would have a larger variety of rising/falling tokens.

Ambiguous definition of rising/falling tokens RE: sample_puzzle 30

I noticed that based on Chalmer's definitions of rising and falling numbers, 111111 could be generated by a makeRisingToken function or a makeFallingToken function. I just now noticed that it could also be generated by either of the palindromic token constructors. Maybe the definition should be changed? I'm not sure if that's supposed to be part of the puzzle or not. Here's Chalmer's definition:

rising numbers (each subsequent number is equal to or larger than the previous number)

falling numbers (each subsequent number is equal to or smaller than the previous number)

We could add a sixth category called "Super Number" which has all the properties of all the other categories put together.