Cheatsheet: Difference between revisions

← Older edit

Cheatsheet (view source)

Revision as of 22:34, 31 August 2022

123 bytes removed , 1 year ago

→‎Redirect Stderr

Amanjosan2008

Bureaucrats, Administrators

4,400

edits

Revision as of 14:14, 1 July 2022 (view source) Amanjosan2008 (talk \| contribs) (→‎SMTP) ← Older edit		Latest revision as of 22:34, 31 August 2022 (view source) Amanjosan2008 (talk \| contribs) (→‎Redirect Stderr)
(One intermediate revision by the same user not shown)
Line 949: ls > file.log 2>&1 OR ls &> file.log ls > file.log 2> /dev/null === System Calls === {{UC}} = Sorting Algorithms = ~~'''~~* Quicksort~~''' is a good default choice.~~ It is a good default choice. ~~It tends to be fast in practice~~ It tends to be fast in practice with some small tweaks its dreaded O(n2)O(n^2)O(n2) worst-case time complexity becomes very unlikely. A tried and true favorite. ~~'''Heapsort''' is a good choice if you can't tolerate a worst-case time complexity of O(n2)O(n^2)O(n2) or need low space costs.~~ * Heapsort The Linux kernel uses heapsort instead of quicksort for both of those reasons.▼ ~~'''Merge sort'''~~It is a good choice if you ~~want~~can't tolerate a ~~stable~~worst-case ~~sorting~~time ~~algorithm~~complexity of O(n2)O(n^2)O(n2) or need low space costs. ▲ The Linux kernel uses heapsort instead of quicksort for both of those reasons. ~~can easily be extended to handle data sets that can't fit in RAM~~ where the bottleneck cost is reading and writing the input on disk, not comparing and swapping individual items.▼ * Merge sort '''Radix sort''' looks fast, with its O(n)O(n)O(n) worst-case time complexity. ▼ It is a good choice if you want a stable sorting algorithm. if you're using it to sort binary numbers, then there's a hidden constant factor that's usually 32 or 64 (depending on how many bits your numbers are).▼ ▲ It can easily be extended to handle data sets that can't fit in RAM where the bottleneck cost is reading and writing the input on disk, not comparing and swapping individual items. That's often way bigger than O(lg⁡(n))O(\lg(n))O(lg(n)), meaning radix sort tends to be slow in practice.▼ '''Counting sort''' is a good choice in scenarios where there are small number of distinct values to be sorted. ▼ * Radix sort This is pretty rare in practice, and counting sort doesn't get much use.▼ ▲ ~~'''Radix sort'''~~It looks fast, with its O(n)O(n)O(n) worst-case time complexity. ▲ if If you're using it to sort binary numbers, then there's a hidden constant factor that's usually 32 or 64 (depending on how many bits your numbers are). ▲ That's often way bigger than O(lg⁡(n))O(\lg(n))O(lg(n)), meaning radix sort tends to be slow in practice. * Counting sort ▲ ~~'''Counting sort'''~~It is a good choice in scenarios where there are small number of distinct values to be sorted. ▲ This is pretty rare in practice, and counting sort doesn't get much use. * Which sorting algorithm has best asymptotic run time complexity?