Win a copy of Rust Web Development this week in the Other Languages forum!

Mike Simmons

+ Follow
since Mar 05, 2008
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 Mike Simmons

Tim Holloway wrote:

Carey Brown wrote:You do know that varargs will accept an array, right?

No I don't. Inside the method itself, the varargs looks like an array, but consider the following:

Here a1 is a char[], and varargMethod() is expecting either an Object[], or a variable number of Objects.  But the thing is, a char[] is not an Object[].  Because chars are primitive, you could never cast a char[] to an Object[].  So there's no question on this one, varargMethod() cannot see this as single Object[] containing chars; it has to see it as an Object[] containing one element, which is a char[].

In the technique which Carey and I are promoting (which, by the way, you can compile and run to see that yes it actually does work), there is more potential ambiguity, I admit.  We are creating an actual Object[], and varargMethod() could see this either as a single Object[], or as an Object[] containing exactly one element, which is another Object[].  But basically, the rules of vararg invocation force it look for the simpler version first, first considering Object... to mean Object[], and looking for method invocations that contain an actual Object[] before considering creating a new Object[] to contain whatever it needs to stuff into the available slots.

For all that, this is a good reminder why it's often good to avoid varags of type Object... - because really anything can get stuffed into an Object[], not necessarily in the way you expect.  But if you offer an Object[] that's already packaged the way you want, it works smoothly.

As for pronunciation, I pronounce varargs to rhyme (almost) with "car parks".  But then, I also pronounce "var" to rhyme with "car" rather than "care".  English has never been strong in consistency, why should I be?
6 hours ago
Or more directly:

The problem here has less to do with varargs than with the fact that you had an int[] array and need an Object[] array.
12 hours ago
To be fair, most fractional numbers cannot be represented precisely in decimal either, without using infinite space.  It's just that we're used to that, and normally only worry about the numbers that *can* be expressed precisely in decimal.  

One could also argue that "most" numbers can't even be expressed as fractions.  But we live with that, too.
3 days ago
To be honest, I also take a certain perverse glee in using Kotlin to do things in that Java would not allow.  So part of me does want to access a local variable in a closure, just because I can.

Junilu Lacar wrote:Seems to me a name like "distance" instead of windowSize would make more sense.


Using windowSize creates some dissonance with the usage of windowed(size = n), I think that's what was bothering me.

Hm, I still don't get this - it's the same concept.  A "window" is the moving subset of the list/array that we're interested in performing a calculation over, and seeing how the result changes.  You and I both   Yes, you also use windowed(size = 2) to look at the changes between adjacent elements, and I don't, so I'm not particularly concerned with that other usage.  The concept of a window is not limited to whether we actually use the windowed() method.

Junilu Lacar wrote:Also, while I'm not really averse to reaching outside of a closure

I'm not averse to it at all, especially if we're calling it a closure.  That's the point, it's able to access free variables in scope.  I'm not concerned with avoiding that just to avoid that.

Piet Souris wrote:Note that with all the fine optimalizations and Kotlin-excellenties, that it only works when the window-stepsize is 1 and the function to apply is suitable, like sum or prod. Try it when the function is say max (window).

Well, the specific combination of optimizations I got only works under those conditions, true.  But the most important part of what I was doing, in my opinion, was going from an O(N*N) operation to an O(N) operation, by means of looking only at what's newly entering the window, and what's exiting.  We don't need to calculate each new window  from scratch.  You may need to perform the calculation on the entire first window, though that was not needed here.  That technique can also be used for other step sizes, and retain O(N) overall.

The point about it only working for a suitable function is valid - but there are still a wide number of functions it can be applied to.  The key is, we need to be able to pull elements out of the calculation as they exit the window, based only on their value.  You give max() as a good example where that won't work easily - once the max value exits the window, how to we know what the new max value is?  A fair point.  I think there's still be a way to do this using a sorted collection, where we end up with O(N*log(N)) overall, still better than O(N*N).  Still, there are many calculations out there that you can do this for.  I've done something like this for applying least-squares curve-fitting to data points as they come in, for example.

Of course, most of these considerations are overkill for something like this day 1 exercise, where O(N*N) is just fine.  Stephan's point about barfing out crude code to get a solution quickly is very much the case for me as well.  (Though, curiously, my day 2 code came out pretty pristine this time.) Most commonly I have a lot of print statements as I go, that get commented out as I see things working correctly.  And it's often one big main() method, unless and until I feel the need to extract methods.
We're using our windows for slightly different things.  I'm using a window for the region over which we would calculate the sum.  In part 1, the window width is 1, because it's one element at a time.  This is a degenerate case where we barely recognize the notion of a "window", but it still works - a window of width 1 has just one element at a time.  In part 2, the window width is 3, because we're summing over 3 consecutive elements.

Note that I'm using exactly the same code for parts 1 and 2 - I just switch between 1 and 3.

(I also don't actually calculate the sum, because we're only interested in changes in the sum, which I get by comparing what is coming in to the window, with what is going out.)

In your code, you've got more differences between part 1 and part 2 than just the numbers 1 and 3.  Your window of size 2, that's what you use to compare two adjacent values, and you use it in part 1 and part 2.  Whereas your window of size 3, that's the one you sum over, and you use it only in part 2.

Here's how I would modify your code to better compare with mine:

Now you can clearly see the same code for part 1 and part 2, except for the difference between 1 and 3.  Of course, it may seem silly to do a slidingWindowSums(list, 1) because that changes nothing - it's a sum over 1 element at a time, identical to the input list.  It's a no-op, why bother?  But in my code I'm not doing the sum anyway, rather jumping straight to figuring out whether the sum would increase or decrease.  For that, it's useful to have that window size parameter 1, representing how far apart are the elements I actually need to compare.
Thanks for pointing out the it.toInt() - I'm still stuck in some Java-isms.
Eh, Java does OK on this one:
Just refactored as:
I also used Kotlin - but I didn't know about windowed(), cool!

Here's mine:
More generally:


you can guard against a being null by flipping the order around:

This is great if b is a constant, or something already known to be non-null.  But, what if both a and b might be null?  In that case, another option is:

This uses a standard library method to do the annoying null checks for you.  Otherwise you have to go through something like

which is already tedious, and looks muck worse if a or b are replaced by much longer names.
1 month ago
@Carey, yes, that's what I was hinting with the last line of my previous post.

@Sean, thanks for posting Server.  That's very close to what I had filled in separately, and now when I replace my code with yours, it still works smoothly for me.  So so I think the problem is elsewhere.  Hmmm...

The only other code I had to fill in for myself was the Game class.  I provided a minimal mock implementation:

When I run this, I get this output from the server:

And this output on the client:

So... if you replace your Game with my code, do you get the same results?  If so, we may need to look at your Game code.
1 month ago

Campbell Ritchie wrote:Don't use nextLine(); use nextInt() instead.
As for why you are getting an empty String, look here.

I don't think that has anything to do with his current problems... and if anything, wouldn't it create problems, unless you follow the nextInt() with a nextLine()?  Using nextInt() saves you some annoying try/catch code, which is good but you need to explicitly go to the next line afterwards.

@Sean, I was able to get that code to work fine on my machine, at least as far as the getPlayers() method is concerned.  But I had to add my own code to set up the ServerSocket and start a ClientHandler - I think that may be where your issue is.  Can you show more of your code, specifically how the ClientHandler is initialized and where its Socket comes from?

Also... when you get to testing getCount(), you may want to reread the first part of this thread.
1 month ago