When would you ever want bubblesort?
51–60 of 70 posts
Re: When would you ever want bubblesort?
#52> On some very particular hardwares bubblesort stills ends up better, like in this NVIDIA study, but you probably don't have that hardware. The author might have misunderstood the hardware in question and the reasons why bubble sort works well here. You probably do have applicable hardware; it’s any GPU. The bubble sort wasn’t running on ray tracing hardware, it was just CUDA code. The reason bubble sort works well i…
Re: When would you ever want bubblesort?
#53Bubblesort is hard to beat if you're optimizing for object code size. I'm surprised that wasn't mentioned.
Unless you have a thousand of sorting routines it wouldn't matter much. And compilers generally produce a much larger code than actually possible, you can implement bubblesort in 16 bytes of x86-32 assembly [1] for example. [1] https://gist.github.com/jibsen/8afc36995aadb896b649
Re: When would you ever want bubblesort?
#54Earlier quoted context omitted.
Unless you have a thousand of sorting routines it wouldn't matter much. And compilers generally produce a much larger code than actually possible, you can implement bubblesort in 16 bytes of x86-32 assembly [1] for example. [1] https://gist.github.com/jibsen/8afc36995aadb896b649
It matters a great deal if you have 1KB of flash to fit the whole firmware in :)
Re: When would you ever want bubblesort?
#55When you read Knuth's The Art of Computer Programming he challenges you to come up with your own sorting algorithm. I feel really fortunate that I was able to do this without knowing any algorithms already. I came up with bubblesort. I think it was the intuition of thinking about it becoming "more sorted" on each pass that led me there.
Re: When would you ever want bubblesort?
#56Re: When would you ever want bubblesort?
#57Bubble sorts are useful in broad-phase collision detection. Each object has an axis-aligned bounding box, and you want to sort those by X, Y, and Z values, then check for overlap in all dimensions. Only if the bounding boxes overlap in all three dimensions do you have to check the object pair's detailed geometry. Most objects aren't moving that much. The lists are thus almost in order. So running a bubble sort on eac…
> Most objects aren't moving that much.
[citation needed]. Even just one object moving from one end of an axis to the other end would incur catastrophic slowdown, and depending on what you are simulating, this might occur regularly (for example, consider teleporters in a video game). When that happens, you incur the full O(n^2) iterations until the axis is sorted again, even though only one object is actually out of order.There are certainly simulations where this approach is fine (if you can be absolutely confident that no object ever "skips" around, like when you're running a simulation that is configured with an explicit upper bound on velocity), but I think that this still requires this warning label.
Re: When would you ever want bubblesort?
#58I've written a sort perhaps a handful of times in the last 40 years. Each of those was a bubble sort. I was nearly-always sorting These were rare cases where I didn't have a sort algorithm in a library -- perhaps because I needed to pass in a comparator that wasn't easily supported in the language. So I banged out whatever was easiest to get me moving on to the actual problem. If the sort became a noticeable part of…
> I was nearly-always sorting In my opinion, a bubble sort is a solid choice for that sort of use case.