Win a copy of Spring in Action (5th edition) this week in the Spring forum!

Liutauras Vilda

+ Follow
since Nov 12, 2014
Liutauras likes ...
London, United Kingdom
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 Liutauras Vilda

Guys, a reminder from what Tim already mentioned:

"Posts in this welcome thread are not eligible for the drawing, and should be reserved for welcoming the author. Questions posted in this topic are subject to removal."
6 hours ago
I'd say stick to second approach in this kind of situation. It is way more concise, more readable and has less places to go wrong, i.e.: by mistyping index.

Write angle brackets after the data type, and not the variable name.

int[] numbers

int numbers[]

Put spaces around '=', put spaces after ','.

int[] numbers = {1, 2, 3, 4};

int a[]={98,97,99,94,96};

Noticed variable name? Instead 'a', I've got 'numbers'. Better than 'a', but not very concrete. loterryNumbers would be better. Don't have 'a', 'b', 'z' as variable names (in most cases), they mean nothing.
6 hours ago

Tim Cooke wrote:I managed to get part 1 done by simply processing the input sequence from left to right also using recursion to collect all the meta values. It was quite tidy even.

Just had a look What?!? Recursion + Loop(s)? What is the feel of going down the root cheap way  

Tim Cooke wrote:Recursion and using variables declared outside of the recursive method Liutauras?

Which variables? Oh c'mon , just file (list) and toProcessChildrenOfLevel (map) , more optimism, please! instead of dealing with 4 parameters, need to cope only with 2. I kept them as fields of mutable data structures   so really to pass them as parameters didn't make sense that moment, except that doesn't make sense to have them as mutable and fields in the first place. Ok, let's call it a lazy (very) tackle of a problem, which at any given moment in time can (i'm sure it will) stab you to the back  
Trying to catch up.

Day 8 Part 1 done (if anyone still remember it), indeed was shouting for a recursive (which I like a lot) solution, except that initial approach ended up with StackOverflowException So had to do plan B - opt-in for tail call optimized solution.

Scala has @tailrec annotation which gives you a compile error if your function isn't tail recursion. So it is nice, I like it.

I must say it is damn too complicated to follow who hasn't spent a good amount of time on it, most likely there are simpler approaches, but I just ended up somewhere deep down in recursion mind with this one, so even coffee got cold.

I'm just now going from shopping mall, so well behind you guys. Hopefully tonight will have a chance to sit down and crack day 8 first.  Sounds like day 9 offers even more challenge.
Boys and Girls... I've nailed it, Day 7 (yesterday's) Part 2 done.

Definitely a fresh morning is more clever than tired night.

Yesterday I've done Part 1 in a less than opimum way, and that was the main reason why I was struggling with Part 2. Simply I was trying to accomplish 2nd part's requirements with Part 1 code, which was not well organized, in short - bad.

This morning I've deleted code and started over. This is what we suggest often, right? So took this advice myself

Watch my beauty:

Lesson learned:
Regardless, whether it is a puzzle or anything else - always pay tremendous attention to code organization. That way no puzzle is unsolvable.

I've got 2 today's puzzles to solve. Will do in an evening.
I'm just simply wandering somewhere around and don't see a light at the end of the tunnel, any end. Head is totally empty now. Probably will give up on this one tonight and will go sleep with an expectation for tomorrow. But tomorrow will be 3 problems to solve, instead of 2. But had similar situation last year, it was just day 3, a spiral problem, which caused me also a headache.
Nice organization and readability. Wouldn't be surprised if you even re-used some of the parts from last year's AoC when you created bunch of re-usable components.
Tim, don't tell me that for 2nd part of today's stuff you are going to implement concurrent version with BlockingQueue

I understand what is asked in 2nd part, just the labor work looks pretty annoying. Part 1 however was easy.
Solved Day 6 Part 2 too.

It was easy! Well, it meant to be easy...    Spent half an hour figuring out what is wrong with my algorithm as instead "total distance to all given coordinates of less than 10.000" I had 1.000 (one zero less), so got nothing as resulting area, and then started looking to wrong places what might be wrong. So then after noticing that got wrong figure from specs, said: "yayay, now all will be fine"!. Executed code, got result - bang! Answer is Too High! What? Well, it says "less than 10.000" not "less than or equal to 10.000", so spent another half an hour

Oh dear... all that today's misery ended finally. I have a feeling that this year is kind of a bit more difficult than last year. Or my Racket skills are better than Scala's. Missing #Racket #'N #Its #Recursion #To #Be #Honest

Tim, indeed, you beat me on this one, so now I'm behind.

As a bonus puzzle for us all, we can calculate the resulting area of the obtained stars in a whole private group, I think it shrinks slowly
Part 1 solved. Interesting one indeed. Will commit soon. Will be interesting to sneak into yours to see how you all solved it.
Frits, thanks for the cow!

Frits Walraven wrote:It must be good fun.

No, it isn't. Unless you solved it and watching others struggling. I'm the only one who hasn't solved yet. Started... I'm half way through in Part 1. Got all the areas of all coordinates. Except one thing - don't know yet how to rule out infinity ones So now all can laugh, but it isn't funny for me.

Liutauras Vilda wrote:...currently it doesn't look very complicated

shut up!

Stephan van Hulst wrote:It's tougher than the puzzles before for sure. I battled a bit with the first part, but the second part was comparatively much easier.

I just understood now the logic behind the given example. It took me about a half an hour (might even one hour) of constant looking to it.

Didn't try to implement yet, but currently it doesn't look very complicated. Will try as soon as I'm available.