[ prog / sol / mona ]

prog


What are you working on?

49 2019-01-11 17:51

>>47

Thanks, but this is a bit of an office contest type thing over here, so that wouldn't be fair.

Oh man, that sounds like fun, good luck then anon.

Since the struct and an ad hoc representation like a list would be isomorphic as far as their information content is concerned, I take it that this is an aesthetic preference type of aversion.

Yep, I think record-types tend to be implemented as vectors, but it's really just some scars from learning C early on. (you've seen many of them)

Obviously there is no obligation to fix any particular issue in any particular version, such as the next one to be posted. Observations may even be overruled and entirely discarded since, again obviously, the code writer is the decision maker.

Of course, it does seem like good practice to prioritise bug fixes when they're first discovered though so they don't end up confusing you at a higher level of abstraction though. This actually reminded me that at some point I need to get a bit better about writing tests. On overruling your observations, they've all just been completely correct, the only two or three times I considered it, one or two times was due to my misunderstanding and the other was me focusing on micro optimisations instead of building up a abstraction that would let me get a big-O gain later down the line.
>>48

There's a lot of (vector-length vector) recomputation in vector->radix.

I'm really bad about this, it's a pretty low cost because scheme has enforced vector bounds, but that doesn't mean it's free. It's also just not very aesthetic.

The leaf-length computation of vector->radix-iter duplicates work already done in vector-copy-32, which could return the vector and length as a cons.

ugh... okay done. (it's a good catch honestly)

radix-copy-path calls 'proc' with the output of vector-position, which has a range of [0...31], so the 'unless' test of radix-append needs another look.
Why call internal-radix-constructor with hardcoded -1 for null-radix when make-radix handles this via undef? If you want null-radix to be a singleton rather than a constructor you can move it after make-radix.
(radix->vector-iter result length length) in radix->vector-iter is simply result.

fixed, fixed, & fixed. Along with the remainder from your last post. http://ix.io/1y3G

199


VIP:

do not edit these