Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Array Cast – A podcast about the array programming languages

arraycast.com

Post reply on HN
Print view View original

121–130 of 141 posts

Re: The Array Cast – A podcast about the array programming languages

#121

Post by geocar »

rak1507 wrote: post #114
geocar wrote: post #86

Earlier quoted context omitted.

If this were me, and I needed a function like us, I would have written this: us:{$[x~(z;y);,"_";y]}[(*K;,"*")]': I would be interested in seeing anything that was shorter[1] and faster than that in any language , and I would be very curious to learn from anyone who could also do that faster than me. But I'm not a fetishist: I didn't learn k because it was cute, and I don't wake up every day looking for ways to rewrit…

Why do you pass in (*K;,"*") as x instead of hard-coding it in x~(z;y)? Clarity?

Great question!

     v:("select";,"*";"from";"tacos")

     us:{$[#i:&{(y~*K)&"*"~*x}':x;@[x;i;:[;,"_"]];x]}              
     \t:100000 us v
    233
     us:{$[(*K;,"*")~(y;x);,"_";x]}':
     \t:100000 us v
    206
     w:(*K;,"*");us:{$[w~(y;x);,"_";x]}':
     \t:100000 us v
    179
     us:{$[x~(z;y);,"_";y]}[(*K;,"*")]':
     \t:100000 us v
    129
I think it's important to remember just how simple k is: We the programmer know that (*K;,"*") isn't supposed to change, so we should be explicit so k "knows" this as well. In addition to never changing, we also know the value is only used once, so we really don't want to look anything up in the workspace every time we call us: Again, let us be explicit.

On the other hand, this:

     us:{$[#i:& XXX ;@[x;i;:[; YYY ]];x]}
is an extremely recognisable idiom. It occurs several times in sql.k so the reader is probably used to seeing it at this point. It also has a similar syntactic structure to the APL '@' so it may be more "obvious" to an APL programmer. Maybe the reason I write it this way is that I'm not a very experienced APL programmer :)

Re: The Array Cast – A podcast about the array programming languages

#122

Post by geocar »

rak1507 wrote: post #113
Avshalom wrote: post #97

Earlier quoted context omitted.

okay so it's not really smaller because it uses UTF8 also it relies on order of operations to get rid of the parens around ⍵≡'*' but us←{('_'@(1+⍸2{(⍺≡⊃K)∧⍵≡'*'}/⍵))⍵} is one(1) character shorter.

⍵≡'*' should be ⍵≡,'*' like in the original k us←⊃,⍥⊆2{(⍺≡⊃K)∧⍵≡,'*':,'_'⋄⍵}/⊢ is shorter anyway

    us←{'_'@{¯1⌽⍵⍷⍨(⊂⊃K),'*'}⍵}

Re: The Array Cast – A podcast about the array programming languages

#123

Post by geocar »

jiggawatts wrote: post #115
geocar wrote: post #104

Earlier quoted context omitted.

> To me, this is infinitely more readable: Yes, to you. Just like Chinese would be infinitely less readable to you, if you don't know Chinese. Do you think this is a deep observation? The real challenge is knowing whether it is worth it to learn k so that it becomes readable. - How many characters is it? This is a useful metric when you realise bug/defect rate is proportional to the physical size (in rows and columns…

> 126msec for 100k cycles. Or to put it another way: 1,200 nanoseconds. That's about 3,000-5,000 instructions on a modern CPU. Believe it or not, that's actually pretty bad . After jumping through some hoops to ensure that rustc doesn't just compile the whole thing down to a constant, I benchmarked my version as taking 15-20 nanoseconds per iteration. About 45-80 instructions! I actually couldn't quite believe it mys…

I'm not sure getting the wrong answer fast is something to be proud of.

Your rust code has a bug in it, is longer, and you spent more time on it.

Re: The Array Cast – A podcast about the array programming languages

#124

Post by rak1507 »

geocar wrote: post #121
rak1507 wrote: post #114

Earlier quoted context omitted.

Why do you pass in (*K;,"*") as x instead of hard-coding it in x~(z;y)? Clarity?

Great question! v:("select";,"*";"from";"tacos") us:{$[#i:&{(y~*K)&"*"~*x}':x;@[x;i;:[;,"_"]];x]} \t:100000 us v 233 us:{$[(*K;,"*")~(y;x);,"_";x]}': \t:100000 us v 206 w:(*K;,"*");us:{$[w~(y;x);,"_";x]}': \t:100000 us v 179 us:{$[x~(z;y);,"_";y]}[(*K;,"*")]': \t:100000 us v 129 I think it's important to remember just how simple k is: We the programmer know that (*K;,"*") isn't supposed to change, so we should be exp…

Thank you for the extensive answer, that's very interesting that there's such a performance difference. I would have naively assumed if anything keeping it as a constant would be faster.

Another question: Why do

  $[#i:& XXX ; @[x;i;:[; YYY]]; x]
when (if I'm not mistaken, which I could be) you can do

  @[x;i:& XXX;:[; YYY]]
Performance again? A quick test using ngn/k did seem to find the first one faster, but only marginally.

Re: The Array Cast – A podcast about the array programming languages

#125

Post by rak1507 »

geocar wrote: post #122
rak1507 wrote: post #113

Earlier quoted context omitted.

⍵≡'*' should be ⍵≡,'*' like in the original k us←⊃,⍥⊆2{(⍺≡⊃K)∧⍵≡,'*':,'_'⋄⍵}/⊢ is shorter anyway

us←{'_'@{¯1⌽⍵⍷⍨(⊂⊃K),'*'}⍵}

Ah, ⍷, clever, don't even need the outer {...⍵},

  us←'_'@{¯1⌽⍵⍷⍨(⊂⊃K),'*'}

Re: The Array Cast – A podcast about the array programming languages

#126

Post by geocar »

rak1507 wrote: post #125
geocar wrote: post #122

Earlier quoted context omitted.

us←{'_'@{¯1⌽⍵⍷⍨(⊂⊃K),'*'}⍵}

Ah, ⍷, clever, don't even need the outer {...⍵}, us←'_'@{¯1⌽⍵⍷⍨(⊂⊃K),'*'}

Yes!

You could also do: ⌽'*',⊂⊃K to save another character. I don't know if that's "better" though.

Re: The Array Cast – A podcast about the array programming languages

#127

Post by geocar »

rak1507 wrote: post #124
geocar wrote: post #121

Earlier quoted context omitted.

Great question! v:("select";,"*";"from";"tacos") us:{$[#i:&{(y~*K)&"*"~*x}':x;@[x;i;:[;,"_"]];x]} \t:100000 us v 233 us:{$[(*K;,"*")~(y;x);,"_";x]}': \t:100000 us v 206 w:(*K;,"*");us:{$[w~(y;x);,"_";x]}': \t:100000 us v 179 us:{$[x~(z;y);,"_";y]}[(*K;,"*")]': \t:100000 us v 129 I think it's important to remember just how simple k is: We the programmer know that (*K;,"*") isn't supposed to change, so we should be exp…

Thank you for the extensive answer, that's very interesting that there's such a performance difference. I would have naively assumed if anything keeping it as a constant would be faster. Another question: Why do $[#i:& XXX ; @[x;i;:[; YYY]]; x] when (if I'm not mistaken, which I could be) you can do @[x;i:& XXX;:[; YYY]] Performance again? A quick test using ngn/k did seem to find the first one faster, but only margi…

That's a harder question. Why do other people do the things they do? One reason might be because it was convenient for them to write (and debug) things that way.

But it is possible they are doing it for performance reasons, so maybe it's worth considering why it should be faster? That is to say, should the programmer assume the latter is faster than the former?

To do that, I would suggest putting yourself in the shoes of the implementor: You have a choice of how it should be implemented. Knowing this decision will affect every use of @[x;i;f], should it begin with an if statement like this?

    if(y->n == 0)return x;
But before you answer, remember the next thing @[x;i;f] needs to do, is consider if x has any additional references, because if it does, it has make a copy of x. That means there already needs to be an if statement that looks like this:

    if(x->r > 0) x = copy(x);
So one way to think about this, is to ask if you are implementing @[x;i;f], should you choose one branch or two?

    $[#i:& XXX ; @[x;i;:[; YYY]]; x]
Also: Do you see the part that goes :[;YYY]? That's constructing an object. Do you think it is worth avoiding that allocation if possible?

Re: The Array Cast – A podcast about the array programming languages

#128

Post by rak1507 »

geocar wrote: post #127
rak1507 wrote: post #124

Earlier quoted context omitted.

Thank you for the extensive answer, that's very interesting that there's such a performance difference. I would have naively assumed if anything keeping it as a constant would be faster. Another question: Why do $[#i:& XXX ; @[x;i;:[; YYY]]; x] when (if I'm not mistaken, which I could be) you can do @[x;i:& XXX;:[; YYY]] Performance again? A quick test using ngn/k did seem to find the first one faster, but only margi…

That's a harder question. Why do other people do the things they do? One reason might be because it was convenient for them to write (and debug) things that way. But it is possible they are doing it for performance reasons, so maybe it's worth considering why it should be faster? That is to say, should the programmer assume the latter is faster than the former? To do that, I would suggest putting yourself in the shoe…

Ok, that all makes sense, thank you.

And thanks for pointing out the pattern in the first place, it makes sense now how you were able to parse the original expression so quickly.

Re: The Array Cast – A podcast about the array programming languages

#129

Post by rak1507 »

geocar wrote: post #126
rak1507 wrote: post #125

Earlier quoted context omitted.

Ah, ⍷, clever, don't even need the outer {...⍵}, us←'_'@{¯1⌽⍵⍷⍨(⊂⊃K),'*'}

Yes! You could also do: ⌽'*',⊂⊃K to save another character. I don't know if that's "better" though.

Or alternatively '*',⍨⊂⊃K which I think I prefer over ⌽, but neither seem that 'better' in my mind anyway.

Re: The Array Cast – A podcast about the array programming languages

#130

Post by jiggawatts »

rscho wrote: post #102
jiggawatts wrote: post #98

Earlier quoted context omitted.

It's the essence of the thing in this case, and isn't a shallow criticism. Syntax can be good or bad. I don't believe that it's just a matter of "getting used to it", there are objective metrics of readability, developer error rates, and speed of training that some languages do poorly at. My point was that most array languages look like line noise. That's flippant, but true . Ask yourself this question: Is it possibl…

Geocar put in the effort of trying to make you see. But you are prejudiced with the equivalent of those who spite Lisp because of parentheses. If you want a "more readable" array language, take a look at Nial. PS: qualifying the Wolfram language (Mathematica) as obscure is a really, really myopic view of the programming world.

I've never seen anyone use Mathematica outside of academia other than myself. It also occupies a slightly unique corner of the language design landscape. One that I like!

I wish that Mathematica was modernised and made into a proper, compiled (or at least JIT-ed), heavyweight language with all the trimmings. A proper IDE, debugger, tracing tools, etc... The current version is a bit like Visual Basic -- a very old language that had grown past its original design capabilities and now needs a revamp. A bit like how VB.NET replaced VB, and was superseded in practice by C# on dotnet core.

Post reply on HN