min-heap | Min Heap is a data structure | Learning library

.text is a directive that tells the assembler to start a program code section (the “text” section of the program, a read-only executable section containing mostly instructions to be executed). It is here because GCC without optimization always puts a .text at the top of the file, even if it's about to switch to another section (like .bss in this case) and then back to .text when it's ready to emit some bytes into that section (in your case, a definition for main). GCC does still parse the whole compilation unit before emitting any asm, though; it's not just compiling one global variable / function at a time as it goes along.

.globl a is a directive that tells the assembler that a is a “global” symbol, so its definition should be listed as an external symbol for the linker to link with.

.bss is a directive that tells the assembler to start the “block starting symbol” section (which will contain data that is initialized to zero or, on some systems, mostly older, is not initialized).

.type a @object and .size a, 1 are directives that describe the type and size of an object named a. The assembler adds this information to the symbol table or other information in the object file it outputs. It is useful for debuggers to know about the types of objects.

a: is label. It acts to define the symbol. As the assembler reads assembly, it counts bytes in the section it is current generated. Each data declaration or instruction takes up some bytes, and the assembler counts those. When it sees a label, it associates the label with the current count. (This is commonly called the program counter even when it is counting data bytes.) When the assembler writes information about a to the symbol table, it will include the number of bytes it is from the beginning of the section. When the program is loaded into memory, this offset is used to calculate the address where the object a will be in memory.

So the question is why a: is at the bottom

a: must be after .bss because a will be put into the section the assembler is currently working on, so that needs to be set to the desired section before declaring the label. The location of a relative to the other directives might be flexible, so that reordering them would have no consequence.

so I like to know is code 1 and code 2 same?

No, a: must appear after .bss so that it is put into the correct section.

.zero 1 says to emit 1 zero byte in the current section. Like (almost?) all directives GCC uses, it's well documented in the GNU assembler manual: https://sourceware.org/binutils/docs/as/Zero.html

so again have my gcc place main in .zero

No, .text starts (or switches back to) the code section, so main will be in the code section.

is .LFB0: a some section of program that my x86-64 processor can run

Anything ending with a colon is a label. .LFB0 is a local label the compiler is using in case it needs it as a jump or branch target.

so I like to know if I am coding in assembly can I ignore .cfi_startproc line.

When writing assembly for simple functions without exception handling and related features, you can ignore .cfi_startproc and other call-frame information directives that generate metadata that goes in the .eh_frame section. (Which is not executed, it's just there as data in the file for exception handlers and debuggers to read.)

… if not needed then I can assume my program will become…

If you are omitting some of the .cfi… directives, I would omit all of them, unless you look into what they do and determine which ones can be omitted selectively.

I believe I have to save it with .s or .S extension which one s small or large S?

With GCC and Clang, assembly files ending in .S are processed by the “preprocessor” before assembly, and assembly files ending in .s are not. This is the preprocessor familiar from C, with #define, #if, and other directives. Other tools may not do this. If you are not using preprocessor features, it generally does not matter whether you use .s or .S.

heap is a data structure which is actually a complete binary tree with some extra properties. There are 2 types of Heaps:

1. MIN Heap
2. MAX Heap

in min heap the root has the lowest value in the tree and when you pop out the root the next lowest element comes on the top. To convert a tree into heap we use heapify algorithm. It is also know as priority queue in c++. and usually as a competitive programmer we use STL function for heap so that we dont have to get into the hustle of creating a heap from scratch. Max heap is just the opposite with largest at the root. Usually heap is used because it has a O(logN) time complexity for removing and inserting elements and hence can even work with tight constraints like 10^6.

Now i can understand you confusion between heap in memory and heap data structure but they are completely different things. Heap in data structure is just a way to store the data.

There is nothing wrong with the complexity of your algorithm (note the appoximate factor of 10 of increased time when operating on 1e6 instead of 1e5 values). The standard library functions are just faster by a constant factor. That is probably because they are optimized and maybe even written in a compiled language, that can run much faster.

For each query, there is an (inclusive) interval of acceptable cut points, so the task is to find the minimum number of cut points that intersect all intervals.

The usual algorithm for this problem, which you can see here, is an optimized implementation of this simple procedure:

1. Select the smallest interval end as a cut point
2. Remove all the intervals that it intersects
3. Repeat until there are no more intervals.

It's easy to prove that that it's always optimal to select the smallest interval end:

• The smallest cut point must be <= the smallest interval end, because otherwise that interval won't get cut.
• If an interval intersects any point <= the smallest interval end, then it must also intersect the smallest interval end.
• The smallest interval end is therefore an optimal choice for the smallest cut point.

It takes a little more work, but you can prove that your algorithm is also an implementation of this procedure.

First, we can show that the smallest interval end is always the first one popped off the heap, because nothing is popped until we find a starting point greater than a known endpoint.

Then we can show that the endpoints removed from the heap correspond to exactly the intervals that are cut by that first endpoint. All of their start points must be <= that first endpoint, because otherwise we would have removed them earlier. Note that you didn't adjust your queries into inclusive intervals, so your test says peek() <= start. If they were adjusted to be inclusive, it would say peek() < start.

Finally, we can trivially show that there are always unpopped intervals left on the heap, so you need that +1 at the end.

So your algorithm makes the same optimal selection of cut points. It's more complicated than the other one, though, and harder to verify, so I wouldn't use it.

However, let say if I want to build a "max heap", but the constructor does not let me pass in a collection and comparator together. In this case, is the only to build max heap is via creating a wrapper class that implements comparable?

Yes. This class does not provide a constructor that can pass in a collection and a comparator at the same time. It will use the compareTo method of the collection element, so as you did, you need a Wrapper(But this may seem a little unnecessary?).

repeatedly call add.

You can use PriorityQueue#addAll().

Pushing items to the heap and popping from it are both logarithmic operations. Removing an element from the heap is logarithmic because the heap needs to adjust its elements to guarantee the heap invariant. So, you would do 2 * n * log n, and while this is still linearithmic in Big O terms like merge sort, it is probably slower. Or let's say at least that you can do better by using a linearithmic sorting algorithm, instead of using a heap for sorting.

What you could do, and I didn't see you mentioning it, is to add all the elements in the linked list to the heap's data store in O(n) time and then heapify it, which runs also in O(n) if implemented correctly. Then you would have 2n + n * log n which reduces to O(n * log n) with better constants.

The additional space used by the heap isn't O(n log n). It is linear and while this depends on the heap implementation, let's say that many standard heap implementations provide that.

When merging k sorted linked lists with a heap you are benefiting from the fact that k is much smaller than the length of the lists themselves. This leads to a O((n1 + n2 +...) * log k) algorithm where n1, n2,... are the lengths of the involved lists. If you didn't use a heap, that algorithm would have run in O((n1 + n2 +...) * k) time.

At the end of the day, if a heap is correctly implemented and used, you will have linearithmic time complexity and linear space complexity for sorting the linked list. But whatever you do, all other variables equal, a standard sorting algorithm has better constants than a heap when it comes to sorting, unless there are some special requirements and constraints. Let me reiterate, both methods are linearithmic in terms of Big O, but sorting algorithms can have better constants for this specific purpose which can mean a lot in real world applications. The reason is that a heap needs to guarantee access in O(1) time to the smallest/largest element at any time. This puts constraints on its behavior and you wouldn't be able to optimize it as much as a standard sorting algorithm when it comes to sorting.

First the structure of the file is as follows:

Any ideas or what am I doing wrong? :(

257

getc() returns 257 different values in the unsigned char range and EOF. Saving in a char loses information and can cause a valid input byte to be misinterpreted as an EOF signal (when char is signed) or byteFromFile == EOF never to be true (when char is unsigned).

Build: Use median-of-medians to find the initial median in O(n), use it to partition the values in half. The half with the smaller values goes into a max-heap, the half with the larger values goes into a min-heap, build each in time O(n). We'll keep the two heaps equally large or differing by at most one element.

Median: The root of the bigger heap, or the mean of the two roots if the heaps have equal size.

Insert: Insert into the bigger heap, then pop its root and insert it into the smaller heap.