@rak1507 The 2016 year game has no connection to the programming competition anyway, and yes, the programming competition could have been automated earlier, but nobody did it. In principle, much of today's amazing technology could have been created long ago, if only people had had had the imagination/experience/knowledge.
it doesn't have to be automated to be transparent. just publish the winning solutions immediately after the deadline (assuming judging doesn't take too much time).
Week 9: as I wrote a year ago, "I've assumed that character scalars are not acceptable results - The Rules mention only character *vectors*. If scalars are ok, please don't count the leading glyph in the expression for 9."
Week 25: The first item of ⎕SD is not necessarily 25 - for example in the terminal I'm typing in right now ⎕SD is 39 151. The Rules say: "Expressions must not rely on local conditions, for example, the operating system, the exact date/time or specific input from the user."
tradfns are tradfns. Tradition. Backwards compatibility requires that they work the way they do. It's disingenuous to claim that they ought to be different than they are, or that they violate some "common sense" sacred cows of programming that were not yet religiously dogmatic at the time.
@voidhawk … ⊢{a←1 ⋄ }0 giving a value error; can't trace into a one-liner dfn; →0 in the session quits instead of resuming execution; plus←+ ⋄ a plus← and plus←+ ⋄ 1 plus a←2 overwriting plus; :: failing to catch ⎕SIGNAL etc.
Also forgot to mention during previous index origin discussions -- that new darling language Julia is also 1-origin based. I guess that should preclude it from use by anyone who knows better.
@KamilaSzewczyk One of the main contributors was Brendan Eich. He probably learned a lesson or two from experience with JS. Still, JS is way more popular than Rust, while truly having a lot of legacy quirks, and it cannot really discard anything, as that could break old websites.
oh yeah, i think scrapping up the web just like we scrapped up flash would be a not bad idea. Brendan Eich at first took a list of every design flaws in his past languages and put it in a single language just to see what happens
There's nothing legacy in APL that can't be discarded in a new implementation, at its core APL is the most elegant way I know of to express array operations
@ngn it has the same problem as APL that real life use cases are hidden away, I have no idea what a real world K project would look like, and the sort of real world things I might want to use a language for don't lend themselves to an array one anyway
i'll probably get eaten for that, but i just consider APL as a very good problem solving tool for smaller projects, and i don't see a business use for it
@rak1507 k has an additional problem: k developers don't like being seen, or their code being shared. they like to hide quietly in the shadows, in banks and hedge funds.
@KamilaSzewczyk With emphasis on the seems like :-) APLers and APL-using companies are notoriously bad a finding each other. Though Morten is trying to encourage the companies to monitor this room if they are looking for promising talent.
@KamilaSzewczyk fear of competition probably. in my experience, apl culture is somewhat closed too, but to a lesser extent. at least until dyalog decided to hire adam :)
@KamilaSzewczyk just spitballing, but maybe it could have something to do with the fact that sharing the code would instantly trigger a golfing crusade which could be crushing to one's ego .. ;)
i don't think vector & functional langs like APL are simple, because they enforce a good code style and writing performant code in them seems a bit difficult
@rak1507 Why harp on what vector langs aren't suited for? If you're doing image processing, signal processing, statistics, anything like that APL will give a massive boost
If you want the ultimate in speed use Fortran or ASM if not a GPU, but that takes orders of magnitude longer than writing APL. If your task only involves a few algos that must be as fast as possible, then the former options are the best way to go. If you're writing more algos and want to be done quickly, vector langs are better
@ngn Due to the misery of supporting APL characters on mass-market computers in the 90s. By the time J released Unicode had solved the problem
I read that in the 80s there was a PC graphics card for APL with a physical switch on it that would toggle between displaying the regular DOS character code page and one with APL characters
if you were to take this restriction and bring it back to unicode, it'd make as much sense as transcoding flac to mp3 128kbps and then back again to flac
@ngn J is required to serve it's previous users and documentation base. It's a weird position to take, acting like Dyalog is somehow nefarious for keeping backwards compatibility in a programming language.
Go compare what coding in GNU APL feels like versus what Dyalog gives you.
@rak1507 That's the way it is for a programming language that has a legacy. I don't understand at all what you are trying to say. Name another example of a language which successfully broke with it's own past in terms of backwards compatibility to the extent that has been proposed here, I'd like to know.
I had a long talk with Geoff Streeter yesterday, and he was quite positive towards adding a ⎕EL that'd let code declare what Evolution Level of the language the code expects. This will allow fixing warts!
@Adám first of all, k9 is very different from other ks. i don't think it should even be called a k. second, why would you be paying for two different licences? just use the newer one.
it all comes down to the willingness to rewrite old code
k programs tend to be small and more easily rewritten than apl's notorious legacy
the more dyalog do this - religiously maintaining backwards compatibility instead of encouraging customers to fix their code - the more they sink into this trap
again i agree with ngn, some features should start getting deprecated, dyalog should present clear and simple workaround for getting rid of them, and remove them in upcoming versions
Management even wanted to make a breaking change today, and I argued against it, instead suggesting making an additive change and deprecating the current stuff.
<moon-child> I've come to the conclusion that deprecation cycles aren't a great longterm solution, from watching how they play out in d. Small compat breaks are easy, but the big potatoes never get addressed
Actually there was another one today: Unicode file handling functions are not currently standards compliant when it comes to handling invalid byte sequences. We're discussing what to do, stay non-compliant or break backwards compatibility.
My position is that you should push as much as possible into libraries, so that if a library is seriously wrong you can switch to a new one. Large libraries can figure out versioning, but overall it's much less of a hassle than making changes to the whole language.
Combining matrices with different row lengths is not really a natural operation to do. I think you want to find the common length and use Take to bring them both up to that length.
apparently java 16 has been out in early-access for a while, with vectors in incubator. On a simple isolated test I get a 1.5x boost on 32-bit int addition with overflow checking (just using the ((w^r)&(x^r)) < 0 check; 580ms→379ms for adding 65536-item arrays of 0…65535 10000 times. Dyalog's still of course much ahead at 280ms doing Smarter Things)
@dzaima setting the first item in each arg to 1800000000 results in it still taking 150ms, which should be just the initial array allocating (which is immediately discarded)
@dzaima Ah, I thought I remembered having to do the bitwise version for something. I feel like I got it an instruction or so better than ((w^r)&(x^r)) < 0, but I don't remember how.
But it's also entirely possible Java's just compiling poorly.
@KamilaSzewczyk Dfns use lexical scope, so they only see things that are defined where they are defined. As an experiment, try changing Stream into a tradfn to see if that makes it work.
@dzaima I've now added some decent fill support to my BQN, and fill elements are finally specified. I haven't found any constraints that would be reasonable to specify, and I've kept the requirements down to things I think are easy to implement. But as usual I'm open to comments on the spec.
I should be adding tests for specified fills pretty soon as well.
@KamilaSzewczyk why are you trapping specifically domain errors? and why cut back the stack with 'C'? documentation says with 'E' the trap should execute in the environment where the error occurred
@RikedyP re: APL event; i think a ton of great talks / things would be: From Python (NumPy) to APL Dyalog APL Major Additions (like what are the main things added in 18.0, 17.0, etc) A History of APL (cover APL/360, APL2, MicroAPL, Dylalog, etc) A (Very) Basic Introduction (i.e. not the average fork or Conway's game of life, but just a walk through of very simple expressions)
@dzaima it's definitely a bit broken though. With the same code, a function can consistently take 365ms, or >12000ms with no signs of improving. JIT ¯\_(ツ)_/¯
ayy, this matches Dyalog in performance of sum with 7.5-8us per 65536 items (in the rare case when it doesn't take 400us avg, that is ಠ_ಠ): https://dzaima.github.io/paste/#0jVLBauMwEL3nK@YoEyO6u0enhXTjZQ2GLQnkUkqR7UkiUCQjyak3Jf/ekUzbuCm0BzMevaenN09qu0rJGpwXnspGaqFgjbU3dtViLdHNCu1xi/YGijVcA3UDzFd3@e8iXz3eLfM/@XKZL7JJ@6VYafT2BsqgFH6/K6WIC67bE59J7e8foE/geQJnIqAOY9HKGtHUwnlWrlO4SjKiv7mH42iWI1rDivUHjqmIdOSiaQrdYM9@JFzoJhTXVVTGbAxsU3FtPIsQGQVJa1eh2RCDZdTPKEeujGlvTUdiPVeot36XEDa9jljsWTIMeH5CPfK8sWY/t1b8J@Mp9CnIeOpogBBJHU2b6gLFdxRf0RiiOoSZmTlwizQE2tain7uQrSNfl0y3sww/Z6fw6@ew5URfvEc7bLTYdDWWQqNjg6N/…
(I would definitely like to create a mini-language that either transpiles to java (or even straight to bytecode) to not have all that verboseness for vector operations)
@dzaima Oh, for reductions Dyalog just converts up from 16 to 32 bits immediately (adding adjacent pairs, maybe?) and adds about 2^16 of those at a time. That has the advantage that it's easy to support any bit width without extra overhead, but I'm not surprised your code is about the same speed.
@dzaima Oh, "int" is so confusing. Not sure what I did for 32-bit arrays but I think it involved 64-bit sums in registers. If you care you should be able to watch Dyalog with perf top as you do a sum.
@Marshall I barely can read regular assembly, reading dyalogs vector madness won't be particularly productive. (and i already match its performance here so it doesn't matter anyways)
I guess i'll leave more playing around tomorrow. Kinda sad I noticed java vectors this late :|
<moon-child> @Marshall dyalog.com/uploads/documents/Developer_Software_Licence.pdf ‘You may not (except as may otherwise be permitted by any applicable Law) translate, adapt, vary, modify, disassemble, decompile or reverse engineer the Software’
