Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 May 2004
Offline Last Active Aug 11 2013 10:16 PM

Posts I've Made

In Topic: Best book to learn Java from?

23 September 2008 - 10:57 AM

So is your budget $30? If yes, then here are my suggestions.

The first Java book I read many years ago is published by Murachs. At the time I was really not that interested in Java so I overlooked how cool the book’s format really is. The book uses a “paired-page” concept. The code is in one page and the explanation of it in the next page of the book. If you are interested in a gentle introduction, while at the same time learning a few things about GUI and database programming I strongly recommend this book.

If you want something that delves into much greater detail you can’t go wrong with any of the Java books (after Java 1.5 of course) by Ivor Horton. His books cover many things that most people now think are unnecessary for a beginner programmer. For example, how to use streams to get data as opposed to the new and easier method of using the Scanner class. The Scanner class takes care of many things for you, but you don’t have any idea of what it’s doing, or why it works the way it does.

Now, I have heard a lot of good things about the book “Head First Java.” Since I have not read it I really can’t give you a description of why it’s good. However, it has a majority of positive reviews on Amazon.com, which is rare for a technical book. Thus, if I was in your position I would strongly consider this as a candidate.

At my university a variety of books have been used in the past three years and I will list them here, but these are more expensive, and in my opinion are worst for self study:

Big Java
Programming and Object Oriented design using Java
Java 5.0 Program Design

Lastly, once you are up to speed in Object Oriented programming you will need a strong foundation on Generic programming, or in this case, Java generics. The best reference in book form currently available is “Java Generics and Collections” by Maurice Naftalin and Philip Wadler.

And don’t forget to check your local library for these books before you buy them. Or at the very least check Half.com for discounts on the above books.

Best of luck.

In Topic: implementing a stack

26 August 2008 - 06:54 AM

Thank you Antheus for taking the time to explain the topics.

When I learned about data structures we covered stacks and some of their applications, but I can't recall ever covering what are the advantages and disadvantages of different implementations in this detail.

In Topic: implementing a stack

25 August 2008 - 04:45 PM

Original post by Antheus
Stack benefits very little from linked list, and nothing from double linked list. One will never be inserting in the middle, and removal is always on single (first) node.

Stack is not a queue. One always accesses only the top (bottom) element. One will never be inserting from middle or back, one doesn't need to traverse the elements externally, even size is not an issue.

Linked list has one and only benefit that its growth is finer grained. But the greatest benefit of LL, the ability to insert at middle efficiently, something which is not possible with arrays, is completely lost in case of stack.

When used for performance reasons, stacks are typically implemented as fixed size structures (recursion unrolling, where size can be calculated from algorithm). This approach will always be preferred, since access to elements is effectively free.

If maximum size constraint is undesirable, then the aforementioned paging will work better.

Perhaps the only case where I could imagine linked list being used for stack would be in lock-less stack implementation, but even in those, the maximum number of nodes in stack is typically fixed and pre-allocated (issues however transced the ADT stack by far and complications are too numerous to list).

But for everything else, I find linked lists to be simply sub-optimal for stack, with possible exception of certain memory configurations (the overhead however is still hard to justify compared to occasional resize).

Antheus, respectfully I disagree with your reply. The original post states c++ and a linked list are what godsenddeath is thinking about using for the implementation.

For my own understanding could you please expand on the following:

"middle efficiently"
"calculated from algorithm"
"lock-less stack implementation"

Or at the very least could you please provide resources where we can find more information about those terms. From your response it appears that you are talking about implementation of stacks where space overheads are not acceptable. Or are you talking about an implementation of the stack that takes threads into consideration?

Thanks in advance.

[Edited by - arroyjose on August 25, 2008 11:45:43 PM]

In Topic: implementing a stack

25 August 2008 - 03:42 PM

Yes, a linked list would be a good underlying data structure for a stack. The only methods that you would need would be an addFirst, and removeFirst if you think of the first element as the top of the stack. Or conversely addLast and removeLast if you think of the last element as the top of the stack.

Example structure:

|Head| --> null if empty

|Head| --> |Top| one element

|Head| --> |Top| --> |Top - 1| --> .... --> |Last|

The two methods should not take a long time to code, and you should not over engineer your solution if a simple stack is what you need. If on the other hand you want to implement a robust solution with potential code reuse you should code a doubly linked list with a dummy node. Keep in mind this is for you own personal learning purposes, and to understand how the data structure is implemented.

The difference between a linked list and array implementation of a stack is the that you don't have to worry about resizing the array when it gets full. The only other thing that I can think about is that if you need for some reason access specific elements in the stack (highly unlikely because the stack operations are only push() and pop()), then the array implementation gives you that advantage because you can access elements in constant time.

So here is what I would suggest as far as code goes:

// Adds an element at the top of the stack.
push() a.k.a. addFirst()

// Removes an element from the top of the stack.
pop() a.k.a. removeFirst()

// Returns the element of the stack without modifying the structure

// Returns true if the stack contains no elements

Hope that helps and good luck.

In Topic: Computer Science or Computer Engineer ? Whats the difference?

28 March 2008 - 01:09 PM

Original post by Antheus

Ever tried to apply at Google, Microsoft or IBM?

Or what kind of programmer are we talking here? It's a known fact that for most web shops senior programmers can be produced in a 3 week Java course.

I'm talking about recent college graduates. I have not applied at any of those companies, but I've talked to reps from both Microsoft and IBM at the career fair in my school. They did ask me if I could write Dijkstra's algorithm on paper at that moment.

However, I would never expect them to ask me for three years of experience of .NET or JEE5, or whether I understand AJAX and the latest version of Silverlight.

I guess what I'm trying to say is that it doesn't matter if you are ComS, CprE, SE, or even MIS to get a programming job if you have the willingness to learn, the ability to problem solve, and the dedication to tackle problems by steps. In that sense, all of those degrees can lead you to a multitude of jobs. What I was trying to illustrate is that a CprE degree can - in addition to software - help you get a job working with hardware.