Winston Gutkowski

+ Follow
since Mar 17, 2011
Winston likes ...
Hibernate Eclipse IDE Ubuntu
Merit badge: grant badges
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).
For More
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

About the only thing I can add to the excellent advice you've been given is to
1. Turn your computer OFF.
2. Write down the problem in English (or your native Language), including any questions you have, or things you don't understand.
3. When coming up with a solution, concentrate on What Not How.


2 years ago

Campbell Ritchie wrote:Winston, welcome back

Thanks mate. Thought I'd look around the old homestead.
2 years ago
I think you're doing fine, and I particularly like the fact that you're explaining each step in your code. You'd be amazed how many experienced programmers forget to do that.

I also like the fact that you've named your method expand(), because that's exactly what it's doing. It's also a verb, and methods are usually actions of some sort.

However, what I don't like is that your method takes no parameters and returns no value. This makes it highly "coupled" - meaning that it doesn't stand on its own.

If you look at Junilu's example, his method takes the original array as a parameter and spits back a "modified" array, so the only thing left to do is assign it somewhere. And his code never references anything outside the method.
This is called "re-usability" and means you can - for example - copy and paste it into another program to do something similar, or (probably better) add it to a static library of generic "Array" methods, which is precisely what java.util.Arrays is.

As you go forward, what you'll discover is that most methods follow the "IPO" pattern - IPO standing for "Input - Process - Output".
That is: they take an input (in your case, an array), perform some sort of process on it (in your case enlarging it), and produce a result (the expanded array).

So the general signature pattern for most methods is:
{public/protected/private} final return-value method-name(parameter1, [parameter2, ...])

And don't forget that "final", even though it's redundant for private methods. Just get into the habit of adding it, because one of these days it will save your bacon. :-)


2 years ago

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)).

4 years 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.

4 years ago

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

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

4 years 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.

4 years 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.

4 years 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. :-)

4 years 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.

4 years 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. :-)

4 years 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?

4 years 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.


4 years 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.

4 years 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.

4 years ago