This week's giveaway is in the JDBC forum.
We're giving away four copies of Java Database Connections & Transactions (e-book only) and have Marco Behler on-line!
See this thread for details.
Win a copy of Java Database Connections & Transactions (e-book only) this week in the JDBC forum!

Junilu Lacar

+ Follow
since Feb 26, 2001
Junilu likes ...
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
Forum Moderator
Junilu Lacar currently moderates these forums:
Columbus OH
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Junilu Lacar

Wouldn't the first sub-expression be whatever was inside the brackets on the left side of the assignment? If you change it slightly, you'd have (almost) the same expression tree.
13 hours ago

Martin Fowler wrote:Any fool can write code a computer can understand; good programmers write code that humans can understand.

Maintenance makes up the bulk of the overall cost of software. If your code is not maintainable because it is cryptic and difficult to understand, then it becomes more costly. Even if there is no monetary value involved, it still costs someone time and effort. So if you want to be a good programmer, strive to write code that is easy to understand and work with.

Make your code express its intent clearly. Replace formulas like what you have with a call to a method with an intention revealing name.

A common example is this:

The former gives a formula that needs to be deciphered by the reader. The latter reveals the intent of the formula.
1 day ago
"The internet is full of quotes which weren't actually said by Einstein." —Abraham Lincoln

2 days ago
Static fields and methods get resolved to the declared type, not the actual runtime type because they dont participate in polymorphism. Read about static/early binding vs dynamic/late binding.
2 days ago
Don't conflate randomness with uniqueness - a random sequence does not preclude duplicates.  In other words, you cannot assume elements of a random sequence will not (eventually) be repeated.

I like Dave's suggestion of shuffling to mix up the order then just sequentially give out the elements of the shuffled list.

This may have already been suggested but alternatively, you can pick out a random element from 0 to n-1 where n is the total number of elements then swap the chosen element with the n-1 element. On the subsequent round, you randomly pick from elements 0 to n-2 and swap that one with the n-2 element. Then pick from 0 to n-3 and swap with the n-3 element, and so on until you have exhausted the entire list.
2 days ago
Thanks for the link, that is very helpful.

This minimax algorithm basically constructs what's called a game tree and is supposed to pick the branch that will lead to the best outcome. Unfortunately, the code you shared is difficult to follow and, frankly, quite a mess.

At this point, it might be helpful if you gave an example of where your code fails to find the optimal set of moves to play. The failure could come at any time so it will be most helpful to see it go through an entire game so it's easier to see the point where it goes wrong.
3 days ago
And my point is that not everyone who looks at this thread will know offhand what that algorithm is. Giving people a link to more details about it or giving a short description of what it's supposed to do would be helpful and increase your chances of getting help. It would be the courteous thing to do.
3 days ago
You might help people understand your intent by explaining what you mean by "minimax algorithm". Then they'll have a basis for analyzing your code to see what might be out of alignment with that algorithm.
3 days ago
It might also help to think about recursive cases as "going down the rabbit hole and (eventually) coming back".

That is, when you have two recursive calls "stacked up," as you say, like that the first call just goes as far down the recursion as it will, come back out when it reaches a base state, and completes the recursive call at that level. Then it continues to the second recursive call and does the same thing.

I think your confusion may lie in thinking about when the second recursive call occurs. That's where the different levels of recursion comes in. Carey's suggested adjustments to the code allows you to better see how recursion levels come into play. At the same level of recursion, program execution simply goes the regular sequential order.
3 days ago
I can tell you that your code so far appears to be confused. For example, the usrInput() and exchange_rte() methods are essentially duplicates of each other. It doesn't matter that you use different names and have different intents for them, they both do essentially the same thing and therefore are duplicates.

Also, there is no need to create a Scanner object in those methods. You can create one Scanner in main and use it across your entire program. The Scanner variable in this case would be a static member variable.
3 days ago
You'll have to tell us more than just "I'm stuck."

Do you have specific questions? What exactly are you confused about?

And welcome to the Ranch!
3 days ago

Mark Richardson wrote:So, as a student, I've always learned that we make our instance variables private because some "rogue class" might inadvertent (or nefarious) changes to your class.
That is, every class should have responsibility over it's own variables. I get that.

But the getter and setters methods are public. They can presumably just be called by another class, no?

I suggest you read articles related to "getters and setter break encapsulation" to get a better grasp of some of the motivations for keeping the scope of things (methods, fields, classes) as small as possible. Essentially, the wider the scope of something, the less control you have over how that something will be used. Therefore, it is in your best interest to put up "guardrails" around things that are widely accessible to mitigate the risk of them being used in ways that you didn't anticipate that could violate some the assumptions made when you designed those program elements.

This is another reason I like to adhere to Kent Beck's 4 rules of simple design - I usually think of rule #4 as "keep things small," including scope.
5 days ago
I would use words like "unintentional" or "unexpected" rather than "rogue". The latter term has a more malicious connotation whereas in the real world, the motivations are often less so.
5 days ago