Win a copy of OCP Oracle Certified Professional Java SE 11 Developer Practice Tests this week in the OCP forum!

Winston Gutkowski

+ Follow
since Mar 17, 2011
Winston likes ...
Hibernate Eclipse IDE Ubuntu
35 years of computing, from junior COBOL nerd to sysadmin for Sun...with a lot of DBA and modelling in between. Resistentialist. Beer lover. Fat cyclist. Bridge Player (fanatical, but mediocre). Trivia buff. Collector of oddities. Liberal (in the old-fashioned sense; but still ABC - Anything but Conservative).
Girvan, South Ayrshire, Scotland
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 Winston Gutkowski

Steven Villarreal wrote:The point is to input a Date string lets say "5/10/2020". The code lets everything through the method that is 1/1, 1/12, 10/1, 10/11. But for instance, typing in a 0 before a day or month like 09, 012, 02 should throw a run time exception error.

Why? Seems perfectly reasonable to me (well, maybe not "012"), and the way many dates are actually written.

However, my advice would be to forget "rolling your own", and use the parser provided by SimpleDateFormat - ie, parse(String).

You should read up on it carefully first because there's quite a lot to know; but it's a far more generic solution and you don't have to write a single line of code.

The class even allows you to set its "strictness" (see setLenient(boolean)).

1 year ago

Dawid Smith wrote:Still, what do you think about writing your own version just for practice?

Nothing wrong with it at all; just don't expect too much in the way of enlightenment unless you repeat the process at least 10,000 times, or work with arrays involving millions of objects, which probably isn't very practical.

Java does things very quickly indeed, so the difference between one instruction (or technique) and another might be measured in picoseconds (thats 10⁻¹²), and since the best Java time counter (System.nanotime()) is good to about 1/100th of a second, if you're lucky, you're unlikely to get any meaningful information unless you're running your comparisons on very large samples.

I'm with Junilu - right now, you might get more mileage out of looking at sorting algorithms and working out why you might use them; but don't ignore the simple ones simply because they're supposedly "inefficient" (O(n²) or worse).

The technique you're using, for example, is very similar to a Selection sort, which is still used to sort small datasets ... although Insertion sort is usually quicker.

And in trawling Wikipedia, I was also reminded of Cycle sort, which is basically a "write-optimized" Insertion sort.
All these sorts are supposedly "slow", but they all have their uses, especially in hybrid algorithms that combine them with other, theoretically faster techniques, like Quicksort.

Hope it helps.

1 year ago

Winston Gutkowski wrote:...but AFAIC the result of a search on a sequential dataset...

Oops, I meant "random-access"...

1 year ago

Stephan van Hulst wrote:

Winston Gutkowski wrote:the name suggests to me that your class is part of a broader set of "search results" which don't necessarily have to be "sorted".

It's the result of a search in a sorted sequence. An unsorted sequence wouldn't have an insertion point for an element that wasn't found.

Sure it would (or could). First, last or anywhere. That would depend on the nature of the dataset.

And that's where we disagree. int is not a natural choice for a search result. Integer (yuck) or OptionalInt (better) might be when the search doesn't have to return an insertion point. When it does, a value of -4 to indicate an insertion point at index 3 is everything but natural.

I suspect, Stephan, that you are one of the very few people who doesn't see an int as the natural result of a search.
In fact, I think it's so natural that it's perverse not to use one.

Granted, you've explained your reasons for not doing so reasonably well to me, who has been bumping around computers and languages for a few decades now; but you haven't convinced me that you're right.

And my reasoning is as follows:
I'm searching for something, and there are two possible outcomes: I find it, or I don't.
There may be cases when that's all the information I need, but often it won't be, and at the very least an int (as opposed to a boolean) can tell me WHERE an item was found.
So, assuming (a) the dataset is indexable with an int, and (b) knowing where the item was found saves my algorithm time, then I want that information.
However, the smart chaps at Sun also worked out that the "not found" multiverse of int can be used to return the index of the element that our value would be at if it existed. It's hardly their fault that it doesn't fit in absolutely seamlessly with 0-based indexing.

I find it confusing that your foundAt() method returns an index when the element wasn't found, and that the insertAt() method does not return an index when the element was found, even though it's perfectly fine to insert an element with the same value before the found element.

Actually it does. It's just that in both cases it's invalid.

Like I say, I have no great problem with a wrapper class if you think it makes things easier to understand, but AFAIC the result of a search on a sequential dataset, sorted or otherwise, is absolutely an int ... or something very like it.

1 year ago

Stephan van Hulst wrote:Well, they could have returned an object like I demonstrated with SortedSequenceSearchResult, and they could have done it all the way back in Java 1.2.

I'm not arguing that; although the name suggests to me that your class is part of a broader set of "search results" which don't necessarily have to be "sorted".

It also seems perfectly reasonable to me, since an int is a natural choice for a search result, to rationalise its result set into "where I found the element" and "where I would have inserted it".

If you really feel you need to wrap that in a class, I have no particular problem, though I think yours is slightly OTT. Surely:
is sufficient.

1 year ago

Stephan van Hulst wrote:What gave me a headache is the terrible way they return the value...

What choice did they have? The value has to be negative, and it has to allow for the fact that "new" object/value might be first.

Oh, and it's an int, since the method predates all the weird and wonderful stuff you can produce today.

And if you can't handle a simple numeric conversion, you're in the wrong business. :-)

1 year ago

Pablo Napoli wrote:Is this right for you?.

Basically, but the more important question is: Why?

And the answer is that sometimes the JVM simply doesn't know how to continue.

The most common situations that arise inside a program are NPE (NullPointerException) and integer division by 0 (ArithmeticException), but there are other problems, like stack overflows and I/O issues, that the JVM can't recover from, so it throws an exception automatically.

Part of your job, as a programmer, is to foresee potential problems (especially NPEs) and try to deal with them before they happen so that the JVM doesn't have to.

Hope it helps.

1 year ago

Stephan van Hulst wrote:List.sort() accepts a Comparator<? super T> and not a Comparator<T>, because if it just so happens that I have a Comparator<Fruit> which sorts fruits by sweetness and I have a List<Strawberry>, then why shouldn't I be allowed to sort the strawberries with the comparator I already have?

I still say it's clumsy. A Comparator should take a Comparable, and very possibly a directed subtype.
To me, the "? super" business is confusing nonsense, and furthermore mechanical nonsense. The first thing you learn about supertypes and interfaces is that they are inherited by ALL subtypes, so why do I have to specify anything other than Comparable unless I want to be more specific??

I love Java, but it sounds like generics syntax is a mechanical issue, and maybe C# got it right (or 'righter').
I also wonder if it might be worth another look now that even standard Java APIs are becoming more complex (how many methods do Comparable/Comparator have now?).

I guess it's 4ยข now. :-)

1 year ago

Biniman Idugboe wrote:Is ? super T a single parameter?

Yup, and don't worry; it IS confusing.

The problem is that generics is a bolt-on to Java, not a native part of the language; and when it was implemented:
1. It had to be backwards-compatible with all existing code.
2. No existing code had any concept of a 'type'.

I think they did a pretty good job in the circumstances, but lots of constructs (like Campbell's example above) just look "messy" - even after ... what is it now? ... 10 years?

1 year ago

Dawid Smith wrote:Thank you guys for all the feedback.

You're welcome.

One other thing to think about (although I may get some disagreement here):
Arrays.binarySearch() does one other very useful thing, at almost no cost to the search itself.

If the search fails, it returns the index where the missing value would be inserted as a negative value. Some purists regard this as unnecessary, but to me it's simply adding value by providing a by-product of a calculation that you're already doing.

Such things have to be thought through carefully, but in this case I think utility trumps the bit of extra documentation needed.


1 year ago

Arun Singh Raaj wrote:because I want to know why insertion is slower in ArrayList. I understand in case of arrays that to insert a new element it has to shift rest all elements because they are stored in contiguous locations but ArrayList is a dynamic array so I guessed it also stores elements in contiguous locations.

I suspect it has to do with your assumption of what a "dynamic array" means, and it's certainly nothing like an awk "array".
My assumption is that it increases (and possibly decreases) in size as needed to hold all elements, but that has nothing to do with how fast it can insert an element, especially in the middle.

1 year ago

warren brandt wrote:i have come up with a small project for myself (though i'm sure its been done before)
I want to develop an ATM machine application...

Well, you've definitely got the first step right: You haven't started coding. Well done!

And I mean that quite seriously.

You've managed what maybe 5% of beginners can - explain to a bunch of old farts like us (very well, I might add), what you want to do, without using a line of Java code to do it.
And THAT suggests to me that you're going to be a good programmer.

Everything that you've described so far could be done in a dozen computer languages, and that's good design.

But now you want to get down to the nitty-gritty. In Java.

My suggestion #1: Start with creating a new user account, and for the moment forget everything else. No point in logging in a user until they exist, right?

As for your classes: Instead of UserAccount, BankAccount, and MainProgram, what about User (or Customer), Account, and ATM?
Same basic idea, but maybe a bit more focused:
A User holds information for a user: Name, address, dob, password (or - usually better - its encryption), etc.
An Account holds financial information about a specific User: Account #, current balance, overdraft limit...
And the ATM - which will probably end up being your "main" program - holds all the stuff that an ATM needs to know about - Accounts, Users, and the like - and goes though its cycle once for each User who sticks a card in the slot.

I suspect you'll find you need a few more classes, but the ones you've got are fine to start with.

But stick to one thing at a time.
Get that Create User function working, and don't even think about logging them in until you have it working Every.Single.Time, no matter how bad the input is.
Then, once you can create a User and log 'em in, maybe create an Account for them.
Then, when (and only when) you can do all that, worry about that second menu.

Don't get me wrong. It's great that you have a plan of what you want to do; but don't get too far ahead of yourself, because aspects might change, or you might work out a better strategy, and you don't want to tie yourself down too much.

Hope it helps. and again: Well done so far.

1 year ago

Biniman Idugboe wrote:

Don't worry, you're not the first to be puzzled by Java's type syntax; probably because it is NOT native, and therefore quite messy.
the first bit
<T, U extends Comparable<? super U>>
declares the variable types that a statement is going to encounter, specifically a T and a U.
Now we get to the
U extends Comparable<? super U>
All that says is that U is a Comparable that takes a type that is itself Comparable, even though it doesn't read that way.
(Comparable has caused a lot of problems - especially since generics was included - so I wouldn't take it as a model class; even though it's incredibly useful)

Just remember that the syntax '? super X' means "in the hierarchy of X", and it's purpose - by no means obvious - is to restrict X to a type that makes sense for the class (or method) - in this case, another Comparable.

The reasons have to do with backwards-compatibility with "pre-generics" code, and it is very clumsy.

1 year ago

Arun Singh Raaj wrote:I want to know, Since ArrayList is backed by array data-structure, do ArrayList elements get stored in contiguous locations similar to array's?

Answer: Probably. Nothing (or very little) is certain in Java.

Question: Why do you care?

The idea of any computer language is that it you trust IT to store information in the "best" way possible, be it contiguous, linked, or some form of hashmap.

That said, primitives are ... er ... primitive, so I suspect the language will try to store them contiguously if it possible can.


1 year ago

Dawid Smith wrote:Hello. I've attempted to code a recursive version of a binary search algorithm. It seems to be working, but I would love to hear feedback from you guys.

Oddly enough, your program contains the same mistake as almost all binary chops ever written, so don't worry, you're in good company. :-)

The problem is with the expression 'half = (a + z) / 2'.
It may look right, but it contains a dangerous flaw, which you'll likely never reproduce because all the lists you deal with will be too small.

The reason is that it will not always produce the correct result because of integer overflow.
If the sum of a and z is >= 2^31, the result will be a negative number, which the compiler will happily divide by 2, and screw up your lovely calculation.

Luckily, there is more than 1 solution:
1. half = a + ((z - a) / 2) - hopefully fairly obvious.
2. half = (a + z) >>> 1 - as fast as it gets, and guaranteed to work provided a and z are >= 0, but a bit "mystical", and not directly translatable to other languages.

For more info check out this.

Hope it helps.

1 year ago