Search All of the Math Forum:
Views expressed in these public forums are not endorsed by
NCTM or The Math Forum.
|
|
Math Forum
»
Discussions
»
sci.math.*
»
sci.math
Notice: We are no longer accepting new posts, but the forums will continue to be readable.
Topic:
Just finished the fastest ever, general purpose sorting algorithm.
Replies:
29
Last Post:
Jan 8, 2013 10:21 PM
|
 |
|
|
Re: Just finished the fastest ever, general purpose sorting algorithm.
Posted:
Jan 5, 2013 10:08 PM
|
|
On Saturday, January 5, 2013 6:29:36 PM UTC-8, JT wrote: > Numb and mindless, no it does not compare the numbers have weight and > are placed in the binary tree depending on weight, i do not compare it > with other values in tree. Can you understand or do you need a > translator into stupidness?
So, how do you place them in a binary tree depending upon weight without comparison? Do you not understand the binary insertion sort?
I don't feel like reading your java. I don't know why you consider only numbers between 0 and 255. Do you think all items to be sorted fall into this category? Then you just use the number to be sorted and increment it. I don't speak java. Can't you do countval[dval[i]]++ in java?
We used to use hashing algorithms to access bank accounts. Speed was important. We create a hash from the account number and read that secotor of disk and verified the account number. If two numbers hashed to the same sector and linked list was made into the overflow sectors. Once we got too many hits we just changed the hash. Sure there was lots of empty space and this was expensive but then so was time. Machines weren't as fast as they are now and we couldn't afford core memory. The trade off was more disk memory and unused sectors. Now we use binary indicies compressed on disk. Even though disk is very cheap the speed to uncompress in memory is less than reading extra secotors of disk.
|
|
|
|