| 10:02 | <annevk> | Hmm, I guess we can do as Hixie suggests |
| 12:09 | <Ms2ger> | MikeSmith, http://www.w3.org/TR/xml-stylesheet/ :) |
| 12:09 | <MikeSmith> | ah yeah |
| 12:09 | <MikeSmith> | thanks |
| 12:13 | <Ms2ger> | As always, happy to complain |
| 12:17 | <karlcow> | http://manu.sporny.org/2011/uber-comparison-rdfa-md-uf/ |
| 12:24 | <hsivonen> | karlcow: If having a feature is generally green even for misfeatures like Compact URIs, why isn’t more New Attributes greener? |
| 12:24 | <karlcow> | no idea |
| 12:27 | <karlcow> | http://www.w3.org/2001/sw/interest/ED-ldh-20110626/ |
| 16:11 | <annevk> | I am not liking what bz says on public-webapps |
| 16:11 | <annevk> | Maybe it comes down to: redirects suck |
| 16:21 | <karlcow> | at least for performance |
| 16:21 | <karlcow> | :) |
| 19:29 | <Hixie> | the internets are failing me |
| 19:29 | <boogyman> | don't you mean interwebs |
| 19:29 | <Hixie> | does anyone know if there's a more efficient way to take an unsorted array and create a second sorted array from it that is quicker than just copying the first array to the second array and then doing an in-place sort of the second array? |
| 19:30 | <Hixie> | (i need both arrays at the end -- the first array is actually just sorted in a different order that i still need) |
| 19:31 | <Hixie> | it seems that being willing to pay for O(n) more memory should have some sort of benefit but all the algorithms wikipedia talks about are in-place and don't take advantage of having lots of scratch space. |
| 19:33 | <Philip`> | Merge sort needs O(n) extra space |
| 19:35 | <Hixie> | merge sort could work i guess |
| 19:35 | <Philip`> | (and it's stable (unlike heap sort) and worst case O(n log n) (unlike quicksort)) |
| 19:36 | <Hixie> | stable isn't an issue here, my keys are unique |
| 19:36 | <Hixie> | my N is also very small, less than 32 in the worst case, likely 2-4 in the common case |
| 19:37 | <Dashiva> | Well, you'd only have "extra" space in the first iteration of the algorithm |
| 19:37 | <Philip`> | In that case, why do you care at all about efficiency? |
| 19:37 | <Hixie> | Philip`: principle, mostly |
| 19:37 | <Dashiva> | Do you need a comparison sort at all? |
| 19:38 | <Hixie> | Philip`: but also because it's interesting :-) |
| 19:38 | <Philip`> | Sorting isn't interesting, Knuth solved it decades ago so that you can just call .sort() and not have to worry about it any more :-p |
| 19:38 | <Hixie> | simplest solution seems to just be to walk the first array looking for the lowest value, then the next lowest value, etc, but that's pretty pathetic performance-wise |
| 19:38 | <Hixie> | Philip`: :-P |
| 19:39 | <Dashiva> | Hixie: The extra space is just an illusion unless you're using a n-writes-only algorithm |
| 19:39 | <gsnedders> | Philip`: But Knuth also said you should know *how* to sort, even if you should normally just use the stdlib of whatever you're using. :P |
| 19:40 | <gsnedders> | Hixie: i.e., a selection sort |
| 19:41 | <Hixie> | Dashiva: well if the key space was better defined (e.g. 1..32, rather than arbitrary short strings as in this case) i could do a pigeon-hole sort, which would be way faster than a comparison sort |
| 19:41 | <Hixie> | gsnedders: yeah |
| 19:41 | <Hixie> | gsnedders: more or less |