|
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. |
On December 04 2015 00:01 WarSame wrote: And for this reason I believe that I do need a min node class. You could also implement a MinStack by wrapping 2 stacks into a single class. One acts as the normal stack, one holds the min values. Each time you push/pop you do so for both stacks.
|
Now there's an idea! That sounds really good. I'll give that a shot.
|
Is it worth doing a very long (4+ hours according to the recruiter, and looking at the spec I can definitely see why) coding challenge which I don't feel like I would be able to do properly anyway? I have finals coming up and assignments due still, and honestly if I thought I'd be able to do it reasonably well I would definitely go ahead and do it anyway (learning opportunity, it's not harmful, chance at interview, etc).
However I just feel like that's an awful lot of time to be spending on a coding challenge I couldn't complete, when I have other shit due. It's hexagonal text search if anyone else has ever heard of it. But then I'd feel bad just leaving it/the learning opportunity... Time is an issue because they want it back today (so I can't ask to wait until after exams and whatnot). :S
|
Why not just focus on your assignments and finals and try your hand at the challenge on your own some other time?
|
On December 04 2015 02:10 WarSame wrote: Alright a much simpler question this time: they have a Tower of Hanoi example,but I think it might be wrong. They say, as one of the requirements: " A disk is slid off the top of one rod onto the next rod" so you can only go from tower 1 to 2 and 2 to 3 or the reverse. However, in their solution they seem to ignore this - they move all their disks except the bottom to the buffer tower, and then move the very bottom disk to the destination tower. This means that they skip tower 1, and move it from tower 1 to 3, which violates the requirement. Am I going crazy or is this an error? If you'd like me to paste the solution they have then let me know. Hanoi is unsolvable if that requirement you say exists. You can move any disk from any tower to any other tower, as long as it doesn't end up on a disk that's smaller than it. Now go back to programming recursion in Java (yeuch)!
|
On December 04 2015 07:12 Acrofales wrote:Show nested quote +On December 04 2015 02:10 WarSame wrote: Alright a much simpler question this time: they have a Tower of Hanoi example,but I think it might be wrong. They say, as one of the requirements: " A disk is slid off the top of one rod onto the next rod" so you can only go from tower 1 to 2 and 2 to 3 or the reverse. However, in their solution they seem to ignore this - they move all their disks except the bottom to the buffer tower, and then move the very bottom disk to the destination tower. This means that they skip tower 1, and move it from tower 1 to 3, which violates the requirement. Am I going crazy or is this an error? If you'd like me to paste the solution they have then let me know. Hanoi is unsolvable if that requirement you say exists. You can move any disk from any tower to any other tower, as long as it doesn't end up on a disk that's smaller than it. Now go back to programming recursion in Java (yeuch)!
You sure? I'm pretty sure it's still solvable.
https://en.wikipedia.org/wiki/Tower_of_Hanoi#Graphical_representation
Incidentally, this longest non-repetitive path can be obtained by forbidding all moves from a to b. Since forbidding moves from a to c is clearly symmetric to forbidding moves from a to b, there must be a solution.
Furthermore, this solution is maximal in the sense that it solves the problem while taking the most amount of moves without repeating any states.
|
On December 04 2015 06:57 solidbebe wrote: Why not just focus on your assignments and finals and try your hand at the challenge on your own some other time? Recruiter got back to me and mentioned I could do it later if I wanted, so I'll probably just go ahead and do that, yeah
|
On December 04 2015 08:00 Prillan wrote:Show nested quote +On December 04 2015 07:12 Acrofales wrote:On December 04 2015 02:10 WarSame wrote: Alright a much simpler question this time: they have a Tower of Hanoi example,but I think it might be wrong. They say, as one of the requirements: " A disk is slid off the top of one rod onto the next rod" so you can only go from tower 1 to 2 and 2 to 3 or the reverse. However, in their solution they seem to ignore this - they move all their disks except the bottom to the buffer tower, and then move the very bottom disk to the destination tower. This means that they skip tower 1, and move it from tower 1 to 3, which violates the requirement. Am I going crazy or is this an error? If you'd like me to paste the solution they have then let me know. Hanoi is unsolvable if that requirement you say exists. You can move any disk from any tower to any other tower, as long as it doesn't end up on a disk that's smaller than it. Now go back to programming recursion in Java (yeuch)! You sure? I'm pretty sure it's still solvable. https://en.wikipedia.org/wiki/Tower_of_Hanoi#Graphical_representationShow nested quote +Incidentally, this longest non-repetitive path can be obtained by forbidding all moves from a to b. Since forbidding moves from a to c is clearly symmetric to forbidding moves from a to b, there must be a solution. Furthermore, this solution is maximal in the sense that it solves the problem while taking the most amount of moves without repeating any states.
Actually, you might be right. I always think in terms of minimal solution, which is impossible, but I guess you could move entire towers back and forth multiple times. For instance, take a tower of 2: under normal rules you move 1: a -> b 2: a -> c 3: b-> c Done.
Under these rules, you have to move:
1: a->b 2: b->c 3: a->b 4: c->b 5: b->a 6: b->c 7: a->b 8: b->c
I don't see any point in this restriction. It adds an exponential number of pointless moves without actually teaching you anything about recursion or dynamic programming that the first method doesn't. But I do admit I was wrong: Hanoi is still solvable (or at least, my most immediate objection to why it is invalid: you CAN move entire towers one by one back and forth on top of each other, it's just tedious).
|
Yeah, I saw that it was solvable with that restriction, but honestly had no clue how the fuck you would program that. The actual Tower of Hanoi is still fairly difficult, but actually possible to program. Thanks for the response. It was just me being stupid, then.
|
Sorry if this is not the right thread for my kind of question:
I'm currently thinking about buying an Arduino Starter Kit. Does anyone have experience with it? There seem to be quite a lot of imitiations( not sure if the right word) with some of them costing only half of what the Starter Kit does. Is it worth it to pay the full prize for the original Arduino kit or can anybody recommend another one? I'm a bit overwhelmed. You seem to have an awful lot of options to basically either buy the original Starter kit, a 3rd part version of it, or just assemble your own kit by buying elements on their own.
|
On December 04 2015 08:44 WarSame wrote: Yeah, I saw that it was solvable with that restriction, but honestly had no clue how the fuck you would program that. The actual Tower of Hanoi is still fairly difficult, but actually possible to program. Thanks for the response. It was just me being stupid, then.
The Tower of Hanoi solution should just be a decision tree. Same way you would solve Tic-Tac-Toe.
|
On December 04 2015 08:44 WarSame wrote: The actual Tower of Hanoi is still fairly difficult, but actually possible to program.
How is it fairly difficult?
def moveTower(height, fromPole, toPole, withPole): if height >= 1: moveTower(height - 1, fromPole, withPole, toPole) moveDisk(fromPole, toPole) moveTower(height - 1, withPole, toPole, fromPole)
def moveDisk(fp, tp): print("moving disk from", fp, "to", tp)
moveTower(3, "A", "B", "C")
I believe it's one of the first things you encounter when reading up on recursion.
|
Ah... that is much easier. I was still stuck in the mode of the other way I was doing it.
|
I've been reading Robert Martin's Clean Code book, and had a question about his section on switch statements. He uses the example of different kinds of employees: commissioned, hourly, and salaried. You might have various decisions to make depending on what kind of employee they are, such as how much they're paid, their pay day, or how to deliver their check. Rather than wrapping each decision with a switch statement, where you have to hunt for and change each one every time there's a new kind of employee, his suggestion is to use an abstract factory and abstract out those decisions into child employee classes such as HourlyEmployee or SalariedEmployee. That way the switch statement is declared only once, and it's easy to find and change.
That makes sense to me, and I can see the advantages and disadvantages doing that as opposed to maybe using an enum. But my question is, what happens when you have more than one need to do that on the same object. Suppose you also have to make decisions based on the employee's gender regardless if they're salaried or whatever. You can't create a class that inherits from more than one parent (at least not in C#), which means you'd have to create an instance for each possible combination: HourlyFemaleEmployee, HourlyMaleEmployee, SalariedFemaleEmployee, SalariedMaleEmployee, etc. Is there a better way to do that? Am I over-complicating it like I always do?
|
Look up decorator pattern, it was designed to deal with the exact problem youre describing.
|
On December 05 2015 08:15 solidbebe wrote: Look up decorator pattern, it was designed to deal with the exact problem youre describing. Yes! I knew there was a simple solution. I'm quite familiar with the decorator patter, and it just didn't occur to me to use it in this instance. Thank you!
|
whelp, I just woke up and it's time to work on my CS project for java
but I need to get my head straight and in the game..
help me figure something out.
If I make a class, let's call it "database". and in "database" I am gonna have a couple arraylists, that are going to hold objects. and I want those arraylists to be static because there will only be 1 of each. so that's cool and all
if this is all my database class does - hold those 2 arraylists - is it appropriate to make that class "final" ?
god I can't believe I am this far into the semester and I sitll get confused by how static and final interact
if I have static arraylists in a final class, can I still change what is in the arraylists? I can, right? or can NOTHING in the class be changed?
and if I have static arraylists in the class and I make a new instance of the class, then it doesn't matter which instance of the class I reference, if I reference the arraylist within that instance it will always be pointing to the same one, right?
|
'final' only indicates that you can not inherit from that class. 'static' members transcend class instances (that is, the static members in all class instances have exactly the same value). However, beware of multi-threading writing static members.
|
If you only have static members, you don't have to create an instance of the class to use it. Just make everything you need public static and use it like this:
Database.List1.Add(x); Final on a class shouldn't interact with static at all. It just means you can't subclass the final class. It does not make instances of the class or its members immutable.
However, I discourage that whole setup. "because there will only be one of each" is a trap. Static is inflexible and should mostly be avoided, especially if it's static data. It might seem convenient that you don't have to pass around a reference to your Database class, but sooner or later you'll find that you would in fact prefer to have multiple different instances of that class.
Also unless you have a good reason to make your class final, why would you?
|
Im not that sure myself what declaring a class final does but youre correct on static. Declaring a variable static means it belongs to the class, not to an instance of the class. So accessing it through any instance would lead to the same variable. Youll probably get a warning "variable should be accessed in a static way" though. Which means youd need to access it like *classname*.variable. (or through a static getter)
edit* I agree with the post above. Its usually better design to not use static but rather instances.
|
|
|
|