« first day (835 days earlier)      last day (700 days later) » 

3:00 AM
@rak1507 I could only get an equal sized solution: {x(0,1+&s),&|\s:32=x}
 
 
6 hours later…
ngn
9:08 AM
@JohnE right, not pure c
@Traws @rak1507 32=x -> ^x (monadic ^ means "is null?"; space is the "null" for the char type)
now -1 by not assigning to s: {x(0,1+&^x),&|\^x}
 
ngn
9:36 AM
another -2: 0,1+&^x -> &1,^x
 
 
3 hours later…
12:29 PM
something like this is the k9 translation: {x(&~:':x),&|\~x}
 
ngn
12:39 PM
@chrispsn is " " falsy in k9?
 
 ~"laughing out loud"
00000000100010000
but other whitespace too (eg \n)
this problem is a great example of a situation where your first instinct (particularly in other langs) may be to reach for a split, then deal with each case using a filter or flip or drop, etc... but the best approach is probably clever indexing. in short: keep it flat
although it gets pretty short in k9 tacit: ,/(~:':;|\~)#\:
and this works in 2021.06.02: ,/(:':;&\)_\:
 
ngn
1:01 PM
@chrispsn ah, the non-eaching "filter" :)
for a moment i was horrified thinking that j-like forks have been added
 
 
2 hours later…
2:40 PM
who is e.l. whitney[1920-1966] multiple putnam winner from the shakti site?
googling it isn't getting me anywhere
 
ngn
@Razetime arthur's father
 
interesting
 
 
5 hours later…
8:01 PM
@ngn 10^7... it would be interesting to know e.g. when to change from quadratic to merge to radix. but it might be a hard question, as the speed depends on the input values. implying random input may not correlate to use cases. i don't know any better either.
 
ngn
@ktye why not always radix (for simple types)
 
@ngn isn't it slower for small batches?
 
ngn
might be, but then it doesn't matter much
 
not if you run once, but many times? i think it should be as fast as possible.
@ngn what should be do about nans (float)? my radix puts them to the front (as the source of inspiration: github.com/shawnsmithdev/zermelo).
 
ngn
@ktye i think doubles should be compared as if they are longs, after a small correction: negatives should be xor-ed with 0x7f..f, positives should be kept as-is
@ktye right, i just tried arrays of size 10 and radixsort is much slower :(
actually, there's some range of array lengths for which stdlib's mergesort() is fastest
 
8:22 PM
also, some algorithms handle already sorted input quickly, others don't. that could be nice, if you have no (sorted) flags.
 

« first day (835 days earlier)      last day (700 days later) »