Two Plus Two Poker Forums - ** Python Support Thread **

Page 7 of 30

Show 100 post(s) from this thread on one page

Two Plus Two Poker Forums (https://forumserver.twoplustwo.com/)

- Computer and Technical Help (https://forumserver.twoplustwo.com/48/computer-technical-help/)

- - ** Python Support Thread ** (https://forumserver.twoplustwo.com/48/computer-technical-help/python-support-thread-1007515/)

kerowo

07-03-2011 08:35 PM

Re: ** Python Support Thread **

And when you get to teach at MIT you may be able to do that too... Until then, learn how the debugger works like the rest of us just in case. :)

Neil S

07-03-2011 08:40 PM

Re: ** Python Support Thread **

Heh, it doesn't surprise me a bit that an MIT Professor is saying something like that. When you're doing research, you probably don't have to worry much about memory management, error conditions, users, and all the other things that make us in the real world have to use debuggers.

kerowo

07-03-2011 08:42 PM

Re: ** Python Support Thread **

They can also spend half a day typing print statements instead of producing code...

TheIrishThug

07-03-2011 10:37 PM

Re: ** Python Support Thread **

MIT is one of the most theory oriented schools in existence. I work with a couple of people that got their degrees there and they said, "If you really wanted to, and planned your classes right, you could graduate without writing any code."

Neil S

07-03-2011 10:42 PM

Re: ** Python Support Thread **

And I can respect that because computer science is a valid and useful field.

But so is software engineering.

daveT

07-03-2011 11:40 PM

Re: ** Python Support Thread **

I did watch the first lecture of the second class. According to them, computer science is not a science, nor does it deal with computers.

I ended up agreeing with the professor.

Next time you talk to the MIT guys, ask them if they know how to use a debugger. :p

Neil S

07-04-2011 12:49 AM

Re: ** Python Support Thread **

Ah, the question of whether math is a science. That's an interesting one. Pointless, but interesting to debate I'm sure.

Max Raker

07-04-2011 08:43 PM

Re: ** Python Support Thread **

Quote:

Originally Posted by daveT (Post 27428481)

I did watch the first lecture of the second class. According to them, computer science is not a science, nor does it deal with computers.

Computer science is no more about computers than astronomy is about telescopes...

ralu	07-05-2011 02:54 AM

Re: ** Python Support Thread **

Quote:

Debuggers don't remove bugs. They only show them in slow motion.

I found that using print function is much faster debugging cycle in python than debugger, but i am writing programs up to 1k lines.

ArturiusX

07-05-2011 12:17 PM

Re: ** Python Support Thread **

Quote:

Originally Posted by daveT (Post 27426436)

This'll rankle some posters here:

For at least four decades, people have been building tools called debuggers. Things to help you find bugs. And there are some built into Idol. My personal view is most of them are not worth the trouble. The two best debugging tools are the same now that they have almost always been. And they are the print statement, and reading.

-- Prof. John Guttag, MIT

Debuggers are print statements with reading, just splitting and organising them automatically. They are the same thing, at an essence.

ArturiusX

07-05-2011 12:20 PM

Re: ** Python Support Thread **

Quote:

Originally Posted by daveT (Post 27208849)

This code does exactly what I want it to do, but I wonder if there is a simpler solution to this problem. I'm also wondering if there is a different solution to this problem that I didn't catch.

The idea is to find all the values of n via n = 6a + 9b + 20c. I created an ascending list with no repeating values. The program runs pretty slow, but I guess that isn't too surprising since I am running 3 simultaneous loops, checking vs an if, creating a list, sorting the list, then minimizing the list.

Considering the problem set, I could use a smaller value than 150. I ran it with 50 as well, but it is still slow.

I'm not sure why you're using sets here. Why do you need to format your data into an unordered collection?

tyler_cracker

07-05-2011 01:25 PM

Re: ** Python Support Thread **

Quote:

Originally Posted by ArturiusX (Post 27450948)

Debuggers are print statements with reading, just splitting and organising them automatically. They are the same thing, at an essence.

this is not very accurate. print statements aren't very useful for setting breakpoints, inspecting state, and then continuing execution. they don't allow you to change values in the running program.

another way to look at it: text editors are typewriters with a cursor, splitting and organising text automatically. they are the same thing, at an essence. right?

Neil S

07-05-2011 03:16 PM

Re: ** Python Support Thread **

Yup. I'd love to see a print statement that will let me pause the program, overwrite memory as I choose at runtime, then resume the program.

pokergrader

07-06-2011 01:35 AM

Re: ** Python Support Thread **

Python does have a nice interactive debugging console built in:

Code:

import code



def func(a, b):

    code.interact(banner='', local=locals())

    return a + b



print 'Program is starting'

print 'Function is now executing: %s' % func(1, 2)



----------



$ python test.py 

Program is starting



>>> print a

1

>>> print b

2

>>> ^D

Function is now executing: 3

daveT

07-06-2011 05:38 AM

Re: ** Python Support Thread **

I about freaked out. I came across a problem where I had to return several values (320 to be exact) from one function, and I couldn't for the life of me figure out how to return more than one result. I was really mad at myself because I either did this before and completely forgot, or I "learned" to do this, but I forgot, but after some research, I found out that I actually never been exposed to this.

I found this SO thread inspiring, though useless because it talks about dealing with say two or three items:

http://stackoverflow.com/questions/5...rom-a-function

I think that this is an interesting problem set because it deals with some of the list/tuple questions people itt ask about, exposes my short-coming as a thinking programmer, and of course, introduces a complete headache.

and on to the yucky spoil tag for #8:

Spoiler:

The problem set gives me a set of strings that is (truncated):

2.00,5,9
2.01,2,2
2.02,1,17
.....
24.17,8,17
24.18,6,9
24.19,4,18

I am supplied with this function:

Code:

def printSubjects(subjects):

    """

    Prints a string containing name, value, and work of each subject in

    the dictionary of subjects and total value and work of all subjects

    """

    totalVal, totalWork = 0,0

    if len(subjects) == 0:

        return 'Empty SubjectList'

    res = 'Course\tValue\tWork\n======\t====\t=====\n'

    subNames = subjects.keys()

    subNames.sort()

    for s in subNames:

        val = subjects[s][VALUE]

        work = subjects[s][WORK]

        res = res + s + '\t' + str(val) + '\t' + str(work) + '\n'

        totalVal += val

        totalWork += work

    res = res + '\nTotal Value:\t' + str(totalVal) +'\n'

    res = res + 'Total Work:\t' + str(totalWork) + '\n'

    print res



subjects = loadSubjects(SUBJECT_FILENAME)

printSubjects(subjects)

That with the help of my code, will print out:

>>> subjects = loadSubjects(SUBJECT_FILENAME)
>>> printSubjects(subjects)
Course Value Work
====== ==== =====
10.00 1 20
10.01 2 20
10.02 1 16
10.03 6 19
10.04 3 13
10.15 8 13
[... TRUNCATED ...]
9.16 9 10
9.17 9 11
9.18 7 16
9.19 9 9
Total Value: 1804
Total Work: 3442

So the code that I output via my own function should print out. I assume this from the mouthful they asked for and the fact that it somewhat works:

{'2.00': (5, 9)}
{'2.01': (2, 2)}
{'2.02': (1, 17)}
{'2.03': (6, 1)}
{'2.04': (3, 2)}
{'2.05': (2, 2)}

.... and of course, I end up with this output via the helper code:

Course Value Work
====== ==== =====
24.19 4 18

Total Value: 4
Total Work: 18

>>> ================================ RESTART ================================
>>>
Course Value Work
====== ==== =====
2.00 5 9

Total Value: 5
Total Work: 9

So at least I am getting the stuff to output somewhat correctly, but of course, the problem is that I can't figure out a good way to send over all the stuff.

The commented out stuff is stuff that I tried, and this is not exactly a completed code:

Code:

# The following sample code reads lines from the specified file and prints

    # each one.

    inputFile = open(filename)

    #t = ()

    t = []

    for line in inputFile:

#erase \n and convert string to tuple (quoted string, lol).

        line = str(line).strip('\n').split(',')

#convert the first elements in each tuple to a dictionary key.

        r = line[0]

#convert the second and third elements to integer key values represented as tuples.

        s = int(line [1]), int(line[2])

#create the actual dictionary

        d = {r:s}

#create a tuple

        #t += d,

#create a list since tuple idea didn't work too well.

        #t.append(d)

#Heck, why not try this list conversion, too? 

        #t += d

#the helper code does not accept tuple or lists as my answer.

    #return t

        return d 

    #return d

So, I was thinking something along the lines of:

[code]
x += 1
return t[x]

[code]

I used something like this before, but that is a wholly different problem. This would would return only the first element and put me back to where I started.

I just looked over this and I realized I hadn't tried to create a string of dictionaries. Is that even possible?

daveT

07-06-2011 05:43 AM

Re: ** Python Support Thread **

I am not too ashamed to say I haven't done much with the debugger yet. I opened the thing up and saw

__main__ and other stuff and got intimidated.

I guess the pressure hasn't been to strong since I haven't written a 10000000 line program, but I'll get to the tutorial on this soon enough.

I posted that teacher comment tongue-in-cheek, obv.

The other advice he gives is the walk away for two hours and come back with a fresh set of eyes, since if you are debugging for 1hr/58m, you aren't saving any time at all. I'm sure the interviewers and management would be very happy to hear that one.

kerowo

07-06-2011 08:16 AM

Re: ** Python Support Thread **

When I was in school for {gasp} COBOL it was very common to stare at a chunk of code for a long time not seeing the problem. Which usually was a missing piece of syntax. These were usually spotted on the first read through when someone else looked at your code. There is something to be said for fresh eyes. At work there is usually something else you can be doing instead of banging your head against the code.

Neil S

07-06-2011 08:38 AM

Re: ** Python Support Thread **

It was a lot harder to spot syntax issues in the days before editors would turn our code into fruit salad.

daveT

07-06-2011 10:39 AM

Re: ** Python Support Thread **

False alarm on my issue. At least missing the obvious sometimes presents tons of new information (outside of showing how little I know). But still, i prefer pounding the keyboard like a robot.

tyler_cracker

07-06-2011 05:01 PM

Re: ** Python Support Thread **

dave,

not a ton of time so i'm not going to give your post a colonic or anything, but a few comments (some of which might even be useful):

Quote:

Originally Posted by daveT (Post 27465527)

I found this SO thread inspiring, though useless because it talks about dealing with say two or three items:

for most software problems, once you've solved it for two or three, you've solved it for N.

Quote:

Code:

    subNames = subjects.keys()

    subNames.sort()

this is one of the things about python that drives me nuts. keys() is a method that returns something related to the object, but sort() is a method that acts on the contents of the object and returns nothing. how am i supposed to know this? i just have to remember it. this violates the principle of least surprise and, y'know, drives me nuts.

ruby has a simple and elegant way to deal with this problem. the sort() method returns an array containing the sorted elements. if you want to do the sort in place, you have sort!(). the ! notation is simple and consistent throughout the language, a beautiful thing.

Quote:

So the code that I output via my own function should print out. I assume this from the mouthful they asked for and the fact that it somewhat works:

{'2.00': (5, 9)}
{'2.01': (2, 2)}
{'2.02': (1, 17)}
{'2.03': (6, 1)}
{'2.04': (3, 2)}
{'2.05': (2, 2)}

you aren't packing the values correctly, so the consuming code gets confused, leading to erroneous output.

Quote:

Code:

# The following sample code reads lines from the specified file and prints

    # each one.

    inputFile = open(filename)

    #t = ()

    t = []

    for line in inputFile:

#erase \n and convert string to tuple (quoted string, lol).

        line = str(line).strip('\n').split(',')

#convert the first elements in each tuple to a dictionary key.

        r = line[0]

#convert the second and third elements to integer key values represented as tuples.

        s = int(line [1]), int(line[2])

#create the actual dictionary

        d = {r:s}

#create a tuple

        #t += d,

#create a list since tuple idea didn't work too well.

        #t.append(d)

#Heck, why not try this list conversion, too? 

        #t += d

#the helper code does not accept tuple or lists as my answer.

    #return t

        return d 

    #return d

1. don't know if it's because of pasting into the forum or whatever but keep your comments at the same indentation level as the code they're commenting. the above is unnecessarily difficult to read and understand.

2. i'm not entirely clear on what you're trying to do but the consuming function wants a dictionary so your function should create and return a dictionary. not sure why you think you need to return multiple things; looks like you just return one thing: a dictionary.

hth/prepared for flames from the python fanboys :p,
tyler

daveT

07-06-2011 11:25 PM

Re: ** Python Support Thread **

I don't always agree with the code style they give me.

For example, using the globals seems unneccessary to me:

Code:

VALUE, WORK = 0,1



def myFunction():

####

for s in subNames:

        val = subjects[s][VALUE]

        work = subjects[s][WORK]

###

Not sure what you are talking about irt to .sort(). It appears to sort the data into something more organized, which is what is suggested by the word 'sort.' Mind that I am not a very sophisticated coder.

I read all of it and just concluded that Python is for people who haven't discovered Ruby. :D

As far as the dictionary issue. I over-thunk the idea and forgot YAGNI.

TheIrishThug

07-06-2011 11:43 PM

Re: ** Python Support Thread **

Think of them less as globals and more as constants. Obviously this is python and their constant-ness is not enforced, but the ALL_CAPS name implies that the variables are constants and should be read only.

It may seem silly in small examples, but it does have value. In the future, when you decided to make some new piece of data be the 2nd element instead of work, you just need to edit your constant instead of find every instance of "subjects[*][1]". Oh and then there was that one time where you called the base variable something else.

However, in general, I would not use lists like this at all. I am completely against using a list just because you can*. It leads to issues where order becomes import and and small changes can effect lots of code. If the data you are encapsulating is not a collection of things, you should find a better data structure. In this example a Subject class with a value and work property would be more explicit and easier to process.

*Who can guess my opinion of Scheme?

sorrow

07-07-2011 12:03 AM

Re: ** Python Support Thread **

Quote:

Originally Posted by daveT (Post 27480995)

I read all of it and just concluded that Python is for people who haven't discovered Ruby. :D

I remember reading an interview with Yukihiro Matsumoto (Ruby creator) where he stated that if he was aware of Python when he started, he probably wouldn't have started writing Ruby at all.

daveT

07-07-2011 12:32 AM

Re: ** Python Support Thread **

Quote:

Originally Posted by TheIrishThug (Post 27481285)

I see the way to approach that now. I guess that I got too attached to the semantics of the words, not their underlying meaning. I guess I should change all my 0's and 1's to WORK and VALUE now.

The two profs in this course are Lisp/Scheme programmers. This isn't supposed to be a 'how to program Python course,' but a 'how to program' course and this course is pretty list/tuple heavy. I guess that this is an okay way to present data, but I agree that this is likely overkill when working with the data. However, I was beginning to believe that list/tuple/dictionary comprehensions was the strong point of Python.

The profs were talking about how Lisp deals with pointers and list comprehensions and what happens when there are lists inside of lists, and then what happens if values have variable length, and my mind about exploded. Python simplifies all of this.

Take the attitude toward dictionaries when dealing with javaScript, which are called "associative arrays" in js: Don't do it. Obviously there is some controversy surrounding lists/arrays/dictionaries/tuples/..... and when/how to use them, but if a language is full of powerful features using expanded data storage types, it makes sense to me that the creators or handlers of Python created a large portion of the language's features with these data-types in mind.

I don't know how accurate my thinking is on this. It could be that the profs are so used to using lists that they just generally default to it, or it could be that lists are challenging to use so they make you work with them to make you think harder about the problems.

Right now, they are talking about memoization, which, as far as I can tell, is just a dictionary of values.

If I decide to dive into Python and buy that 1600 page book on the language, then those questions will likely be answered, but right now, I do the lemming (read: student) thing. Not sure how much further into this language I would like to go. For some reason, I simply can't enjoy coding it, no matter how much it's promoted as fun to code.

TheIrishThug

07-07-2011 08:41 AM

Re: ** Python Support Thread **

Quote:

Originally Posted by daveT (Post 27482035)

The two profs in this course are Lisp/Scheme programmers. This isn't supposed to be a 'how to program Python course,' but a 'how to program' course and this course is pretty list/tuple heavy. I guess that this is an okay way to present data, but I agree that this is likely overkill when working with the data. However, I was beginning to believe that list/tuple/dictionary comprehensions was the strong point of Python.

It is a strong point, but you wouldn't use a hammer to cut a piece of wood in half.

Quote:

Originally Posted by daveT (Post 27482035)

The profs were talking about how Lisp deals with pointers and list comprehensions and what happens when there are lists inside of lists, and then what happens if values have variable length, and my mind about exploded. Python simplifies all of this.

Yes, they love nesting things. The first class I had to take in grad school was all about programming fundamentals and was taught in Scheme. Towards the end of the class, they introduced us to what is called and S-Expression<T> (The <T> means that the data structure is generic and T is some data type, but the structure works the same for all types T).

Quote:

An S-Expression<T> is either a value of type T or a list of S-Expressions<T>.

The following are all valid S-Expressions of ints.

Code:

1

(2 3)

(1 (2 3) 4)

(1 (2 3) (4 (5 6)))

From a theory perspective, it is quite beautiful. A one sentence definition that only allows for two options. But the fact that the data structure is recursive allows you to essentially create any representation you want for your data. The problem is that it is a huge pain to actually work with something like that. The data structure does not provide any help, you just have to know the underlying layout. Scheme really likes lists and recursion (lists are recursive too), but in my opinion, it is used even when it is not the best tool for the job.

Quote:

Originally Posted by daveT (Post 27482035)

Right now, they are talking about memoization, which, as far as I can tell, is just a dictionary of values.

At the core, yes, that is how it is done. But the point of memoization is why it is done and when. The goal of memoization is to not calculate the same value twice. Think about it like this:
[php]def fib(int n):
if (n>1):
return fib(n-1) + fib(n-2)
return n
[/php]
I found the 1000th Fibonacci number and it took me a minute to calculate.
If I want to find the 2000th number, it will take me at least a minute because you have to have calculate all the numbers before it. Even more basic, calling fib(1000) twice in succession would take 2 minutes. But I already know the 1000th number, so I really don't need to recalculate it.
[php]
memo = {}
def fib(int n):
if (n in memo):
return memo[n]
if (n>1):
result = fib(n-1) + fib(n-2)
memo[n] = result
return result
return n
[/php]

The function is only slightly more complicated (3 extra lines) and has the advantage of returning faster the more often you use it. The first call to fib(1000) still takes a minute (actually a little longer). But if you call fib(1000) again, it is just a hash-table look up to get the answer. The downsides are that the initial call will take longer because of the extra work and you use lots of memory. For now, you are just learning the method, so it doesn't matter. When you get to a point where you will actually use it, you will have to decide what is the best balance between recalculating values and storing old values in memory.

All times are GMT -4. The time now is 03:50 PM.

Page 7 of 30

First

2 3 4 5 6 7 8 9 10 11 12 17 27

Last

Show 100 post(s) from this thread on one page