No biggy Aristotle, It was late and I was tired, but I didn't understand why John M. Dlugosz was calculating his very complicated 'first value', thereby ensuring that he had a overly complicated piece of processesing in order to decode his stream.
As you had done such a thorough job of golfing his code, I thought maybe you saw the reason that I was missing.
I see now that you just enjoyed the golf, and didn't bother yourself with the architecture of the course:)
What's this about a "crooked mitre"? I'm good at woodwork!
| [reply] |
Oh. Yes, I deliberately avoided suggesting a different data format since original poster inquired about how to simplify his code. You are right that the data format complicates matters needlessly - in fact, it is very poorly chosen since the total grows without bounds, so you cannot easily encode streams of arbitrary length using this format, whereas by simply passing along the first value of the stream before storing deltas, the first element of the encoded stream has a constant size regardless of the stream's length.
I wasn't actually golfing per se though. :-) I actually consider the code production quality. The only opaque location in my code, IMHO, is the $_[0] = -$_[0] bit, in which as I noted the opacity is a matter of math rather than Perl, and because I saw it is unclear and was intending this to be production quality code, I added a comment so the next person to read it would know the intent without having to re-deduce the algorithm from the code to understand what's going on. Personally, I prefer a slightly opaque and efficient solution clarified by a comment over a swathe of statements that do the same thing "simplemindedly". Self-documenting does not equal easily maintainable, IMHO. That's what God gave us comments for. :-) Anyway, I think I went off on a bit of a tangent here.. </soapbox>
Makeshifts last the longest.
| [reply]
[d/l] |
I quite agree with you on all points.
| [reply] |