Mike Simmons

Master Rancher
+ Follow
since Mar 05, 2008
Merit badge: grant badges
For More
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

Mark Sando wrote:and in this case, it's gonna be 4 different copies of the exact same string in heap, right?

Yes - but you don't need to keep them.  Once you have those 3 replies, you look up the NumberData object in the Map, update the object with the data from the responses, and you're done with that phone number (for now) - which means the references to those 4 objects can go out of scope, and they are eligible for garbage collection.  Only the one object referenced as the key will be retained.  If the same number is mentioned in 1000 future JSON requests, then you will temporarily see 4000 different String objects associated with the same number, but only 1 will be kept "permanently" as a key (or, until you send a report and can clear your data).  All the rest will be garbage collected.
2 weeks ago
It sounds like these numbers are coming in in separate JSON requests.  If you have several JSON requests for the same phone number, they probably have a distinct String for each number received.  However, once you use this to look up the NumberData in the Map, you can discard those other String objects - you only keep the one that's stored as the key in the map.
2 weeks ago
I think you probably want to create a Map<String,NumberData> instance - where the String key is the phone number, and NumberData is a class you write to collect the info you need to save for each number.  The Map will only save one instance of each key, so you will keep one String, and one NumberData, for each distinct phone number you encounter - update the NumberData object every time you have new info.  Then when you send a report and no longer need the data saved up so far, clear the map (or create a new, empty one and throw away the old one) so that all that memory can be freed up again.

If you're really concerned about memory usage, you can probably store the phone number as a Long instead, by dropping the dashes and doing a Long.parseLong().  To use it in a Map it will be a Long wrapper rather than a long, so it's another object that you might need to clear out periodically - but at least it will take somewhat less space than the String version.  I wouldn't spend too much time optimizing this unless you're actually experiencing memory scarcity, and unless you're also optimizing the NumberData class carefully.  You could also use a custom library like Eclipse Collections, where a class like MutableLongObjectMap will probably be more efficient for a primitive key.
2 weeks ago
Put these in a single file:
3 weeks ago
No, that's incorrect.  From the latest JLS:

Example 6.6-5. Access to private Fields, Methods, and Constructors

A private class member or constructor is accessible only within the body of the top level class (ยง7.6) that encloses the declaration of the member or constructor.

3 weeks ago
Some additional thoughts:

There are a lot of uses for static and inner member classes, for exactly the reasons that Simon just emphasized.  But local classes and anonymous classes? There used to be a lot of uses for anonymous classes.  In modern Java, lambdas can often better fulfill the needs that anonymous classes were most often used for.  So you may go quite some time without seeing anonymous classes used, depending on what you are doing, and how old the code you're working with is.  As for local classes... I very rarely see them, nor want to use them.  Especially since I usually have a strong desire to keep my methods short, short enough to easily be seen on a single screen, at least.  You may encounter local classes.  But you can probably not worry about the details much, as it's unlikely you'll see them much in the real world - other than for certification, if you're doing that.

As an aside: If, in learning about nested and inner classes, you ever encounter the phrase "top-level nested class", be aware that this linguistic travesty was removed from Java almost twenty years ago.  It was originally a term for a static nested class.  But since about 2005, "top-level" and "nested" are exclusive categories, as they should have been all along. If you encounter the term now, be aware it's quite outdated, and you should probably move to a newer edition of the book you're using.  Or a different tutorial, or article, or whatever.  Save yourself from needless confusion.

I sometimes feel as if Java's designers took the initial idea of inner/nested classes and generalized it it "you can declare a class almost anywhere, and we will figure out the consequences of that and write rules to allow you to do so".  That's an exaggeration, but I still feel there's some merit to this view.  For example, you can declare
a class inside a static method, or a static initializer block.  With an anonymous class, you can even declare a class in a static field declaration (as part of the initializer).  These are all inner classes, by definition.  And yet, there is no enclosing instance in these cases.  So you don't have access to one, and the compiler will complain if you try to access it.  So there's an additional category of "inner classes declared in a static context" which has special rules that are different from what others have described above.  More confusion for another special case.

3 weeks ago
I don't think there is any guarantee of order, regardless of any connection parameters.  ORDER BY is really the standard, proper way to enforce a particular order - they don't have an alternative.  For a particular database they might have documented the behavior, but there's no general rule.  Typically I would expect the newly inserted rows to appear at the end, but would never bet large sums of money on that.  If the database is distributed across multiple servers, especially worldwide, you can probably expect even more bizarre behavior.

Simon Roberts wrote:More than that. The *compiler* must be able to calculate the case value. It's literally a compile-time constant. It's not a variable in any way

Well, except in the sense that a "variable" in Java can be a constant variable, despite the linguistic non sequitur.  A variable in Java isn't a "thing that varies" - it's a symbol that refers to a value.  Which often may vary, but may be a constant.  So you can have a case value that's a variable which is also a compile-time constant.  

Of course that's not what Simon was talking about, and he's absolutely right in his main point that case values need to be compile-time constants.  For now.  But I wanted to clarify in case anyone reads it and thinks you can't have a constant variable as a case value - yes, you can.
3 weeks ago
Piet - congratulations!  Yeah, I was planning to use rotated coordinates to resolve intersections rectangles.  Back when I thought I would have to count all the excluded points.  But decided I could skip that for the question they actually asked.
Tim - I agree with you that the text explanation seems at odds with the example.  At best, the text is unclear whether you compare individual elements first, or lengths.  At worst, it sounds like the length comparison is first.  Which is contradicted in the example, yes.  But it you treat the example as the way to resolve ambiguity in the text, then you are good.
I hadn't heard the "hope" quote before.  I like it

Just solved day 15 part 2, w00t!  Both parts combined run in 3 seconds.  I kind of overthought this one - I was confident I knew what part 2 was going to ask before I actually read it, and I spent time thinking of clever approaches to this problem (while I couldn't actually write code).  But the actual part 2 was somewhat different than my expectation, and had a simpler solution - if you think about where to look.
OK, this new method speed up part 2 from about 0.4 sec to just under 0.1 sec:

This uses my previous code to populate the grid based on the input file (including the infinite floor for part 2) - the fill method just fills in the sand and returns the amount sand used. This was actually simpler than the original fill method, as well as faster.  Though the original had the advantage of being usable for part 1 and part 2.  This one only works for part 2.

[Edited to add:] Note that Vector here is not a java.util.Vector (ugh!), but a typealias for a custom class of mine, IntVector2D, that represents an actual vector in the traditional match/science sense, a quantity with two or more dimensions, e.g. x and y.   With some overloaded methods that allow me to add vectors easily with a + operator, things like that.  So "queue += p + it " actually means "queue.addLast(p.plus(it))".  I was previously calling this class Point (or IntPoint2D), but decided Vector is better since that's a more generalized term.  Sometimes it represents a delta between two points  rather than a point, for example.  I feel it's time to reclaim the term vector for its proper math/science usage.
How do you minimize a post, anyway?

I posted my own part 2 image in the main AoC 2022 thread, before seeing this thread.  If someone wants to minimize it there for me, or delete it, feel free, and I will put it in this thread instead.

I didn't really think of this as "brute force", and I can run parts 1 and 2 combined in 0.3-0.4 sec.  Is it possible you're printing too many intermediate results?  Output along the way can slow things down - especially giant ASCII images.  

Having said that, yes it's true that it seems like an even faster algorithm is possible, for part 2.  I may have to work that out too, for fun.  Good catch.

This was the most fun puzzle so far, for me.  
Ah, I was wondering where that 3-min run time came from.  That makes sense.

Re: Day 14: Nice job, Stephan!  I had posted my own picture for part 2, but later saw you have already done that in another thread, so now I've removed it.
I was busy over the weekend, and to catch up, I went in reverse, more or less.  Still coming.  It didn't look difficult, but you all had already solved it, so I figured I should go elsewhere first.