true, but to be fair-play one should just use of the mill stuff.
there are plenty of guys down-voted for answers like:
“cstmAZ()” write compiler/interpreter on your own …
(beyond John Skeet on SO - but that’s 1st place karma…;-) )
I’ve already punished myself for global variable…
can’t beat this fancy GolfScript…
About 10 years ago i was a member of both communities and wrote manyprograms in both j and k to compare and contrast them. k always cameout on top in terms of succinctness. It is also much faster - it hasno guardrails to protect the user from himself. js guardrails addabout 50% to execution speed.Likely this comes from ks reliance on a single characters torepresent built in functions. j in contrast frequently uses two (ormore) where the second and subsequent characters are very low incontent (chosen from . and :). Arthur has looked at ks source code andconcluded that in most cases a ZIP actually INCREASES its size! k isvery near the limit imposed by information theory.Perhaps because of its small size and concision there is much lessproblem with user programs being outdated by a change in the languagerelease. This is a tremendous issue in the j community. That languagehas had frequent revolutions in format. They are for the better, butplay havoc with user code.i tried to make sense of one large program written in the previousversion of j, only to see it was unreadable because a machine hadforced it into a single file and the source form, which had severalfiles, was lost. So not only was in unexecutable it wasindecipherable.Likely the biggest program i published on the k list was a boggleprogram. i spent many hours of pleasurable activity with a TRS 100which implemented a Boggle board and timer making multiperson playeasy. i was eager to redo this in k, and wrote a version with an AIthat solved all puzzles for various board sizes and compiled variousdictionaries faster than one could hit the carriage return. Itextended the scoring procedure for long words by using a Fibonaccischeme.Eugene McDonnell (who wrote about Boggle in Vector magazine (number28, issue 18.1)) asked for this source code before writing his jversion and submitting it as an “at play” article. This version wasnot only much longer, but much slower than my k version. The primaryreason being a fundamental lack in the j language of a way ofaccessing ragged arrays. These are ubiquitous in language problemslike Boggle, but also in our modern XML based online world.One can simulate ragged arrays in j (of course it is a Turing machine)with boxing. There is nothing in j though that approaches the fluidityand speed of direct addressing in k, which inherited this from Scheme.http://www.jsoftware.com/jwiki/Doc/Articles/Play181 Eugene`s Bogglegreg~krsnadas.org
JackA legend which Arthur contributed directly to by posting to it, as hecontributed to j by writing its ~Incunabulum.Not that Golfing is the best way to human efficacy, but it sure helpsto have everything visible.—~http://www.jsoftware.com/jwiki/Essays/Incunabulumhttp://jsoftware.com/pipermail/programming/2009-November/017017.htmlgreg~krsnadas.org--from: Jack Andrews effbiae@gmail.comto: personal-kdbplus@googlegroups.comdate: 26 August 2012 04:48subject: Re: [personal kdb+] code golfgreg wrote:> in most cases a ZIP actually INCREASES its size! k isit is legend that zipping arthur’s code increases its size no byteshave the top bit set, so compression isn’t hard.but i know what you mean.we compress code - and we might be able to do it better than zip
I didn’t go this direction because of input param conversion, so decided to stick with string ops, namely: _
Tried simmilar aproach in second? email, it was aware of U/L case; even though was still missing input check…which takes most of the chars.
As I’ve mentioned, without char array arithmetic (“a”+65 - like c guys did, very clever stuff with masks etc..), it will be v. difficult to zip it more…