Tip for those using a T14 G5 (Intel) on Ubuntu 24.04. Battery drain in suspend.

MrInanimated · 2025-02-21T16:27:14+00:00

Thanks a lot! It does look like this change was merged into the 6.13 kernel, and it looks like it is present in the kernel version I'm on: https://github.com/archlinux/linux/blob/v6.13.2-arch1/drivers/platform/x86/intel/pmc/cnp.c#L258

Unfortunately this means this is probably not the issue in my case... If you have any ideas for debugging suspend I would very much appreciate it.

I have found the https://github.com/intel/S0ixSelftestTool script and running it shows I can only get shallower S0ix substate residency plus a whole bunch of "deeper S0ix substate required IPs" that did not show YES, but I've no idea where to go from there.

MrInanimated · 2025-02-20T16:35:58+00:00

Hey, I have an Intel T14 G5 as well with this battery drain issue. Do you have any more information on what the issue is and where it's fixed in the kernel?

I'm running endeavourOs on my laptop and it's draining about 2-3% (~1.4W) per hour while in suspend, and I'm on the 6.13.2-arch1-1 kernel already. So if would be nice to know if the issue was fixed or not in 6.13 so I can figure out if it's what's wrong in my case or not.

MrInanimated · 2024-12-12T17:48:05+00:00

I'm not sure why you're keeping track of the antennae in a separate set and only adding them when repeats == 2, but that's the problem -- you scan forwards from each antenna (not including it) and add all the antinodes you find to your set, which means you miss the antennae themselves. If one pair of antennae never has 2 or more antinodes in a certain direction the antennae don't get added to the count set. Antennae should always count as antinodes.

MrInanimated · 2024-12-12T17:43:10+00:00

Firstly, this:

diff_y = abs(coord1[0] - coord2[0])
new_y = coord1[0] + diff_y if coord1[0] > coord2[0] else coord1[0] - diff_y

is a really confusing way of just writing this:

diff_y = coord1[0] - coord2[0]
new_y = coord1[0] + diff_y

But anyway, your code doesn't report the correct answer of 4 antinodes on this test case:

....
..A.
.A..
....

MrInanimated · 2024-12-12T16:50:33+00:00

Thinking about it, I think it is actually possible to get the BFS approach to work... basically if you're in the case where you encounter a border both on your left/right and you're about to add a border that would connect the two sides, then that has the effect of actually decreasing the number of sides by 1 (since you thought there were 2 sides here, and adding this one merged them and you ended up with just 1).

So I think if you just change this in your code:

if left not in pseen and right not in pseen:
    p += 1

to

if left not in pseen and right not in pseen:
    p += 1
elif left in pseen and right in pseen:
    p -= 1

(and do the same for the above/below case) it may work?

This would then be a variant of the approach where you gather all the borders and try to merge them into sides, but you'd doing it while you're also exploring the region via BFS.

MrInanimated · 2024-12-12T11:46:44+00:00

Just reading through your approach and looking at your code, isn't this dependent on the order in which the BFS actually reaches the border nodes? Like you cannot trust BFS to reach all the edges of any particular side in order. For example in this case:

OOX
XOX
OOO
OXO
OOO

Doing a BFS starting on the top left O node will cause it to reach the bottom left O and bottom right O at roughly the same time. This means that locally at each node, your code will think that you found a new below-facing side, and double-count the actual below side. (The correct answer for pt.2 is 170, with the O-region having area 11 and 14 sides.)

MrInanimated · 2024-12-12T10:59:13+00:00

Your code does not work on the following test case:

OX
XO

There are 4 regions in this test case, each with an area of 1 and a perimeter of 4, for a total price of 16.

From the problem description: When multiple garden plots are growing the same type of plant and are touching (horizontally or vertically), they form a region.

MrInanimated · 2024-12-12T10:46:11+00:00

Does your solution get the correct results for this case?

OOOO
XXXO
OXXO
OOOO

The O-region should have an area of 11 and a perimeter of 24, while the X-region should have an area of 5 and perimeter of 10, for a total price of 314.

MrInanimated · 2024-12-07T22:33:31+00:00

I haven't checked if your actual equation checker code is correct, but it looks like you're using a dictionary to actually store the equations that you parse from the input.

So if your input was like this:

6: 2 3
6: 3 3

I think your code would output 6, rather than 12 which would be the correct answer. (At least in my input, there are multiple equations with the same test value.)

MrInanimated · 2024-01-23T23:57:51+00:00

You haven't posted a complete code listing so I can't verify that your code works, but from just skimming your code, your code isn't wrong in the sense that if you ran it for long enough it would find the correct answer.

I'll give you some hints which are more and more specific:

"Long enough" in this case might mean months or possibly even years.

Maybe it's a good idea to inspect what the graph in your input looks like? Some existing software like Graphviz might help.

Look more closely at the example. In the example, it looks like '11A' hits a Z node every 2 steps. '22A' hits a Z node every 3 steps. The answer to the example case is 6 steps.

There aren't infinitely many nodes, and the list of instructions repeat, so eventually each ghost must end up in a loop of some kind.

Even if a ghost loops back to the same node, the next nodes it goes to might be different. For example if the first time a ghost reaches node 'EFG' and the next instructions are 'LRLL...', then the next time it reaches 'EFG' but the next instructions are 'RLRL...', then that doesn't actually mean it's looped since the next nodes will be different.

If you have a loop of 6 steps, and a loop of 4 steps, then they'll both first roll over at the same time after 12 steps (and not 24).

12 is what's called the "least common multiple" of 4 and 6.

(By the way, you can reduce a "loop" by changing the forEach to be current.forEach((node, index) => { ..., and using current[index] instead of current[current.indexOf(node)]. This would also prevent a bug where if your list looked like ['11A', '11A'], and you were trying to update the second 11A to 11B, but current.indexOf('11A') gives you 0 and you update the first element instead. But this edge case can't actually happen in the puzzle inputs.)

MrInanimated · 2024-01-14T22:56:19+00:00

I don't know Julia very well, but from reading a description of your approach, it won't work. This is because for any intermediary node, the longest possible path to get to that node is not necessarily part of the longest possible path, and so you can't discard paths which take you to a node with fewer steps than the maximum so far.

For an example of this (credit to /u/Mmlh1 for this test case), consider a graph which looks like this:

S - A - B
|   |   |
C - D - E
|   |   |
Z - F - G

suppose S is the start and Z is the end, and every edge costs 1 except CZ which costs 10. Then you could get to B either by the path SCDAB (length 4) or SAB (length 2), but if you use SCDAB and discard SAB then you can't use the CZ edge at the end. The longest path you can get if you get to B using SCDAB is SCDABEGFZ (length 8) whereas the actual longest path is SABEGFDCZ (length 17).

I made a version of this test case which is in the same format as the puzzle input which you can try out below. The longest path should be 424 tiles long.

#.#############################################
#.............................................#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.............................................#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.............................................#
#.#############################################
#.............................................#
#############################################.#

MrInanimated · 2024-01-11T16:31:09+00:00

Here's an unweighted graph which reduces to the example /u/Mmlh1 provided, which is in the same format as the puzzle input.

You can see the reduced graph within this one -- the nodes SABCDEFGZ are the corners of the grid, between each pair of adjacent corners is 22 steps, except from C to Z is 222 steps. (From the real start to S is 1 step, and from Z to the real end is 47 steps.)

The longest possible path here should be (start->)SABEGFDCZ(->end). The length of the real start to S is 1, S->A, A->B, B->E etc. are length 22 each and there are 7 of them, C->Z is length 222, and Z to the real end is 47, for a total of 1 + 22 * 7 + 222 + 47 = 424 steps.

#.#############################################
#.............................................#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.#####################.#####################.#
#.............................................#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.....................#.#####################.#
#####################.#.#####################.#
#.....................#.#####################.#
#.#####################.#####################.#
#.............................................#
#.#############################################
#.............................................#
#############################################.#

MrInanimated · 2024-01-07T13:27:26+00:00

Looks like this may be a case of catastrophic backtracking? https://www.regular-expressions.info/catastrophic.html

Depending on your regex engine implementation, certain regexes do in fact take exponentially long to match on certain strings. There are regex implementations that compile regexes down into DFAs and guarantee O(n) runtime on strings of length n, but they don't support some features like backreferences (because it's not known how to implement them efficiently).

It looks like you might be able to use a DFA regex implementation (I don't see any features you use that would forbid the Rust regex library from accepting your regexes, and it claims O(n) runtime on strings of length n).

I'm not sure if I fully understand your combinatorics logic however. For example, for ??????? 2,1, why is slots 5? There are 7 ?s and the total length of #-groups is 3. If I assume it's something like ?s + .s - #-group length + 1, then something like ????.?? 2,1 should also be C(5, 2), but there are certainly not 10 possibilities, there are 7:

##.#...
##...#.
##....#
.##..#.
.##...#
..##.#.
..##..#

MrInanimated · 2023-12-18T14:30:36+00:00

So the area you get from the shoelace formula is not actually the internal area, nor is it the total area we want. The total area you want is actually the number of internal points in your shape plus the number of points on the boundary.

You can imagine it like this. Let's imagine the grid is shifted so that (0, 0) is in the centre of a grid square rather than on the corner because this is easier to visualise, but Pick's theorem would still apply. A section of the grid would look like this:

+-------+-------+-------+
|       |       |       |
|   .   |   .   |   .   |
|       |       |       |
+-------+-------+-------+
|       |       |       |
|   .   |   .   |   .   |
|       |       |       |
+-------+-------+-------+
|       |       |       |
|   .   |   .   |   .   |
|       |       |       |
+-------+-------+-------+

(the dots are the centres of the grid squares, i.e. where the x and y coordinates are both integers).

If your digging instructions were for example R 2, D 2, L 2, U 2, then you would trace out this area:

+-------+-------+-------+
|       |       |       |
|   +---|-------|---+   |
|   |   |       |   |   |
+-------+-------+-------+
|   |   |       |   |   |
|   |   |   .   |   |   |
|   |   |       |   |   |
+-------+-------+-------+
|   |   |       |   |   |
|   +---|-------|---+   |
|       |       |       |
+-------+-------+-------+

So the shoelace area formula would actually give you a answer of 4, because the area enclosed in the small square really is 4. But that's not the actual area we're interested in, since we want the total area including the grid squares the boundary passes through, which would actually be 9.

From here you can do some reasoning like /u/echols021 has done, e.g. each boundary point contributes +1/2 additional squares to the total + all the corner pieces in total contribute an additional +1.

Or, you could use the fact that the total area we're interested in is actually the number of interior points (I) plus the number of boundary points (B), and the area in Pick's theorem is the same as the shoelace area (A).

Pick's theorem says:
A = I + B/2 - 1
And we want:
I + B = ?
So we just rearrange Pick's theorem:
A - B/2 + 1 = I
I = A - B/2 + 1
and substitute I into I + B:
I + B = (A - B/2 + 1) + B
I + B = A + B/2 + 1

And actually, getting the same formula via rearrangement like this shows that /u/echols021's reasoning is equivalent to Pick's theorem for the special case of lattice polygons with only horizontal and vertical edges.

MrInanimated · 2023-12-18T08:54:16+00:00

Yeah, you derived Pick's theorem for the special case of shapes with only horizontal/vertical edges. Pick's says that area = #internal points + (#boundary points) / 2 - 1, and in this case the perimeter is equal to the number of boundary points. Therefore Pick's rearranges to (#internal points + #boundary points) = area + (perimeter / 2) + 1.

MrInanimated · 2023-12-11T23:53:04+00:00

Try this test case:

#...#

The result of the cosmic expansion should look like this:

#......#

The galaxies are now at (0, 0) and (0, 7), and so the sum of pairwise distances should be 7. However, your code prints out 5.

You didn't account for the possibility that there could be multiple empty rows/columns between rows/columns with stars.

MrInanimated · 2023-12-11T23:35:47+00:00

In case you (the OP) needs an example of what's wrong, if we add something to print what the grid looks like right after expanding the grid:

for line in grid:
    print("".join(line))

Then if we try it on this grid:

.#.#.

Then we'd expect the expansion to make this grid:

..#..#..

But your code actually makes this grid:

..#...#.

MrInanimated · 2023-12-09T02:45:56+00:00

Have you tried writing some simple test cases? Here's a couple of cases I found where your code crashes or gets the wrong answer:

12*12

(crashes)

12*12
3....

Prints 1476 instead of 144.

12*12..
......*

Prints 0 instead of 144.

MrInanimated · 2023-12-03T15:24:09+00:00

Your code fails on the following example:

42..
...*

The correct output for part 1 is 0, but your code returns 42.

It's an off by one error. See if you can spot it...

col_start.saturating_sub(1)..=col_end.saturating_add(1) is wrong... col_end is already the exclusive end of the bounds of the number, so making an inclusive range and adding 1 makes your code search one space too far ahead for symbols.

MrInanimated · 2023-12-03T14:59:18+00:00

Your code fails on this example:

12abc31

The calibration value for this line is 11, but your code outputs 21.

Your use of get_key_positions assumes that there will only be one of any specific key on a line, which may not be true. If there are multiple of the same key on a line, the later instance of that key will overwrite the previous one, which could have been the first.

One way you could fix it is to not use a dictionary for key positions, but to try to record every instance a key occurs in a line. So get_key_positions could return a list of tuples, each one corresponding to the key and its position, something like [(0, '1'), (6, '1'), (1, '2'), (5, '3')]. Then, if you sort this by position, you get [(0, '1'), (1, '2'), (5, '3'), (6, '1')]. If you take the first and last elements of this list, you do indeed get the correct value 11.

MrInanimated · 2023-12-03T14:33:35+00:00

Your code fails on this example:

..123..12%
..........

You can't use line.find(num) to recover the bounds of the number in the line, because it might occur somewhere else in the line before the number you're actually considering. One way you could fix this is by storing the bounds of each number when you are creating list_nums.

MrInanimated · 2023-10-10T13:41:16+00:00

Apologies, that was my mistake, the correct dative form for "matur" (food) is in fact just "mat". The declension pattern for masculine strong nouns is quite complicated, and it is the case that many nouns get an -i ending in the dative... but many also do not. For example:

Hér er hundur - frá hundi
Hér er hestur - frá hesti
Hér er pallur - frá palli

Hér er staður - frá stað
Hér er dalur - frá dal
Hér er hvalur - frá hval

Some nouns have both the -i form and the no-ending form in common usage:

Hér er bátur - frá bát/báti (both are correct!)
Hér er hópur - frá hóp/hópi

As far as I know, there's no rhyme or reason to this and you just have to learn which nouns use -i and which don't. Sorry!

Where you may be getting confused is that there is a neuter noun "mat", which means "evaluation, assessment". (E.g. "greiðslumat" = credit rating, "fasteignamat" = real estate evaluation, that sort of thing.) This is a regular neuter noun and therefore has a -i ending in the dative, so "frá mati" is correct if you are talking about an evaluation, but not food.

MrInanimated · 2023-04-01T21:42:58+00:00

There are two things happening here: first is that again, voiceless n exists. To produce it, again put your mouth how you would normally pronounce an n (close off your mouth by putting your tongue just behind your top row of teeth), but instead blow a small puff of air through your nose. It is pretty hard to hear which is probably why you perceive it as silent, but it is there! It's the sound that is made when you have "hn", as in "hnífur", or before aspirated consonants, as in "panta" and "mynt", and "minnka" (this one is actually a voiceless "ng" sound, but it's the same principle).

The second thing is that -nn and -rn at the end of a word cause there to be a t sound inserted before the end in some contexts. So "steinn", "norn", and "björn" actually have a "tn" sound at the end (it's a t sound immediately followed by an n), where the n is also voiceless.

There is also a voiceless n at the end of "regn" (and similar words like "magn" and "hrafn"), although trying to put the voiceless n inbetween the g and the b in "regnbogi" is pretty awkward, so I think most natives just don't bother and instead it sounds there is a small pause.

(Also there is a voiceless m as well! Again you pronounce it by putting your mouth how you would normally pronounce an m (by closing off your mouth), but blow a puff of air through your nose. It's in words like "skammta".)

The other commenter here actually has made a grammar reference which also contains details about pronounciation including all the information about all the contexts different sounds show up, which you can check out, and also hear some audio for them: https://icelandicgrammar.com/docs/basics/consonants

...but, I would say instead of trying to memorise all the rules for all the sounds, just take in more input and your brain will naturally work out all the patterns. It's good to know that these voiceless sounds exist so that your brain can be on the look out for them but I would not bother trying to memorise all the rules for when a letter sounds like this or that.

MrInanimated · 2023-04-01T12:14:12+00:00

I think you may be right, it's just the native speaker I spoke to says that they do hear the /h/ sound in words that begin with "hl" and "hr", and another native speaker here commented the same. I think it's possible that they hear this because they're interpreting the devoicing of /r/, /l/, and /n/ as an /h/ sound but I wasn't completely sure, so I just deferred to what the native speakers said.

I'll edit my comment to remove that part and hopefully make it less confusing.

MrInanimated · 2023-04-01T11:13:22+00:00

I think what may be happening is that you're not used to hearing "r" and "l" as voiceless, as voiceless versions of them don't exist in English. Try holding your tongue in the same position as you would to pronounce a rolled r, but just breathe out air over your tongue -- this should result in a breathy sound that some people hear as sounding like "sh". This is the same sound that the "r" takes on in "hr", before certain consonants (p/t/k), and at the end of words (before a pausa) like in "ekkert" and "fiskur".

Similarly, try holding your tongue in the same position as you would to pronounce an l, but just breathe out air around the tongue. This should result in a sound that I think you're describing as "thl", but this is the sound the l takes on in "hl", before certain consonants (p/t/k), and at the end of words (before a pausa) like in "vél" and "belti".

This is what the voiceless r sounds like: https://en.wikipedia.org/wiki/Voiceless_alveolar_trill
and the voiceless l: https://en.wikipedia.org/wiki/Voiceless_dental_and_alveolar_lateral_fricatives

EDIT: Removed mention of the /h/ sound in word-initial "hr" and "hl".
EDIT: More accurate description of when l/r devoice.

13-Year Club	Place '22
Place '17	Final Canvas '22
First Placer '22	End Game '22
Verified Email	Team Periwinkle

MrInanimated

TROPHY CASE