doc: https://epubs.siam.org/doi/pdf/10.1137/1.9781611973068.53
=> lazy manner deleted, it just marks the element as deleted and on the next extract_min While we are getting an element with the deleted tag, we extract again until get a not tagged deleted element
=> Reald delete means that the element is deleted for real in the heap and the value in the list doesn't exists anymore
You can mix both of these fonction => if you fakeDelete, then you can even realDelete Moreover, you can precise in realDelete if you want to delete an element tagged deleted or not.
force_delete = true => delete even deleted tagged element
force_delete = false => delete only untagged deleted element
can cause invalid read of size if you don't allocate your memory
don't forget to extend the stack when using valgrind => --main-stacksize=number
The error rate of the algo is also displayed while testing because it's not fair for std::sort if we compare only the time.
As you'll be able to see, epsilon affect on the number of element you can put without getting any error of sort. Then if you know the number of elements to sort and that the %error that you can incur (if you accept any error rate), then this algo is yours. Otherwise, you can go away.
Just store the last element of the list then we wont need to browse all list to concatenate element.