4 ms·

This wall of text is very bizarre. First, I don't know where you got "gleason bound" from, but if you search for it on google, your comment in this thread is th

This wall of text is very bizarre. First, I don't know where you got "gleason bound" from, but if you search for it on google, your comment in this thread is the only thing that comes up. Second, your "alternative speed" measures are a hallucination. Sooo, broadly that's two quite different ways to look at how to write fast code. No there isn't. The one that takes 1/10th the time of the other one is faster. You going off on tangents and making up terms to try to say that a heap sort is the fastest sort (of all the strange things to argue) is nonsense.

graycat 3y ago
> First, I don't know where you got "gleason bound" from, For the answer and posted in this thread, I wrote: The Gleason bound? That's in one of the D. Knuth volumes The Art of Computer Programming. > Second, your "alternative speed" measures are a hallucination. No. Instead, I wrote in this thread: A short answer is, if win in the big-O comparison, then, no matter how sloppy the coding, for all sufficiently large n, still will win no matter how measure speed. In short, that's the reason people took big-O very seriously. If you want to argue against heap sort, then you need to argue that in counting comparisons the big-O expression for heap sort is wrong and loses out to some other sorting algorithm. The Gleason bound assumes that each comparison costs the same. So you may want to argue that for n keys, as n grows the issues of caches, locality of reference, parallel processors, etc. mean that the cost of each comparison grows so that in the big-O competition heap sort can be beat. I'll let someone else calculate the big-O expressions again considering locality of reference, etc.
- CyberDildonics 3y ago
  The Gleason bound? Instead of repeating yourself, can you link to some actual information? still will win no matter how measure speed Speed is measured with time. You can keep saying algorithmic complexity is speed, but that will never make it reality. If you want to argue against heap sort, then you need to argue That's not how it works. Other sorts take a fraction of the time. I showed you this already. I'll let someone else calculate the big-O expressions again considering locality of reference, etc. This was never about algorithmic complexity, that's something that you hallucinated. Not only that, but you do realize that other sorts have the same complexity as heap sort right? There a lot of ways to sort with n log n. You are trying to argue something that isn't real to make a point that no one cares about and has nothing to do with this thread.
  - graycat 3y ago
    > You are trying to argue something that isn't real to make a point that no one cares about and has nothing to do with this thread. In a word, you are wrong. I've been very, very, very clear again, over again, once again, yet again, and you just fail to get it, a simple lesson often just in the first week of an easy, first college course in computer science. > Other sorts take a fraction of the time. I showed you this already. Nope. You showed no such thing. Your evidence is meaningless. Heck, even bubble sort could beat heap sort or quick sort under some circumstances. So, again, sit down, pay attention, listen up: What matters for any measurement of performance in comparing code is the big-O expression. Read this again, again, again, write it on the blackboard 1000 times after school, repeat it to yourself before each meal, going to sleep, waking up. You just pass this off as computational complexity irrelevant to execution time. Here you are just wrong, totally, badly wrong. You seem not to understand this. For any measurement, time, Watts, Joules, comparisons, cycles, any measurement, in the reasonable context, what matters is the big-O expression. > There a lot of ways to sort with n log n. Well, merge sort can. Maybe some versions of quick sort can. Okay, there are some ties. I never said there are no ties. But, in the context, can't beat O( n log(n) ) -- the Gleason bound shows this. I've said this over and over and over and over. So, in the context, can't beat heap sort. What you saw in some two pieces of code on 1000 keys is just irrelevant to a meaningful comparison of performance. > The Gleason bound? > Instead of repeating yourself, can you link to some actual information? I gave the information: First in the context heap sort, merge sort, maybe quick sort run in O( n log(n) ) in comparisons and also, in this context, inescapably, in time, cycles, Watts, Joules, whatever. The "faster" is not for n = 1000 but for all sufficiently large n. For n = 1000, anything can happen. Second the Gleason bound says that, in the context, can't sort faster than this. So that's why it's call a "bound", a lower bound on how fast can sort. Third, I gave the reference, D. Knuth's famous book. The Gleason bound is one of the nicer, most powerful, most useful, most important pieces of work in all of computer science, computer programming, sorting, and computing for any and all purposes, in particular for practical performance, and you just fail to get it. You have some problems, some blocks in understanding. You just do not want to learn something new to you. You deeply resent this. Your problem is not about computers or applied math but emotional. For your emotional problems, nothing in computing, computer science, or my writing can help you.

graycat 3y ago

> First, I don't know where you got "gleason bound" from, For the answer and posted in this thread, I wrote: The Gleason bound? That's in one of the D. Knuth volumes The Art of Computer Programming. > Second, your "alternative speed" measures are a hallucination. No. Instead, I wrote in this thread: A short answer is, if win in the big-O comparison, then, no matter how sloppy the coding, for all sufficiently large n, still will win no matter how measure speed. In short, that's the reason people took big-O very seriously. If you want to argue against heap sort, then you need to argue that in counting comparisons the big-O expression for heap sort is wrong and loses out to some other sorting algorithm. The Gleason bound assumes that each comparison costs the same. So you may want to argue that for n keys, as n grows the issues of caches, locality of reference, parallel processors, etc. mean that the cost of each comparison grows so that in the big-O competition heap sort can be beat. I'll let someone else calculate the big-O expressions again considering locality of reference, etc.

CyberDildonics 3y ago
The Gleason bound? Instead of repeating yourself, can you link to some actual information? still will win no matter how measure speed Speed is measured with time. You can keep saying algorithmic complexity is speed, but that will never make it reality. If you want to argue against heap sort, then you need to argue That's not how it works. Other sorts take a fraction of the time. I showed you this already. I'll let someone else calculate the big-O expressions again considering locality of reference, etc. This was never about algorithmic complexity, that's something that you hallucinated. Not only that, but you do realize that other sorts have the same complexity as heap sort right? There a lot of ways to sort with n log n. You are trying to argue something that isn't real to make a point that no one cares about and has nothing to do with this thread.
- graycat 3y ago
  > You are trying to argue something that isn't real to make a point that no one cares about and has nothing to do with this thread. In a word, you are wrong. I've been very, very, very clear again, over again, once again, yet again, and you just fail to get it, a simple lesson often just in the first week of an easy, first college course in computer science. > Other sorts take a fraction of the time. I showed you this already. Nope. You showed no such thing. Your evidence is meaningless. Heck, even bubble sort could beat heap sort or quick sort under some circumstances. So, again, sit down, pay attention, listen up: What matters for any measurement of performance in comparing code is the big-O expression. Read this again, again, again, write it on the blackboard 1000 times after school, repeat it to yourself before each meal, going to sleep, waking up. You just pass this off as computational complexity irrelevant to execution time. Here you are just wrong, totally, badly wrong. You seem not to understand this. For any measurement, time, Watts, Joules, comparisons, cycles, any measurement, in the reasonable context, what matters is the big-O expression. > There a lot of ways to sort with n log n. Well, merge sort can. Maybe some versions of quick sort can. Okay, there are some ties. I never said there are no ties. But, in the context, can't beat O( n log(n) ) -- the Gleason bound shows this. I've said this over and over and over and over. So, in the context, can't beat heap sort. What you saw in some two pieces of code on 1000 keys is just irrelevant to a meaningful comparison of performance. > The Gleason bound? > Instead of repeating yourself, can you link to some actual information? I gave the information: First in the context heap sort, merge sort, maybe quick sort run in O( n log(n) ) in comparisons and also, in this context, inescapably, in time, cycles, Watts, Joules, whatever. The "faster" is not for n = 1000 but for all sufficiently large n. For n = 1000, anything can happen. Second the Gleason bound says that, in the context, can't sort faster than this. So that's why it's call a "bound", a lower bound on how fast can sort. Third, I gave the reference, D. Knuth's famous book. The Gleason bound is one of the nicer, most powerful, most useful, most important pieces of work in all of computer science, computer programming, sorting, and computing for any and all purposes, in particular for practical performance, and you just fail to get it. You have some problems, some blocks in understanding. You just do not want to learn something new to you. You deeply resent this. Your problem is not about computers or applied math but emotional. For your emotional problems, nothing in computing, computer science, or my writing can help you.