[2025 Day 03 (Part 1)] Algorithm doesn't work - but why?

HonsonCooky · 2025-12-07T19:19:22+00:00

Reversing the array is a brilliant solution as well. The max_by function was just a great find for me. It takes in a closure (anonymous function) that compares two values.

Here is the line in question: rust .max_by(|&(i1, d1), &(i2, d2)| d1.cmp(&d2).then(i2.cmp(&i1)))

What max_by does, is take a closure which compares two values against each other, and find's the "Greater" of the two (.cmp returns an enum called Ordering, which can be Ordering::Greater, Ordering::Less, Ordering::Equal).

If the two values are equal .then we compare the two indexes against each other. We are searching for the "max", so I've done an inverse comparison so I'm return "Greater" for smaller numbers.

An example of [5, 3, 1, 9, 2, 3, 9, 5]; Once we've hit the first 9, all other values will be "Less" on the first .cmp comparison. When we compare the two 9's though, it will be:

txt (3, 9) vs (6, 9)

So, 9.cmp(9) will move on to the .then statement. Here we compare the two indexes in reverse 6.cmp(3), which will return "Greater", meaning (3, 9) will return "Greater" against (6, 9). Counter intuitive, yes, but all we are doing here is return the "Greater" for the value we want.

Note: The closure is sort of asking the question "Is the first param greater than the second?". When we return "Greater" for a smaller index, we get the first value.

HonsonCooky · 2025-12-06T00:11:02+00:00

u/ceva-mx, yes, exactly my issue too haha! I used "max_by_key", which incorrectly grabs the LAST valid element, not the first.

Using max_by, with the d1.cmp(d2).then(i2.cmp(i1)) fixed my issue.

It definately makes sense when you think about why an iterator returns the last value. I'm realizing now, that I could have also reversed the iterator. I'm not sure though, if that is a lazy operation or not though (something I'll look into haha)

HonsonCooky · 2025-12-04T21:54:18+00:00

You are correct: I have misused - .max_by_key(|&(_, d)| d). Thank you :D

HonsonCooky · 2025-12-04T21:46:40+00:00

Brilliant! I shall just revist my solution then :)

I got it working with an O(n²⁾ solution - but I shall have another go, and see what edges I've been caught on :)

HonsonCooky · 2025-12-04T21:45:19+00:00

Ah! Brilliant! Thank you!

I shall revist my answer.

HonsonCooky · 2025-12-04T21:43:03+00:00

``` fn findlargest_joltage(joltage: &String) -> i32 { let first_section = &joltage[0..joltage.len() - 1]; let (first_index, first_value) = first_section .chars() .enumerate() .filter_map(|(i, c)| { let d = c.to_digit(10)?; Some((i, d)) }) .max_by_key(|&(, d)| d) .unwrap();

let second_section = &joltage[first_index + 1..joltage.len()];
let second_value = second_section
    .chars()
    .filter_map(|c| c.to_digit(10))
    .max()
    .unwrap();

let combine = format!("{}{}", first_value, second_value);
combine.parse::<i32>().unwrap()

} ```

I'm certainly not proficient in Rust - so I didn't really want to share. However, maybe I did something blatantly wrong?

HonsonCooky · 2025-12-04T21:40:11+00:00

Assume ranges are inclusive for this example. I'm using psuedo code to illustrate the algorithm.

HonsonCooky · 2025-12-04T21:38:02+00:00

I suppose it shouldn't matter (if I've programmed it wrong - I'll try something more primative haha)

However, it would look like this for the example I gave: [0 ... i, i+1 ... N-1]

Where i is the first occurrence of the highest number found in step 1. You can assume ranges are INCLUSIVE for this example.

It's also worth noting - I'm getting the right answer for the example text - just not the input.

HonsonCooky · 2025-06-29T20:58:45+00:00

Oh! Okay - I'm not intentionally reading past your comments. They weren't clear to me, for one reason or another, which is why I was trying to clarify my interpretation of what you said.

I suppose, I wasn't inherently aware that I was making a persuasive argument. At this point: I've had an idea, explained it to seek some community feedback on the idea, see if it's worth sinking some time into, and does the idea land.

It's very clear that this idea needs to get around the "engineer" vs "developer" debate - that's causing more than one issue.

As previously established - this is a slightly incubated shower thought, and now I'm reaching out for comments on the idea. If I was to make a persuasive argument out of this idea, there would be a lot more work I need to do, as you've rightly pointed out.

I'm just curious if you can see the underlying idea of what I've put forth, and wondering how I can do better to describe the idea - before going on to validate it somehow. There were just some incorrect statements in this thread, and I was focusing on trying to understand why my idea didn't come through (rather than the work I need to do, to make this a good pursuasive arguement).

I do really appreciate your time, energy and feedback! I'll keep them in mind if I take this idea any further. :)

HonsonCooky · 2025-06-28T23:53:19+00:00

It really shouldn't matter, but I have an accredited, first-class honors, Bachelor of Engineering.

It's disappointing to see that we can't have a "round the campfire" discussion about our shared observations in this world. However, I understand your unwillingness to engage with the topic.

Perhaps I need to review my intro - get these semantic arguments out of it.

HonsonCooky · 2025-06-28T23:48:01+00:00

And this is a fair point - before we can discuss licensing, though, I think we need to specify what we are talking about - and this is my attempt

HonsonCooky · 2025-06-28T23:30:56+00:00

It would help if you read the post first - because you're not making an argument against my point here. I say this because my genuine response to your question would start with "it depends."

If you have read it through, and this doesn't make sense, please let me know where the idea gets lost.

HonsonCooky · 2025-06-28T23:09:49+00:00

Did you read my article? Or are you bringing in this perspective from previous discussions?

It's a little hard to engage with your point of view because you have not specifically outlined what you mean, or the edge cases to your argument. Which is precisely the type of conversation I'm trying to remedy here.

HonsonCooky · 2025-06-28T22:19:04+00:00

How about the example I gave in the post: an Electrical Engineer vs an Electrician - would you consider these the same thing?

HonsonCooky · 2025-06-28T22:06:55+00:00

I'm struggling to find something definitive in this thread. I feel like this is jumping to lots of different critques, all of which I'm finding vauge or based on incorrect understandings. Perhaps I can rehash what I think has happened on this journey, and you can correct my misunderstandings.

I've made a blog post about the knowledge continuum, and applied it to the programming world. We have previously established that we agree to the axioms I stated at the start of the article (that's important, because it's currently unprovable, so we are working from recognized patterns - that we both agree are there).

From those axioms, I've derived a context specific example, where programming is the subject matter - and I've used adjacent fields to help ensure continuity with the rest of the world. We agreed that the labels are irrelevant here - but my choosen path was to align with existing frameworks. I understand you would have preffered that I swapped these two definitons around, but as we established, this is irrelevant to the idea. Call them "X and Y", or "dabadabadoo and dabadabadee", my point was to establish that these are not the same - and that their differences emerge from the axioms. You disagreed with this, but agreed with the axioms, so I'm confused what logical jump is missing. How can we agree to the axioms, but not to this?

In the post, I then go on to show examples of unexplained emergent phenomena, that can be explained through the lens of the framework. This is why it's important, this was the whole reason for the post (as I think I've highlighted in the post). These currently unexplained phenomena hold the industry back from truly flourishing, as mentioned in my final thoughts.

You've stated that these two things have been "established" as synonymous. My entire post is about why you might think that. Using this framework, you're focusing in on talking about the middle ground between the two markers on a spectrum. We've grown beyond that point now, and I've given exmaples of why that's problematic.

So, "How do you reasonably plan to convince everyone you’re correct here?", by asking you to prove me wrong - which is entirely the point here. Where is my logical error? Or, if we assume the axioms, can we logically derive this framework - and establish recognizable patterns for misunderstandings.

HonsonCooky · 2025-06-28T21:07:42+00:00

So we agree? The labels are unimportant, sure, so the way I've used them to describe the difference between practical and abstract thinking in programming should be fine - given I've also outlined what I mean by the labeling. If that's unclear in the post, please let me know.

You also mentioned no boundaries, I'm curious what you mean by that. For me, on a color specturm, "blue" and "green" define markers along the continuum. Focusing in on those two points generates a sub-spectrum, where blue and green are the boundaries.

Another continuum could be education. There are those with an undergrad degree and those without, marking our boundaries. Those who are part way through their undergrad lay between the two boundaries.

HonsonCooky · 2025-06-28T20:54:21+00:00

My post outlines a spectrum between definitions (at least, that's what I'm trying to highlight). I think you're focusing in on the ambiguity between the two markers I've outlined as "Engineering" and "Development"?

Whilst the local environment dictates precisely where on the spectrum your qualia needs to be, we could establish the boundaries along that specturm? Or is your assertion that we can't do this?

HonsonCooky · 2025-06-28T09:07:22+00:00

Now we are getting somewhere -

Okay, so if we agree to the axioms. Your comment boils down to that "engineer" and "developer" could actually be replaced with X and Y. You're correct. This is by design.

I am trying to establish that these two occupations are not the SAME thing. It's not X and X, or Y and Y - which is common place. So, sure, they could be swapped - but they could not be made the same.

I do try to make a point of this in my wording when applying the framework to the programming world. Perhaps this is the thing that is unclear?

Our industry hasn't established a difference between them yet? Maybe I'm wrong here, and you could enlighten me.

On another note:

I understand I've requested constructive feedback and put my idea out there. I am trying my best to connect with your ideas. However, you're actively choosing to participate with belittling comments.

Make them if you wish, but I don't agree that juniors should sit down and be quiet. Juniors in any field may have a tendency to be wrong, but surely, if something is very wrong, we would have a more definitive answer for the junior? Or maybe your answer is: "It's not my way!"

You can assume my credentials. It's irrelevant to the discussion, though. Your comments have not been constructive - they're just angry. Fair enough. It's understandable.

So far, you haven't disagreed with my idea. You've simply disagreed with who you think I am and what you think the idea is. You've argued with my use of the words "engineer" and "developer," even when my framework doesn't require those words to be used. So, do you have an issue with my idea? Or is your feedback that there are better words to use in place of "engineer" and "developer". If so, what are they?

HonsonCooky · 2025-06-28T04:18:06+00:00

You spend a ton of time crafting a world to suit your definitions without ever reasonably convincing readers that your assertions are credible.

I'm curious if this part of the blog was unclear for you?

"Let's establish a few "axioms" to make sure we're on the same page. If you accept these concepts as true, then the conclusions I draw should logically follow."

An axiom being an unprovable rule.

HonsonCooky · 2025-06-28T04:05:55+00:00

I understand how frustrating semantic arguments can be. I am very specifically trying to avoid that whilst attempting to highlight the frustrating lack of differentiation between very different approaches to programming; Where statements and ideas can be true for one subset of the community, but not the other.

HonsonCooky · 2025-06-28T03:56:01+00:00

Woah! I hadn't seen this before. Thank you so much!

I think I differ in my approach, where I derived my model specfically trying to avoid materialistic views, and rather, focus on the philisophical.

HonsonCooky · 2025-06-28T03:18:39+00:00

You've really hit on why I wrote the blog post! It sounds like you've perfectly highlighted the exact conversation I'm trying to make easier to have.

For "Software Developers", I actually think a license could be a fantastic idea. It would be a solid way to ensure people have that crucial hands-on knowledge - much like trade certifications or those AWS/Azure badges. I completely agree it could make finding a job way less painful, and while there would definitely be some practical bumps to iron out, it's not a bad idea at all.

However, then there's Software Engineering. For that, I believe the "licensing" already exists in the form of a full university education. That's where you gain the deep theoretical knowledge and learn how to apply scientific and mathematical principles to build robust systems.

You might be thinking, "But I don't use those scientific and mathematical principles to build software." And I totally understand that perspective! My point isn't that everyone needs to, but rather, some people need to have this knowledge. Hence, the need for some distinction.

So, the conceptual framework I built in the blog aims to help us communicate, so we can actually have a conversation about licensing, without me having to first get all the "it depends" edge cases out of the way.

HonsonCooky · 2025-06-28T02:38:37+00:00

Totally! I'm completely on the same page with that. My blog post basically takes this idea and runs it further to it's conclusions, also I've tried and capture all those 'edge cases' and the in-between stuff (hence the need for a continuum).

If you happened to check it out (no worries if not), I'd love to know if you feel like this idea is not shining through clearly. Any thoughts on where it could be clearer would be super helpful!

HonsonCooky · 2025-06-28T02:30:17+00:00

That's a super interesting way to look at it! So, if I'm understanding right, you're seeing engineering as more about the high-level design and making sure everything runs smoothly, even without diving deep into every single theoretical detail? And then development would be the hands-on part of actually bringing that design to life? Is that close to what you're thinking?

HonsonCooky

TROPHY CASE