|
Post by Observer on Nov 26, 2001 8:21:59 GMT -5
I managed to get my bone burying method to work but for some strange-ass reason sometimes not all of the bones appear. Has anyone else encountered this and could someone provide a general reason why? Also, they don't care if sometimes something like 4444333 happens on one row would they? I thought my assignment was done but now I'm a little worried. How can 4444333 ever happen? From what I interpreted in the 'burying the bones' part of the assignment handout they said that once the horizontal or vertical position had been randomly chosen, to pick the the left most position for horizontal and top most position for vertical so that they don't go off the array. They said that if placing further bones down and they are going to overlap, repeat the first few steps and choose a new row/column. So two lines of bones that are both horizontal cannot go one after the other...right? If that's wrong on my part then I have to change a lot of my bone burying method.
|
|
|
Post by Majin_Blues on Nov 26, 2001 16:29:17 GMT -5
well they did say to start placing bones from the top or the left most area...
for that 4444333 to happen (or any variations thereof), you'd have to go the extra mile... but don't worry, it's not mandatory that you do it...
Brutal_Chicken: you might want to check your "check" again and be very careful in reading it over. ask yourself why you did what you did...... i made the same mistake in switching the values for row and columns
either that or count how many bones are "buried" in your burying methods
|
|
|
Post by Brutal_Chicken on Nov 26, 2001 16:58:18 GMT -5
What I'm thinking of doing is just before the return statement I would place another if statement with a for loop inside to check how many coordinates have bones in them, which should equal 12. If it's false it'll break the loop. Either I can do it that way or have an int counter inside the for loop that's incremented and just check if it's equal to twelve...
About the checks. The problem with going over them myself is that you usually don't catch your own mistakes because it makes sense in your head. And I've managed to get the accuracy to 90% (18/20).
|
|
|
Post by Majin_Blues on Nov 26, 2001 17:07:22 GMT -5
getting better... that's why with the checks you have to be extremely careful... keep asking yourself why... and re-check s'more... (boy it sucked!)
anyway, i just want a show of... replies... Suppose you changed the size of your grid to a 4x4 grid through that one line in your program...(4 rows, 4 columns regardless of numbering)...
does your program still work?
|
|
|
Post by 1.8T on Nov 26, 2001 18:14:36 GMT -5
Question: ok the positions of the lines are stored in the array beginning with 0 to the length of array , . i'm wondering wut the user inputs to guess where the lines are for example., for a 1 x 1 array , just say do user input 1 enter, 1 enter? or do they input 0 enter, 0 enter? the latter would be easier to program,, .. well save me a step anyways., how did u guys do it?
|
|
|
Post by Observer on Nov 26, 2001 18:38:22 GMT -5
They didn't specify so I just did it the easy way (or lazy way -depends on how you look at it) and have the user specify the integers in terms of actualy array posistions so the top left most position would be 0 enter 0 enter.
|
|
|
Post by 1.8T on Nov 26, 2001 18:43:40 GMT -5
okok. nice nice. if they didn't specify , i guess we can do it that way., but can bet , just when we're done , they're gonna have an update on the CSC108 page saying the user inputs., its like 1x1 ;D ;D
|
|
|
Post by bladehunter on Nov 26, 2001 19:11:20 GMT -5
Blues, my program works if the grid is changed to 4*4.
|
|
|
Post by Majin_Blues on Nov 26, 2001 22:26:39 GMT -5
Blues, my program works if the grid is changed to 4*4. Guess nobody else's worked... except yours and mine... it doesn't get stuck at the beginning, does it? (i took care of this... just asking) i.e. if your grid set up like this without one line of three, there wouldn't be space for another line of 3 and your program would just keep randomizing (even though it won't find one) 4 3 4 3 4 3 2 2 4
|
|
|
Post by bladehunter on Nov 27, 2001 4:45:57 GMT -5
On a 4X4 grid, it is always possible to fit lines of length 4,3,3, and 2.
In your example, the last 3 line can be put on the last row
|
|
|
Post by gundamf91 on Nov 27, 2001 6:10:21 GMT -5
yup i agreed, mine works did you see my post?
43 43 4322 4333
|
|
|
Post by bladehunter on Nov 27, 2001 13:54:50 GMT -5
The only problem is if the 3 line is vertical. But for my prog, i bury the longest one first.
|
|
|
Post by Majin_Blues on Nov 27, 2001 18:11:51 GMT -5
On a 4X4 grid, it is always possible to fit lines of length 4,3,3, and 2. In your example, the last 3 line can be put on the last row this is not always the case; it depends if you determine if you're placing the bones vertical/horizontal first: 4 4 4333 4 and suppose the second line was "flipped" to be vertical... no space left = infinite loop (unless you re-flipped the vertical/horizontal coin again)
|
|
|
Post by 1.8T on Nov 27, 2001 19:00:26 GMT -5
i agree with blues,
. . 4 3 2 2 4 3 . . 4 3 . . 4 .
if u made placed the lines in this order, 4, 2, 3, 3 then its obvious the last line of length 3 can't be placed anywhere but with . . . 4 . . . 4 3 3 3 4 . . . 4
my lines do reflip (change direction) if it doesn't fit, . so this orientation is valid in my case. , but
. . 4 3 2 2 4 3 . . 4 3 . . 4 .
this grid there's no way a line of length 3 can fit, the only way to get around it i found was to make the lines in this order, 4, 3, 3, 2 .. , .but its a cheap way to get around the problem., any suggestions?
|
|
|
Post by Brutal_Chicken on Nov 27, 2001 20:18:16 GMT -5
Hmm... you know what? I'm gonna call this little annoying 'bug' in my program a 'feature' instead...
|
|