A bit of a tangent, but boson vs. fermion is not a massless/massive split. There are massive bosons. Rather, it's a split on the qualities of the objects' spin, and thus whether they obey the Pauli exclusion principle.
A tool that will read your Java REST endpoints, and make TypeScript interfaces and invocation functions, so you can pretend your React front-end is using DCE again like it's 1999.
This reminds me of playing with openMosix and ClusterKnoppix back in the day. The kernel would take care of migrating the processes and balancing the load automagically...
Ah man. OpenMosix. What a great piece of software that was. Many people might not know but the developer beyond OpenMosix founded a company around it called Qlusters and then that was the predecessor to Xen/Xensource which he also founded and then he went on to found KVM/Qumranet. To say he left a mark is an understatement.
The term for JS enabled pages used to be DHTML back in the day. You'd be talking about a static-server DHTML site. Or something like that. https://en.m.wikipedia.org/wiki/Dynamic_HTML
I imagine the solution is going to be some sort of parallel to open source, that I can't quite visualize atm.
Maybe the next generation beyond 3D printing will be able to do multi-component assembly tasks, and you can get/print your own high quality components, and assemble your own high quality toaster... Maybe
The open source angle is an interesting concept. The raspberry pi seems to be doing quite alright, despite its design being completely open sourced. Can that model be tweaked a little to apply to all sorts of manufactured goods...? I’m mean, a brand name can have value.
The Raspberry Pi isn't a great example: You can't make a clone of it, because Broadcom will not sell you the SoC for it.
The parent mentioned 3D printing: I think that's the space were right now this plays out the most. Many designs are open or at least have open components, and people build and sell variations, but brands and brand loyalty are very much a thing.
> If swaps are the only thing you are counting, selection sort is O(n).
And if you ignore the bottom half of the centaur, it's just a dude playing a flute. :)
"In computer science, the time complexity is the computational complexity that describes the amount of time it takes to run an algorithm." [1] We shouldn't be confusing people that actually want to learn about this stuff.
> And if you ignore the bottom half of the centaur, it's just a dude playing a flute. :)
That is an excellent phrase.
> We shouldn't be confusing people that actually want to learn about this stuff.
I definitely agree that Selection sort should definitely not be described as O(n) to beginners. I was just pointing out a subtly. In the strange case where memory writes are much more expensive than reads or comparisons, it is correct to say the Selection sort takes O(n) time.
I'm not sure what conditions you have in mind, but in the selection sort, the comparisons are O(n^2), and the assignments are O(n).
If comparisons are a fixed, non-zero cost, and assignments are a fixed, non-zero cost, then the comparisons in your selection sort will always overwhelm the assignments, and I can tell you at exactly which input size.
The article describes these algorithms "efficient" on the basis of being linear, and they're not. Insertion and selection require O(n^2) moves or compares respectively (or, n log(n) with use of data structures). As it stands, the page is pretty as heck but teaching a misconception.
> The article describes these algorithms "efficient" on the basis of being linear, and they're not.
If memory writes are expensive (relative to reads and comparisons), selection sort is much better than insertion and bubble sort. Which is not something I had considered before trying to defend the post from the original comment.
> Insertion and selection require O(n^2) moves or compares respectively (or, n log(n) with use of data structures). As it stands, the page is pretty as heck but teaching a misconception.
I am definitely aware of the runtime of the sorting algorithms discussed. I have written about all of them [0]. Originally, I was going to agree and write about how it was a concerning misconception, but at least in the case of selection sort there is some (albeit small) merit to considering selection sort as O(n).
Though given that I cannot come up with a defense for insertion sort it is likely the author doesn't understand the time complexity of the sorting algorithms presented.
Yes. What sort of reasoning is that? I can present the result in a square picture, thus it's O(n)... The point is that creating each row of the picture does not take constant time; a longer row will take more time to create.
Both selection sort and insertion sort are O(n^2).
Sorting by pairwise comparison is O(n log n) at best.
For anybody that still uses Java. :D
https://github.com/BlueCircleSoftware/bluecircle-json-interf...