Adam Vinueza

Ranch Hand
+ Follow
since Apr 16, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Adam Vinueza

You're calling the nextToken method only once, which is why you get "lmn" instead of "b". Try something like this instead:
18 years ago
FYI,

There's also a dedicated interface in Java called FilenameFilter for doing just what you need to do. As it happens, I had a similar requirement--there were directories containing files whose names included timestamps, and I needed to delete those whose names included a timestamp older than a given timestamp--and I found that this interface greatly simplified my task.
18 years ago
Another way of talking about a binary heap is as a binary tree which has the property of being heap-ordered and left-to-right filled. A tree is heap-ordered if, given an ordering operator, the parent node is no later in the ordering than its children. Being left-to-right filled means that if there is a space available on a level, nodes are added left-to-right.

The space property of binary heaps makes them complete binary trees, except possibly for the lowest level. It is the heap property that makes them heaps.

Any decent data structures text should have basic information on binary heaps. They're usually just called heaps in your more basic texts, and are often discussed in the context of sorting, because binary heaps provide an efficient means for sorting items. A very good and comprehensive discussion is in the chapter on Heapsort in the big Intro to Algorithms book by Cormen et al.
[ May 31, 2005: Message edited by: Adam Vinueza ]
18 years ago
Ah, that explains it. I was just confused. Thanks for clearing it up!
18 years ago
If I write this code:

I get the result as 6 a.m. today. But the documentation says, and the code suggests, that the result should be noon today (in the default time zone, which is wherever your computer happens to be). Has anyone else noticed this, or have I made some mistake?
[ May 05, 2005: Message edited by: Adam Vinueza ]
18 years ago
It's hard to give a useful answer without more information than you've given here, but the problem you raise is a general one: how does one tell by looking at the contents of a file what kind of file it is?

The short answer is: it can't be done in general. You can use various heuristic tricks and make educated guesses. (For example, compressed files typically come with specific bytes at the very beginning; I'm told that viruses and worms tend to have signatures that betray them; and so on.) But there isn't a general-purpose algorithm for looking at a stream of bytes and saying, "Yes, that's an executable" or "No, that's just an email message." So you won't find a class in the Java API that enables you to do this.
18 years ago
Maybe I'm wrong about this, but if the OS assigns a drive letter to the device, then you should be able to access its files in the way you access files on any other drive. So if you're opening a file, you need to pass in the fully qualified path containing the drive letter. Maybe you'll need to use the special API to do what you need to do with those files, but I imagine telling Java where the files are is handled by the OS when it assigns a drive letter.
18 years ago
You can make Calendars lenient or non-lenient. If they're non-lenient, they'll throw exceptions when bad dates are thrown in. So make a Calendar, set its leniency to false, and try to set its date with the date you've parsed.
[ May 03, 2005: Message edited by: Adam Vinueza ]
18 years ago
I'd forgotten about implementing Comparable, which saves you the trouble of writing your own Comparator. But you have to implement the compareTo() method in either case. Joe's suggestion is strongly preferable to writing your own Comparator, assuming the objects to be sorted are always sorted in the same way.
18 years ago
That seems to be an odd restriction, but I suppose you could use the sort() method from Arrays, assuming the sorted objects are Strings. You'll have to do some jiggery-pokery--extract the names into an array, sort them, build new Lists and read the elements into them in sorted order using the sorted array as your guide--but it would work.

The reason comparators are the natural thing to use here is that the objects you're sorting probably have no natural ordering, or if they do, they have a natural ordering different from the ordering you want. I really don't see a way to do what you want in a natural way without using comparators.
18 years ago
Why not just write your own Comparator? It should take five minutes or so, if you know what to look for when comparing the objects.
18 years ago
I haven't tried this myself, but won't this.getClass() get the class you want? Then you can call getMethod() to get the right method, and call invoke() on the Method to call it. That'd my strategy for implementing execute(). Something a bit like this:

I don't know if it will work--again, I haven't tried it--but that's the basic idea.
18 years ago
In x + y where either x or y is a String, the non-String is converted to a String and the results are concatenated.

Binary operators besides the assignment operator are left associative, so the string "" + 5 + 6 yields "56", as it's really ("" + 5) + 6.

Your worry feels familiar to me, though.
Neeraj outlined the basic idea, but here are a couple of details you might keep in mind.

1) Java's garbage collection features make removing a Node from a linked list easier, as you don't have to explicitly set a pointer to a Node to null.

2) When implementing a remove(Object key) method for your own linked list, you'll start to appreciate why Java included Iterator interfaces. You might want to implement your own iterator() function in your linked list that returns a special implementation of Iterator to remove Nodes in your linked list. That will make your code more readable and more OO.
18 years ago
A stock example from OO courses is a Shape class in an application that makes use of geometric shapes. A Shape class would probably have various useful functions, such as draw(), area(), perimeter(), and so on. The Shape class is made to be extended, as the draw(), area(), and perimeter() functions might be very different depending on what kind of Shape we're talking about. Moreover, there seems to be no point to implementing draw(), area(), and perimeter() functions for a Shape that isn't also a Rectangle or Circle or some other specific Shape; users will work with those things, not with Shapes as such. This means there would seem to be no point to making a Shape object, so we might as well make Shape abstract.

In general, when you've got some number of classes that have common data members and superficially similar behavior, but no common underlying behavior, it's appropriate to create an abstract class and have these classes extend it. By contrast, if the classes don't have common data members, it's appropriate to have them implement a common interface.
18 years ago