Hacker Newsnew | past | comments | ask | show | jobs | submit | timv's commentslogin

You can use Quickselect (https://en.wikipedia.org/wiki/Quickselect) or Floyd-Rivest (https://en.wikipedia.org/wiki/Floyd%E2%80%93Rivest_algorithm)

Quickselect is fairly simple to understand if you already understand Quicksort. You use use a binary division but you avoid sorting sections where the order doesn't matter.

Let's start with a 7 element array

    [ 2, 4, 7, 5, 3, 6, 1 ]
We pivot on the mid-point (5) so that values less than end before it in the array and numbers larger end up after it

    [ 2, 4, 3, 1, 5, 7, 6 ]
Since 5 is now at an index greater than the midpoint, you know the median must be less than 5, so you don't care that 7 and 6 aren't sorted.

We pivot the first partition (first 4 elements) on 3 and get

   [ 2, 1, 3, 4, 5, 7, 6 ]
We don't care that 2 and 1 are unsorted, because we know that the median is > 3 (3 is at index #2 and we want index #3), so the median must be 4


And what of the likelihood that the original collection is modified when using the quickselect algorithm, thus introducing observable side effects in what could reasonably be considered a "read-only" computation?


And there lies the tradeoffs you need to consider as part of an interview question.

But if the best alternative is to sort the whole collection, then Quickselect doesn't introduce a new problem. You either accept that modifying the collection in place is an acceptable behaviour (and describe that in your API docs) or you make a copy of the collection and operate on that.

Given a choice between quickselect and quicksort, quickselect will get the answer with less overhead and no additional constraints (because it's essentially the same algorithm with unnecessary steps removed).

There are alternative approaches that don't require a full copy/sort, but they either require a partial copy + partial sort, or multiple passes through the collection.


> You mention early in the article that you intended to base this approach as a response to your own subpar user experience with support in other products.

This was the biggest (1) complaint for me - in light of what you discovered from your actual support experience, why was your expectation so off?

Was it that you expected support to be full of "how do I do this complicated thing?" questions that can be answered by an expert? That's an unrealistic expectation, but I guess now you know.

Or was it that you really thought that customers would be happy if you just took the time to explain your pricing model to them (also unrealistic).

It is kind of obvious from the types of emails you get, and the types of responses you give that it was not going to lead to strong customer relationships. If all you're doing is writing a 100 words to say "No, I'm not going to do what you want" that's not going to make things better.

(1) Actually 2nd biggest - the biggest was talking about "buying Castro" but having no explanation/links about who the author is, what Castro is, or how/when/why it was bought.


Pricing is a bad example I guess I should've minimized that part of the post.

I guess I didn't think about it enough, but if someone emailed in with a feature request, or with an opinion that this tab should behave differently or whatever, I thought giving explanation would be helpful. "I actually tried it that way, but it didn't work because X, and Y, and I didn't even think about Z which breaks the whole concept, etc etc." As a dev, these types of explanations would seem meaningful to me. But in reality, these conversations are mostly not helpful for either party. That was the point I was trying to make in the post.

Fair point on 2, I honestly didn't expect anyone to read this tonight and had another post planned I thought might get comments on HN, but I just put this up for now until I could finish that one. I will do better at giving context next time.


I wrote something like that about 15 years ago for a financial institution.

For what we needed, we intentionally wanted both people to be at the same terminal (it was going to be used to give shell access to a specific unix account that ran a critical system).

That mean that we could implement it as a setuid (root) binary that required both users to authenticate. It had a config file that worked like sudoers, and defined a list of commands that could be called, how many people were needed to authenticate, and which unix groups they had to belong to.


Imagine you were making purchasing decisions about which LLM-based coding tool to use.

If one of the possible vendors convinces you that that they have a next gen model that is so powerful it found 20+ year old bugs in a hardened operating system, that would undoubtedly have an influence on your decision even if you are only buying the current model.


The argument here is that they're confident that the bounds check isn't needed, and would prefer the compiler not insert one.

The choices therefore are:

1. No bound check

2. Bounds check inserted, but that branch isn't covered by tests

3. Bounds check inserted, and that branch is covered by tests

I'm skeptical of the claim that if (3) is infeasible then the next best option is (1)

Because if it is indeed an impossible scenario, then the lack of coverage shouldn't matter. If it's not an impossible scenario then you have an untested case with option (1) - you've overrun the bounds of an array, which may not be a branch in the code but is definitely a different behaviour than the one you tested.


> Because if it is indeed an impossible scenario, then the lack of coverage shouldn't matter.

At the point where a load-bearing piece of your quality assurance strategy is 100% branch coverage of the generated machine code, it very much does matter.

> I'm skeptical of the claim that if (3) is infeasible then the next best option is (1)

In the general case, obviously not. But, in the specific case we’re discussing, which is that (2) has the rider of “the development team will be forced to abandon a heretofore important facet of their testing strategy at the exact moment they are rewriting the entire codebase in a language they are guaranteed to have less expertise in,” I think (1) seems pretty defensible.


I think you’re misreading their statement. They aren’t saying they don’t want the compiler to insert the additional code. They’re saying they want to test all code the compiler generates.


> This is also an unconventional drinking fountain.

Why do you say that?

At least in Australia, drinking fountains ("bubblers"!) are fairly non standardised. I don't recall seeing many with that rubber top, but the rotating release mechanism is pretty common. I'd say press buttons are more common but both are typical.


In Australia the entry level "Dolphin essential" is A$30k which is between US$18.5k and US$21k, depending on the (fairly volatile) exchange rates.

Still not US$14k, but not quite the $25k it is in other markets.


He probably meant Seagull, which is also sold as Dolphin Mini in some countries.


"The Seagull went on sale in Mexico as the Dolphin Mini in March 2024. It is available in two variants, dubbed the Dolphin Mini and Dolphin Mini Plus, which are equipped with a 30.88 kWh and 38.88 kWh battery respectively."

https://en.wikipedia.org/wiki/BYD_Seagull

https://mexico.as.com/motor/byd-dolphin-mini-que-tiene-de-es...


Phones have a lot of that market covered, and the Switch Lite gets close enough for a lot of people who want something other than a phone.

I guess Nintendo don't see enough left over space to bother trying.


Even Linux users in 1999 (when you had to be pretty well informed to know that Linux even existed) were truly that uninformed.

http://www.slackware.com/faq/do_faq.php?faq=general#0


The market penetration of the switch makes it harder for Sony to expand into the family/casual gaming space. That forces Sony to stick to the AAA lane (which is where their focus is) limiting their growth opportunities.

If the switch had been a failure, then a lot of households that currently have a switch (only) would have bought a different console and that would likely have been a PS5 (even if they held on to their previous generation console, and waited a couple of years until the PS5 price dropped below $500)

I have a PS4 and a Switch at home. The kids play the switch and occasionally play on the PS4. I can't justify buying a PS5 because there's only so much gaming time available, and family gaming is covered by the switch and my personal gaming is good enough on my PC. Take the switch out of the equation and that changes.

PS5 is winning the AAA console lane, no doubt. But Sony could have been making more money if they could also own a significant portion of the family console lane.


I don't know that the Playstation 5 really plays in that market when the cheapest version is $450, so nearly $200 more expensive than the switch. Keeping the price down is part of how Nintendo owns that market, on top of their first party game lineup and the like.


Interesting. Yea if the switch didn't exist I could see a re-attempt at the PSP (or the Vita? whatever that thing was).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: