REMINDER: Austin Student Mentorship -- Meeting April 30th
7 views
Skip to first unread message
Lane Smith
Apr 29, 2012, 9:22:01 PM4/29/12
to Austin Software Mentorship
This is a reminder that we're planning to meet for the last time this semester tomrrow, April 30th. Come talk about whatever programming ideas or questions you've come across this last semester! We'll be meeting in ENS 313 starting at 6pm and going for as long as you guys are interested.
On Monday, April 23, 2012, Lane Smith wrote:
Please do me a favor: if you even think you might make it to the meeting, please send me an email. That way, we can get put together an area large enough to fit everyone.
Cheers!
Lane Smith
On Monday, April 23, 2012, Lane Smith wrote:
Hey all,
I think we should meet up one last time before the end of the
semester. I always get some value out of the discussions that come up
in the meetings, and it's been a while since we've talked about ideas
we've come across or problems we've ran into while trying to make
better code. I know Michael mentioned he had some interesting things
he said he'd like to throw out to discussion, which I'm looking
forward to hearing. So, let's plan on meeting next Monday, April 30th
at ENS 313 (the big social study room on the third floor) starting at
6pm. If you can't make it at 6pm, that's fine; come whenever you're
available. We'll stay as long as people have interesting topics to
discuss.
All of this information is also on our Upcoming Events wiki page [1]
and our public calendar [2]. I will also send out a reminder this
weekend.
Hope to see you guys there!
Lane Smith
[1] http://code.google.com/p/atx-sw-mentors/wiki/UpcomingEvents
[2] http://code.google.com/p/atx-sw-mentors/wiki/Calendar
Cheng Leong
Apr 29, 2012, 10:13:34 PM4/29/12
to atx-sw-m...@googlegroups.com
I should be there.
Cheng
Cheng
Sukant Hajra
Apr 30, 2012, 12:40:51 AM4/30/12
to atx-sw-m...@googlegroups.com
Excerpts from Lane Smith's message of Sun Apr 29 20:22:01 -0500 2012:
been off doing other things.
-Sukant
>
> Please do me a favor: if you even think you might make it to the meeting,
> please send me an email. That way, we can get put together an area large
> enough to fit everyone.
I'll be there too. Lane, thanks a lot for keeping the posts going while I've
> Please do me a favor: if you even think you might make it to the meeting,
> please send me an email. That way, we can get put together an area large
> enough to fit everyone.
been off doing other things.
-Sukant
Michael May
Apr 30, 2012, 3:00:45 AM4/30/12
to atx-sw-m...@googlegroups.com
Will be there as well.
Cheng Leong
May 1, 2012, 1:32:08 AM5/1/12
to atx-sw-m...@googlegroups.com
https://github.com/leongc/kenken/commits/master
I've been working on a kenken[1] solver. It is far from done, but some
basics are in place.
I'm linking to the history because I think it's interesting to note
that I have already made a couple of major structural changes to how I
initially modeled things.
I definitely over-guessed at what I would need when I began and it
took a while for me to see that I had put a lot of junk in the Puzzle
that did not belong there.
Later I suspected there might be a better way to construct puzzles;
using a version of Builder helped me see the extra baggage the Puzzle
was carrying.
Trying to write tests also exposed poor separation of concerns between
the Solver and the Solution.
So far I believe I can express Puzzles and expected Solutions easily,
but solving is far off.
I'm also not thrilled about the lack of a coordinate construct to
represent (row, col) int pairs for addressing cells in Cages and
Solutions, but on the flip side, does it help or hinder to have a pair
of ints as a struct?
I have only identified a couple of logical side-effects that are
independent of Cages:
A. when setting a value in a cell, that value is impossible for all
other cells in that row and column, and other values are impossible in
that cell
B. when a cell has only one possible value, that must be the value to set
And a few Cage-based reductions that might lead towards a solution.
1. the identity cage (duh)
2. (im)possible pairs (brute force)
3. shrinking cages when a cell in the cage has a known value
I know I need to add some more general logic to establish (im)possible
lists of Cage factors and addends (beyond pairs).
If a value appears in the intersection of possible lists of Cage
factors or addends and the value is possible in only one of the Cage
cells, then that is the value to set for that cell.
There will also be a row/column aspect for repeated Cage factors or
addends in the lists (must appear in different rows and columns). I
don't know how to structure this yet.
I also know there needs to be some kind of Cage-independent solution
logic that can evaluate a row or column and detect if N cells from
that row or column have a union of N or less possible values, then it
is impossible for the other cells in that row or column to have any
value from the union. Initially I expected this would be done by
Uniques, but I eliminated that class because I don't know how to
structure this yet either.
I welcome your thoughts, comments, or suggestions,
Cheng
[1] http://en.wikipedia.org/wiki/KenKen
I've been working on a kenken[1] solver. It is far from done, but some
basics are in place.
I'm linking to the history because I think it's interesting to note
that I have already made a couple of major structural changes to how I
initially modeled things.
I definitely over-guessed at what I would need when I began and it
took a while for me to see that I had put a lot of junk in the Puzzle
that did not belong there.
Later I suspected there might be a better way to construct puzzles;
using a version of Builder helped me see the extra baggage the Puzzle
was carrying.
Trying to write tests also exposed poor separation of concerns between
the Solver and the Solution.
So far I believe I can express Puzzles and expected Solutions easily,
but solving is far off.
I'm also not thrilled about the lack of a coordinate construct to
represent (row, col) int pairs for addressing cells in Cages and
Solutions, but on the flip side, does it help or hinder to have a pair
of ints as a struct?
I have only identified a couple of logical side-effects that are
independent of Cages:
A. when setting a value in a cell, that value is impossible for all
other cells in that row and column, and other values are impossible in
that cell
B. when a cell has only one possible value, that must be the value to set
And a few Cage-based reductions that might lead towards a solution.
1. the identity cage (duh)
2. (im)possible pairs (brute force)
3. shrinking cages when a cell in the cage has a known value
I know I need to add some more general logic to establish (im)possible
lists of Cage factors and addends (beyond pairs).
If a value appears in the intersection of possible lists of Cage
factors or addends and the value is possible in only one of the Cage
cells, then that is the value to set for that cell.
There will also be a row/column aspect for repeated Cage factors or
addends in the lists (must appear in different rows and columns). I
don't know how to structure this yet.
I also know there needs to be some kind of Cage-independent solution
logic that can evaluate a row or column and detect if N cells from
that row or column have a union of N or less possible values, then it
is impossible for the other cells in that row or column to have any
value from the union. Initially I expected this would be done by
Uniques, but I eliminated that class because I don't know how to
structure this yet either.
I welcome your thoughts, comments, or suggestions,
Cheng
[1] http://en.wikipedia.org/wiki/KenKen
Reply all
Reply to author
Forward
0 new messages