ID:2527462   Dec 5 2019, 10:42 am Simply the most optimal version of merge sort I could produce in testing. To sort different object types, you would need to overload `operator<`. It produces a new list that is a stable sorted copy of the original list, leaving the original unmodified. I learned, in testing, that `Cut` was the largest detriment to speed complexity. Anyone know of a faster or more optimal sort proc? ```proc/Sort(list/L) // requires operator<, stable if (L.len <= 1) return L.Copy() if (L.len == 2) var/list/result = L.Copy() if (L[2] < L[1]) result.Swap(1, 2) return result var/pivot = 1 + round(L.len / 2) var/list/L1 = .(L.Copy(1, pivot)) var/list/L2 = .(L.Copy(pivot, L.len + 1)) // merge var/list/result = new var/i1 = 1 var/i2 = 1 while (i1 <= L1.len && i2 <= L2.len) if (L2[i2] < L1[i1]) result += L2[i2++] else result += L1[i1++] if (i1 <= L1.len) result += L1.Copy(i1) else if (i2 <= L2.len) result += L2.Copy(i2) return result ``` Edit: Would need modification to handle associative lists.
 Dec 5 2019, 11:55 am Update: The way I was testing was flawed. Here is my most optimized version, now. (It now modifies the original list.) ```proc/Sort(list/L) // requires operator<, stable . = L if (L.len <= 1) return if (L.len == 2) if (L[2] < L[1]) L.Swap(1, 2) return var/pivot = 1 + round(L.len / 2) var/list/L1 = .(L.Copy(1, pivot)) var/list/L2 = .(L.Copy(pivot, L.len + 1)) // merge L.Cut() while (L1.len && L2.len) if (L2[1] < L1[1]) L += L2[1] L2.Cut(1, 2) else L += L1[1] L1.Cut(1, 2) L += L1 L += L2 ```
 Dec 5 2019, 4:29 pm Here's a version that gains a slight optimization (small, but noticeable) by sorting lists or sublists of very small length (i.e., length 5 or less) using bubble sort. Even more optimized! ```proc/Sort(list/L) // requires operator<, stable . = L if (L.len <= 1) return if (L.len <= 5) // bubble sort for small lists var/swaps = 1 while (swaps) swaps = 0 for (var/i = 1, i < L.len, ++i) if (L[i + 1] < L[i]) L.Swap(i, i + 1) ++swaps return // merge sort for large lists var/pivot = 1 + round(L.len / 2) var/list/L1 = .(L.Copy(1, pivot)) var/list/L2 = .(L.Copy(pivot, L.len + 1)) L.Cut() while (L1.len && L2.len) if (L2[1] < L1[1]) L += L2[1] L2.Cut(1, 2) else L += L1[1] L1.Cut(1, 2) L += L1 L += L2 ```
 Dec 19 2019, 8:59 pm (Edited on Dec 19 2019, 9:07 pm) ```var/pivot = 1 + round(L.len / 2) ``` to ```. = 1 + round(L.len * 0.5) ``` ```var/list/L1 = .(L.Copy(1, .))var/list/L2 = .(L.Copy(., L.len + 1)) ``` also defining var/i outside of the while() would help for speedz, could even use . lol
 Dec 19 2019, 9:58 pm In response to Kozuma3 He should also shave his legs so when he goes for a jog he's more aerodynamic.
 Dec 20 2019, 2:29 am In response to Popisfizzy Popisfizzy wrote: He should also shave his legs so when he goes for a jog he's more aerodynamic. He asked for optimizations in his code. I don't know what your personal interest in jogging has to do with anything.
 Dec 20 2019, 3:10 am I was just giving some suggestions on other things which can help in a technical sense, but in practice are so dominated by other factors that it's all but impossible to actually detect their benefit.
 Dec 20 2019, 3:19 am In response to Popisfizzy Popisfizzy wrote: but in practice are so dominated by other factors that it's all but impossible to actually detect their benefit. With practice you'll notice them.
 Dec 20 2019, 4:51 am In response to Kozuma3 Kozuma3 wrote: With practice you'll notice them. SortUnmodified is the base version from here. SortModification1 and SortModification2 are versions which implement your suggested changes. ``` Profile results (total time)Proc Name Self CPU Total CPU Real Time Overtime Calls----------------------- --------- --------- --------- --------- ---------/proc/SortModification1 4.469 24.938 24.946 4.451 65535/proc/SortModification2 4.160 21.597 21.576 4.157 65535/proc/SortUnmodified 4.133 21.526 21.538 4.104 65535/mob/verb/SortTest2 0.001 4.470 4.471 0.001 1/mob/verb/SortTest3 0.002 4.162 4.162 0.001 1/mob/verb/SortTest1 0.002 4.135 4.135 0.001 1 ``` Look at which of those three is coming in first :^) The code is as follows. I use my MersenneTwister library to generate 100,000 floats. I do this because, unlike BYOND's built in RNG, my library will consistently generate the same sequence of floats across computers given the same seed. This keeps the test data consistent. ```proc/SortUnmodified(list/L) // requires operator<, stable . = L if (L.len <= 1) return if (L.len <= 5) // bubble sort for small lists var/swaps = 1 while (swaps) swaps = 0 for (var/i = 1, i < L.len, ++i) if (L[i + 1] < L[i]) L.Swap(i, i + 1) ++swaps return // merge sort for large lists var/pivot = 1 + round(L.len / 2) var/list/L1 = .(L.Copy(1, pivot)) var/list/L2 = .(L.Copy(pivot, L.len + 1)) L.Cut() while (L1.len && L2.len) if (L2[1] < L1[1]) L += L2[1] L2.Cut(1, 2) else L += L1[1] L1.Cut(1, 2) L += L1 L += L2proc/SortModification1(list/L) // requires operator<, stable if (L.len <= 1) return L if (L.len <= 5) // bubble sort for small lists var/swaps = 1 while (swaps) swaps = 0 for (var/i = 1, i < L.len, ++i) if (L[i + 1] < L[i]) L.Swap(i, i + 1) ++swaps return L // merge sort for large lists . = 1 + round(L.len * 0.5) var/list/L1 = .(L.Copy(1, .)) var/list/L2 = .(L.Copy(., L.len + 1)) L.Cut() while (L1.len && L2.len) if (L2[1] < L1[1]) L += L2[1] L2.Cut(1, 2) else L += L1[1] L1.Cut(1, 2) L += L1 L += L2 return Lproc/SortModification2(list/L) // requires operator<, stable . = L if (L.len <= 1) return if (L.len <= 5) // bubble sort for small lists var/swaps = 1 var/i while (swaps) swaps = 0 for (i = 1, i < L.len, ++i) if (L[i + 1] < L[i]) L.Swap(i, i + 1) ++swaps return // merge sort for large lists var/pivot = 1 + round(L.len / 2) var/list/L1 = .(L.Copy(1, pivot)) var/list/L2 = .(L.Copy(pivot, L.len + 1)) L.Cut() while (L1.len && L2.len) if (L2[1] < L1[1]) L += L2[1] L2.Cut(1, 2) else L += L1[1] L1.Cut(1, 2) L += L1 L += L2 var/list/Data = newmob Login() ..() world << "Beginning test data generation..." sleep(7) var const SEED = 27 SIZE = 150000 pif_Random/Mersenne32/rng = new(SEED) for(var/i = 1 to SIZE) if((i % 5000) == 0) world << "[round((i / SIZE) * 100)]% complete" sleep(1) Data += rng.GetFloat() rng.Step() sleep world << "Test data generated." verb SortTest1() world << "Sorting..." SortUnmodified(Data.Copy()) world << "Sorting test 1 (unmodified algorithm) complete" SortTest2() world << "Sorting..." SortModification1(Data.Copy()) world << "Sorting test 2 (algorithm, modification 1) complete" SortTest3() world << "Sorting..." SortModification2(Data.Copy()) world << "Sorting test 2 (algorithm, modification 2) complete" ```
 Dec 20 2019, 6:15 am You had to of did something incorrect, logically it's faster. It doesn't need explained as you'll miss the point but, it's faster if done correctly.
 Dec 20 2019, 6:30 am Ah yeah, the nebulous ~something~ even though the code is literally right there. Nothing up my sleeve, mate. Maybe next time suggest an optimization that is substantial instead of silly and the results will speak for themselves.
 Dec 20 2019, 6:34 am In response to Popisfizzy Popisfizzy wrote: Ah yeah, the nebulous ~something~ even though the code is literally right there. Nothing up my sleeve, mate. Maybe next time suggest an optimization that is substantial instead of silly and the results will speak for themselves. You missed out on all my optimization advice to test a single optimization that SHOULD of improved it, but again you'll need to remove your code that's clearly causing runtimes to get a valid read.
 Dec 20 2019, 7:12 am What conspiratorial bullshit are you even on about? There are no runtime errors (where precisely would they be, anyways?). What's going on is that your suggested optimizations are so utterly minute and irrelevant that they're drowned out by the random noise that naturally appears in a typical working environment—DS being single threaded and running on a single CPU, meaning that it's subject to delays caused by other processes running on the system. This is exactly as I claimed: some suggestions on other things which can help in a technical sense, but in practice are so dominated by other factors that it's all but impossible to actually detect their benefit. Attempts at optimizing code by just changing how you declare or refer to variables are almost never going to be substantial in their effects, except in situations where shaving a few processor cycles off your runtime actually matters. Guess what, though? In DM, that pretty much never matters. When you need something that intensive, DM is probably not where you're gonna be programming. The types of optimizations that actually matter are those to the algorithm itself, and especially being able to reduce the number of iterations of an algorithm. In general this is what programmers and computer scientists are interested in anyways. Going from e.g. O(n3) to O(n2) or from O(n2) to O(n), or generally any time complexity improvements, are a result of actually changing the algorithm to be better. Guess what? Silly shit like you suggested doesn't do that. As a comparison, I threw in OP's older version from here into the code as well. ```proc/SortOld(list/L) // requires operator<, stable . = L if (L.len <= 1) return if (L.len == 2) if (L[2] < L[1]) L.Swap(1, 2) return var/pivot = 1 + round(L.len / 2) var/list/L1 = .(L.Copy(1, pivot)) var/list/L2 = .(L.Copy(pivot, L.len + 1)) // merge L.Cut() while (L1.len && L2.len) if (L2[1] < L1[1]) L += L2[1] L2.Cut(1, 2) else L += L1[1] L1.Cut(1, 2) L += L1 L += L2mob verb SortTest4() world << "Sorting..." Sorted = SortOld(Data.Copy()) world << "Sorting test 4 (old algorithm) complete" ``` The results? ``` Profile results (total time)Proc Name Self CPU Total CPU Real Time Overtime Calls----------------------- --------- --------- --------- --------- ---------/proc/SortOld 4.173 22.661 22.678 4.075 168927/proc/SortModification2 4.026 20.970 20.971 3.928 65535/proc/SortModification1 4.010 20.722 20.735 3.912 65535/proc/SortUnmodified 3.979 20.584 20.577 3.881 65535/mob/verb/SortTest4 0.001 4.174 4.664 0.000 1/mob/verb/SortTest3 0.001 4.027 4.511 0.000 1/mob/verb/SortTest2 0.001 4.011 4.494 0.000 1/mob/verb/SortTest1 0.001 3.980 4.466 0.000 1 ``` Notice how there's almost 1/3 as many iterations when sorting that list using their new algorithm compared to their old one, and (relative to Total CPU listed above) that brings it down by almost two seconds. Reflecting on that, why would you think that your ridiculous suggestion—one which has no actual impact on the algorithm itself—would be appreciable at all?
 Dec 20 2019, 7:16 am Your library is causing the issue. Once you fix that, you should see the correct results. @Popisfizzy
 Dec 20 2019, 7:26 am In response to Kozuma3 Lmao. First off, it's operating perfectly fine and you're clearly grasping at straws. Second off, even if it was malfunctioning and causing runtime errors, you need to explain how this would actually impact the data. At best, this is populating the Data list with a bunch of garbage—but that's garbage that is still technically valid data which can be sorted and thus is perfectly valid to test on. Just to humor you, I reduced to an example of the Data list being populated with 1000 elements. Trying to print out 150,000 values in DM, even to a file, would be a nightmare. Here is that data post-sort: 0.000394702, 0.00269377, 0.00393319, 0.00489557, 0.00573146, 0.00633335, 0.00795192, 0.00845587, 0.0102613, 0.0108168, 0.0132338, 0.0134626, 0.0147516, 0.0156686, 0.0161802, 0.0169604, 0.0183719, 0.0186136, 0.0203481, 0.0211753, 0.0221591, 0.026564, 0.0276611, 0.028061, 0.0298457, 0.0306025, 0.0337009, 0.0337463, 0.033986, 0.0363474, 0.0369039, 0.0379428, 0.0387174, 0.0416453, 0.0418301, 0.0420137, 0.0440149, 0.0454901, 0.046087, 0.0469148, 0.0472939, 0.0495639, 0.0495746, 0.0504353, 0.0505817, 0.0518334, 0.0523582, 0.0526712, 0.0536602, 0.0545932, 0.0572371, 0.0573062, 0.0577759, 0.0584117, 0.0599725, 0.0615979, 0.0624365, 0.0629784, 0.0631205, 0.0639055, 0.064414, 0.066711, 0.0667744, 0.0693244, 0.0697936, 0.0698167, 0.070877, 0.0709814, 0.0725368, 0.0736887, 0.0740927, 0.0786593, 0.079816, 0.0821482, 0.0829545, 0.083671, 0.0839114, 0.0841722, 0.0851855, 0.0854439, 0.0856694, 0.0862647, 0.086511, 0.0875077, 0.0877422, 0.0900524, 0.090825, 0.0912995, 0.0913665, 0.0914723, 0.0925649, 0.0947127, 0.0950455, 0.0960954, 0.0961872, 0.0962008, 0.0964451, 0.0970541, 0.0972088, 0.100747, 0.103824, 0.104595, 0.105306, 0.107528, 0.108885, 0.109025, 0.10908, 0.109306, 0.109722, 0.110916, 0.111627, 0.114132, 0.114794, 0.11512, 0.11528, 0.115391, 0.115395, 0.116292, 0.116576, 0.117819, 0.118389, 0.119371, 0.119793, 0.121995, 0.122019, 0.122089, 0.123305, 0.12333, 0.124889, 0.125962, 0.127506, 0.12766, 0.127954, 0.12967, 0.131251, 0.132269, 0.132346, 0.132853, 0.133826, 0.136127, 0.138032, 0.138333, 0.139121, 0.139233, 0.14212, 0.143428, 0.144429, 0.145479, 0.145507, 0.14578, 0.146858, 0.147868, 0.148948, 0.149169, 0.149541, 0.15343, 0.15441, 0.15527, 0.155958, 0.156158, 0.15672, 0.158251, 0.163258, 0.163405, 0.16471, 0.165137, 0.165516, 0.165569, 0.16739, 0.167732, 0.168401, 0.169355, 0.170356, 0.170819, 0.171109, 0.171372, 0.172069, 0.172853, 0.173648, 0.174976, 0.175983, 0.176137, 0.177066, 0.177981, 0.179101, 0.179385, 0.180603, 0.181422, 0.182707, 0.182801, 0.183158, 0.183369, 0.185602, 0.185703, 0.185987, 0.187112, 0.188286, 0.189858, 0.190107, 0.190534, 0.190737, 0.191221, 0.191621, 0.193255, 0.193475, 0.19398, 0.194217, 0.19488, 0.19719, 0.198268, 0.199355, 0.199355, 0.200177, 0.202462, 0.202901, 0.203231, 0.206455, 0.206964, 0.20863, 0.208819, 0.209341, 0.211273, 0.211281, 0.21166, 0.214699, 0.215514, 0.21636, 0.217212, 0.218738, 0.218888, 0.219542, 0.219637, 0.221592, 0.22175, 0.222988, 0.224862, 0.225912, 0.226864, 0.227023, 0.227144, 0.23145, 0.231794, 0.232063, 0.232534, 0.233335, 0.235362, 0.238391, 0.238439, 0.238555, 0.23918, 0.239377, 0.240016, 0.24013, 0.240672, 0.241858, 0.24292, 0.243099, 0.243156, 0.24513, 0.250475, 0.250725, 0.250999, 0.251096, 0.252346, 0.253066, 0.253301, 0.254102, 0.254107, 0.254473, 0.254565, 0.255803, 0.257382, 0.257971, 0.258379, 0.259252, 0.25965, 0.261639, 0.261707, 0.263401, 0.263759, 0.265369, 0.266866, 0.267615, 0.269441, 0.270992, 0.271851, 0.272962, 0.273178, 0.273393, 0.281354, 0.282199, 0.282206, 0.283068, 0.28309, 0.284217, 0.285314, 0.285519, 0.286052, 0.286458, 0.286874, 0.287203, 0.288147, 0.288737, 0.289211, 0.289442, 0.289808, 0.294071, 0.294379, 0.295049, 0.295077, 0.296037, 0.296633, 0.297407, 0.297523, 0.29755, 0.299536, 0.301325, 0.301905, 0.301961, 0.302718, 0.304412, 0.304507, 0.305636, 0.307493, 0.309626, 0.310979, 0.311226, 0.31123, 0.311472, 0.312497, 0.312686, 0.315789, 0.315949, 0.316802, 0.318119, 0.31868, 0.318691, 0.318717, 0.322816, 0.324445, 0.324572, 0.3259, 0.326049, 0.326242, 0.326405, 0.329809, 0.330506, 0.330781, 0.330849, 0.331231, 0.33162, 0.333524, 0.334186, 0.335955, 0.336248, 0.33815, 0.339029, 0.341869, 0.342508, 0.34274, 0.343184, 0.343257, 0.343437, 0.344415, 0.345081, 0.345527, 0.346761, 0.34833, 0.350641, 0.351259, 0.35163, 0.353976, 0.354041, 0.35549, 0.356002, 0.356143, 0.356184, 0.358339, 0.359551, 0.359574, 0.359962, 0.361006, 0.36262, 0.363672, 0.363885, 0.364385, 0.364417, 0.364422, 0.36471, 0.367656, 0.368016, 0.369194, 0.37139, 0.37145, 0.372683, 0.372915, 0.37383, 0.374084, 0.375292, 0.375465, 0.375992, 0.376684, 0.377631, 0.378415, 0.383356, 0.385039, 0.385458, 0.38632, 0.389176, 0.389645, 0.390639, 0.391138, 0.391772, 0.39259, 0.395101, 0.395157, 0.395467, 0.397018, 0.400652, 0.400703, 0.401549, 0.403476, 0.404148, 0.407103, 0.407533, 0.40762, 0.407871, 0.409595, 0.409966, 0.41471, 0.415159, 0.41521, 0.415713, 0.415808, 0.416407, 0.420057, 0.423201, 0.423977, 0.42696, 0.427158, 0.427168, 0.429391, 0.431239, 0.431378, 0.431445, 0.431735, 0.432217, 0.433184, 0.434878, 0.435486, 0.436801, 0.437929, 0.438481, 0.438785, 0.4405, 0.441984, 0.443916, 0.445518, 0.445781, 0.445944, 0.447298, 0.448336, 0.450653, 0.452208, 0.452499, 0.45453, 0.455346, 0.455749, 0.456422, 0.459262, 0.459402, 0.459834, 0.46083, 0.461533, 0.463428, 0.464095, 0.464786, 0.465463, 0.465659, 0.465663, 0.4663, 0.467467, 0.467985, 0.468097, 0.468678, 0.470781, 0.471912, 0.471985, 0.472741, 0.473706, 0.473758, 0.474219, 0.474496, 0.475121, 0.475293, 0.47585, 0.476388, 0.476777, 0.477911, 0.478502, 0.478597, 0.480529, 0.481695, 0.482184, 0.483088, 0.483482, 0.484181, 0.484558, 0.484628, 0.487841, 0.487877, 0.487981, 0.489151, 0.490911, 0.494593, 0.494932, 0.496272, 0.496534, 0.497423, 0.500433, 0.501689, 0.501906, 0.502672, 0.503964, 0.504267, 0.50533, 0.505427, 0.506601, 0.50671, 0.510575, 0.510674, 0.511278, 0.512046, 0.512247, 0.51417, 0.515496, 0.515664, 0.51852, 0.518613, 0.522189, 0.522248, 0.523639, 0.523924, 0.524253, 0.524491, 0.528564, 0.528831, 0.530818, 0.533436, 0.534321, 0.534659, 0.535634, 0.535662, 0.5384, 0.540482, 0.54535, 0.546955, 0.548495, 0.548563, 0.55065, 0.550813, 0.552203, 0.553061, 0.553678, 0.553898, 0.555128, 0.555795, 0.561049, 0.562129, 0.563142, 0.567012, 0.567138, 0.568691, 0.569454, 0.569808, 0.569863, 0.569866, 0.571165, 0.571704, 0.571748, 0.571835, 0.572972, 0.575256, 0.576143, 0.576874, 0.577353, 0.577941, 0.580011, 0.580592, 0.58065, 0.582728, 0.584929, 0.586032, 0.586404, 0.588133, 0.589521, 0.589848, 0.590987, 0.591242, 0.59156, 0.593247, 0.596293, 0.597642, 0.598089, 0.598374, 0.599454, 0.602971, 0.602997, 0.60356, 0.604282, 0.605638, 0.607938, 0.609886, 0.611931, 0.612449, 0.613174, 0.614058, 0.615008, 0.615774, 0.617102, 0.618541, 0.618649, 0.62213, 0.622401, 0.622632, 0.623061, 0.624356, 0.624683, 0.625225, 0.625955, 0.62807, 0.628156, 0.629363, 0.630204, 0.630314, 0.630775, 0.630857, 0.631673, 0.632453, 0.632809, 0.633017, 0.633133, 0.634866, 0.636394, 0.636578, 0.6367, 0.638058, 0.638421, 0.640152, 0.641245, 0.642682, 0.643699, 0.647823, 0.648541, 0.648868, 0.649748, 0.651255, 0.65185, 0.653992, 0.654505, 0.655352, 0.656078, 0.657411, 0.65764, 0.657655, 0.657753, 0.657753, 0.658175, 0.66001, 0.661065, 0.661433, 0.662655, 0.662771, 0.66487, 0.667137, 0.66762, 0.667862, 0.668411, 0.66912, 0.669674, 0.670136, 0.671147, 0.671429, 0.672673, 0.672729, 0.673242, 0.673441, 0.673501, 0.674134, 0.674235, 0.677422, 0.678724, 0.679136, 0.679739, 0.680958, 0.682502, 0.684452, 0.684676, 0.686142, 0.686654, 0.687083, 0.687407, 0.687488, 0.688376, 0.691682, 0.695459, 0.697171, 0.69922, 0.699371, 0.700075, 0.702648, 0.703011, 0.70346, 0.703981, 0.705661, 0.706134, 0.706396, 0.710323, 0.710364, 0.711006, 0.713605, 0.714295, 0.714938, 0.715552, 0.7156, 0.716235, 0.718343, 0.718445, 0.718762, 0.719088, 0.719832, 0.723628, 0.723861, 0.726244, 0.726749, 0.726956, 0.728188, 0.728289, 0.729211, 0.73077, 0.733191, 0.734467, 0.736525, 0.736916, 0.738594, 0.739522, 0.740028, 0.740897, 0.741729, 0.742969, 0.743429, 0.744906, 0.745008, 0.74619, 0.74669, 0.747491, 0.749915, 0.751474, 0.752455, 0.75354, 0.754798, 0.755108, 0.755128, 0.755433, 0.756491, 0.756608, 0.757049, 0.757329, 0.757907, 0.758292, 0.758715, 0.759714, 0.760951, 0.76469, 0.767141, 0.767263, 0.767818, 0.769776, 0.769815, 0.770924, 0.771045, 0.77263, 0.773947, 0.774117, 0.77477, 0.77654, 0.777308, 0.777715, 0.779152, 0.779287, 0.782966, 0.783244, 0.783595, 0.784313, 0.784966, 0.785095, 0.789136, 0.789594, 0.789999, 0.790271, 0.792027, 0.792603, 0.79263, 0.79298, 0.793682, 0.794367, 0.796225, 0.796563, 0.797164, 0.797175, 0.798661, 0.799015, 0.799375, 0.799839, 0.799909, 0.801596, 0.802031, 0.804089, 0.804741, 0.80807, 0.809496, 0.810336, 0.810762, 0.811128, 0.814376, 0.816717, 0.816939, 0.817886, 0.819091, 0.819426, 0.823583, 0.825459, 0.826591, 0.827483, 0.833229, 0.834476, 0.834534, 0.834959, 0.83715, 0.841096, 0.842514, 0.843691, 0.843858, 0.844511, 0.845956, 0.847139, 0.848978, 0.849211, 0.850148, 0.850323, 0.850609, 0.852275, 0.853326, 0.853687, 0.854615, 0.856333, 0.856601, 0.857409, 0.8576, 0.858304, 0.85884, 0.859023, 0.861878, 0.862508, 0.863214, 0.86503, 0.868364, 0.869014, 0.872086, 0.872109, 0.873348, 0.874972, 0.877989, 0.87923, 0.880085, 0.880823, 0.881955, 0.882334, 0.882562, 0.883857, 0.884811, 0.885203, 0.885514, 0.886616, 0.889438, 0.894285, 0.895051, 0.896453, 0.896655, 0.897225, 0.897488, 0.897845, 0.899757, 0.900142, 0.901093, 0.903046, 0.904018, 0.905773, 0.906693, 0.907878, 0.908733, 0.908902, 0.909074, 0.909636, 0.909949, 0.911537, 0.911574, 0.914172, 0.915817, 0.916119, 0.916326, 0.916886, 0.917297, 0.918033, 0.918607, 0.918813, 0.921534, 0.921736, 0.922752, 0.922881, 0.923456, 0.923814, 0.923929, 0.924285, 0.925221, 0.925417, 0.925905, 0.926344, 0.926442, 0.928276, 0.931086, 0.932361, 0.93451, 0.935259, 0.935389, 0.935833, 0.937896, 0.938148, 0.939266, 0.940001, 0.940115, 0.941021, 0.941193, 0.942872, 0.943264, 0.943895, 0.944996, 0.947436, 0.947982, 0.949312, 0.949817, 0.950193, 0.951085, 0.951166, 0.951996, 0.953271, 0.954223, 0.958582, 0.959358, 0.960042, 0.960724, 0.962659, 0.963476, 0.964852, 0.965593, 0.965644, 0.96583, 0.965914, 0.966527, 0.966814, 0.966865, 0.966927, 0.967008, 0.96812, 0.971667, 0.971891, 0.973157, 0.973336, 0.973624, 0.974447, 0.97683, 0.980317, 0.981453, 0.983635, 0.98434, 0.984497, 0.984681, 0.985511, 0.986512, 0.987002, 0.987672, 0.987991, 0.989122, 0.990076, 0.990954, 0.993363, 0.994284, 0.995053, 0.996657, 0.998601 You can use an online tool (such as this one) to verify there are 1000 entries there, as claimed. But please, keep grasping. It's hilarious.
 Dec 20 2019, 7:31 am ```mob verb SortTest4() world << "Sorting..." Sorted = SortOld(Data.Copy()) world << "Sorting test 4 (old algorithm) complete" ``` Keep reading this code until you learn it, the syntax that is. Then the goal is to retain the information. I'll gladly continue to help you comprehend this where able.
 Dec 20 2019, 7:37 am What's this? Bringing up for like the third time an entirely different """problem""" unrelated to the last ones (all of which have been refuted) while completely ignoring how you were wrong? Boy, sure smells like someone grasping at straws in here
 Dec 20 2019, 7:41 am In response to Popisfizzy Popisfizzy wrote: What's this? Bringing up for like the third time an entirely different """problem""" unrelated to the last ones (all of which have been refuted) while completely ignoring how you were wrong? Boy, sure smells like someone grasping at straws in here I feel like you're missing the point, your code is incorrect as your library is causing it to run-time persistently. I can't help those who refuse to be helped tho, sorry.
 Dec 20 2019, 7:58 am (Edited on Dec 20 2019, 8:14 am) The code you quoted here does not use my library at all. The Data list is a plain old /list object which is populated when the client logs in, using my library. From that point forward, my library is not used in any way, shape, or form. The Data object remains persistent and unsorted, and I ensure that by making hard copies of it any time I pass to one of the sorting methods (by using the build in /list.Copy() method, nothing of my own). Sorted is another /list object, one I used just to verify the output is actually being sorted. So, let me make this clear: you have yet to name or highlight any specific runtime errors, any specific code from my library that is causing these ghostly runtime errors, have made no compelling argument about how those runtime errors would actually cause the tests I have presented to fail, nor have you highlighted any code that uses my library as a location where the tests fail. You clearly have no idea what you're talking about. I mean, you think you do, but the difference between us is that to my name I have an integer arithmetic library and libraries built off of it for encryption and pseudo-random number generation and you on the other hand have as your latest libraries a pixel movement lib and one for sanitizing text. One of us has the more sophisticated code, and trust me when I say it's not you. Lastly, here's a pic of DS after generation of the data and running all the verbs. Look at all them runtimes, eh? I know they still show up in DS, because I had to fix a bunch caused by your suggestions for SortModification1(). The OP uses the . variable correctly as a return value, so your changes just put right in cause it to have runtime errors out the wazoo until other changes are made to the code. I've said all I have to say here, and presented my case very thoroughly that your contributions are meager at best, garbage at worst. Keep pounding on this "runtime errors" door, but until you can actually present me with specific code, a runtime error, and the flawed output that invalidates the concrete test data I gave above, all you have are these straws you keep grasping. gl bro  FYI, if you agitate Kozuma enough and really make him confront the fact that he's super duper wrong it really makes him upset and lash out in childish ways.
 Dec 20 2019, 8:03 am Popisfizzy, what you're not understanding is that I am in fact correct. Libraries that have run-times built into them seems kinda, dumb? You wouldn't understand the kind of code I deal. rip 2 u but I'm different.
Page: 1 2