The APL Orchard

ngn

12:03 AM

"many" :)

user41805

5:02 AM

@nathanrogers 23b, but not trying to golf this any further, {0≠(⌽⍉+0 1⍷⍉)⍣4⍣≡1@⍺-⍵}

if the point is on a wall, the wall will be assumed to be a non-wall

@ngn there's a weechat client (but haven't tried it yet myself) matrix.org/docs/projects/client/weechat-matrix

@user41805 okay i lied, 22b, {|(⌽⍉+0 1⍷⍉)⍣4⍣≡1@⍺-⍵}

ngn

@user41805 -2 if you remove { } and replace ⍺ ⍵ with ⎕s

nathan rogers

5:30 AM

@user41805 don't lie

ngn

5:47 AM

@user41805 that's got some not-so-wee dependencies - pip, many python libs, a rust compiler..

the rust compiler is still doing something. i'll give up.

LdBeth

6:59 AM

I'm still confused on how ⎕IO works in dfns

Adám

@LdBeth How so?

Any dfn that doesn't set its own ⎕IO inherits the ⎕IO value from where the dfn was defined.

LdBeth

Seems it is does not have effect modifying it inside { }

Adám

All normal assignments in dfns are local to that dfn (and the dfns it defines).

Julian Fondren

(⍳,{⎕io←0⋄⍳⍵},⍳)3

output: 1 2 3 0 1 2 1 2 3

Bubbler

It is expected behavior, assuming global ⎕IO is 1

LdBeth

7:04 AM

Well, I guess I actually don't know how a∘←0works in general

Adám

@LdBeth Please don't use that at all.

It is a bug, not supported syntax.

ngn

⎕io⊢←.. ?

Adám

@ngn Yes, that's fine.

LdBeth

because mutable variable is considered evil?

Adám

No, because it is an unsupported bug.

ngn

7:06 AM

@LdBeth modified assignment prefers to modify existing variables over creating new

Adám

If you want to create a new (semi-)global variable from within a dfn (although a questionable thing to do) you can use ⎕THIS.varname←value (or any other namespace).

LdBeth

ah, so it potentially pollute the workspace

Adám

Yes.

LdBeth

ah, so it potentially pollute the workspace

@Adám learned a new thing

Julian Fondren

⎕io←1⋄(⍳,{⎕THIS.⎕io←0⋄⍳⍵},⍳)1 → 0 0 1

Adám

7:10 AM

@LdBeth Good, that's what I'm here for :-)

ngn

7:21 AM

puzzle: why does (⍳3) ⊣ ⌷io←0 evaluate to 1 2 3?

Adám

@ngn Because the default ⎕io is 1.

Bubbler

@ngn Because you made a typo

ngn

technically correct (both) :)

Adám

underhanded

@ngn Best type of correct.

In most fonts, ⌷ and ⎕ are distinguishable enough.

⌷ is both taller (it is supposed to extend above ascenders and below descenders, like [ and ], while ⎕ sits on the line and reaches only high enough that vertically centred symbols like ÷ are in its centre) and narrower (⎕ is supposed to have the golden proportions).

ngn

right. i was hoping to fool at least someone with less apl experience.

LdBeth

7:27 AM

is ⌷ created by overstrike [ & ]?

Elias Mårtenson

@LdBeth I believe it was, back in the day.

ngn

when overstrikes were a thing

Adám

@LdBeth Try ⎕FMT'[',(⎕UCS 8),']'

ngn

this gives me an idea for a whole new category of jokes :)

"nothing" jokes -> "backspace" jokes -> "⎉erﬆrike" jokes

LdBeth

wow, so ⎕TC[1] would do the same

Adám

7:33 AM

@LdBeth That's just an archaic constant that contains the same character.

CMC: Table of valid overstrikes. That is, a matrix with one row and column per character that can form an overstrike, all-spaces, except at indices of valid overstrikes where it should have the overstrike.

LdBeth

haven't tried format function much before, thought that was for spreadsheeting

LdBeth

7:51 AM

@Adám {V[⍸A(=⍤0 1)V←∘.{⊃⎕FMT ⍵,(⎕TC[1]),⍺}⍨A]←' '⋄V} a bad attempt here

update {V[⍸A(=⍤0 1)V←∘.{⊃⎕FMT ⍵,(⎕TC[1]),⍺}⍨A]←' '⋄(' ',A)⍪A,V}

I don't know how to get those "basic" APL characters other than from ⎕AV

Adám

@LdBeth This doesn't look right. A←⎕AV?

LdBeth

@Adám A←⎕AV[155+⍳30]

But that doesn't cover all the characters I guess

Adám

8:08 AM

Right. Also, there are valid non-APL overstrikes, e.g. S with | gives $.

LdBeth

And A-Z overstrikes _

Adám

Yup.

I think there are no overstrikes involving characters above ⎕UCS 1E4

Bubbler

      w/⍨2(~⊃∊↑)¨w←,∘.{,⎕FMT⍺⍵⍺(⎕UCS 8)⍵}⍨v←⎕AV~⎕UCS⍳32
 '.!  '⎕⍞  ⍺_⍶  ⍵_⍹  _⍺⍶  _⍵⍹  _∆⍙  _AⒶ  _BⒷ  _CⒸ  _DⒹ  _EⒺ  _FⒻ  _GⒼ  _HⒽ  _IⒾ  _JⒿ  _KⓀ  _LⓁ  _MⓂ  _NⓃ  _OⓄ  _PⓅ  _QⓆ  _RⓇ  _SⓈ  _TⓉ  _UⓊ  _VⓋ  _WⓌ  _XⓍ  _YⓎ  _ZⓏ  _=≡  _≠≢  _∊⍷  _⍳⍸  _⊂⊆  .'!  0~⍬  ∆_⍙  ∆|⍋  A_Ⓐ  B_Ⓑ  C_Ⓒ  D_Ⓓ  E_Ⓔ  E-€  F_Ⓕ  G_Ⓖ  H_Ⓗ  I_Ⓘ  J_Ⓙ  K_Ⓚ  L_Ⓛ  L-£  M_Ⓜ  N_Ⓝ  O_Ⓞ  P_Ⓟ  Q_Ⓠ  R_Ⓡ  S_Ⓢ  S|$  T_Ⓣ  U_Ⓤ  V_Ⓥ  W_Ⓦ  X_Ⓧ  Y_Ⓨ  Z_Ⓩ  ¨~⍨  ¨*⍣  ¨∇⍢  ¨∘⍤  [∘{  []⌷  /-⌿  \-⍀  \○⍉  <>⋄  =_≡  =⎕⌸  ><⋄  ≠_≢  ∨∧⋄  ∨~⍱  ∧∨⋄  ∧~⍲  -E€  -L£  -/⌿  -\⍀  -○⊖  -(⊢  -|ɫ  -,⍪  -)⊣  ÷⎕⌹  ∊_⍷  ~0⍬  ~¨⍨  ~∨⍱  ~∧⍲  ~∇⍫  ⍳_⍸  ○\⍉  ○-⊖  …

Assumes there's no overstrikes outside ⎕AV

@Adám A table of 10000x10000 is too much I guess though

ngn

that's <1GB

Adám

@Bubbler I just did it using less than 1GB

Bubbler

8:19 AM

@Adám Is the result different from mine?

Adám

Looks about the same. hard to tell, as mine is in UCS order.

-|ɫ looks like a mistake. I've long held that that was an encoding mistake and that the implementers had ⍭ in mind but accidentally put ɫ into ⎕AV (and apparently the overstrike table too). Though, why - and not ~‽

LdBeth

I think the perfect A is then '⍺⍵_.0∆ABCDEFGHIJKLMNOPQRSTUVWXYZ¨[/\<=>≠∨∧-÷∊~⍳○*∇∘(⊂∩⊥⊤|,:)]⎕

Adám

@LdBeth Are you not missing a character? My table is 64×64.

@LdBeth Missing ⋄, no?

LdBeth

Dimond is <+>, so not included

Adám

But then you lose ⋄+⎕→⌺

I think ⋄ is unique in being able to both be formed by and form overstrikes.

LdBeth

8:40 AM

⎕FMT '<',B,'>',(B←⎕TC[1]),'⎕' gives ⌺, I trend to count ⌺formed by overstrike 3 chars.

Adám

The overstrikes in Dyalog are clearly biased. Lots of obvious but missing ones, and a few odd ones.

LdBeth

@Adám What I feel more strange is that ` ⎕FMT '-',(⎕TC[1]),':'` doesn't produce ÷ :D

Adám

@LdBeth Yeah, that's what I mean. Dyalog APL never ran on typerwriter terminals, so that wasn't needed. You could indeed create ÷ from - and : in the old days. You could even create E from F and L.

rak1507

9:52 AM

@user41805 wow that's incredible

rak1507

10:27 AM

is there any way to fix inline assignment not working in dyalog extended?

Adám

@rak1507 It usually happens because the next token on the left is an extended primitive. Add ⊢ on the left of the assignment.

I now know how to fix it, but it is hardly worth it when TIO cannot be updated.

rak1507

yeah, shame :( thanks

Adám

Does anyone other than me use Extended locally?

rak1507

it's annoying because I'm not using any extended features but ⍥ doesn't exist in classic or unicode

I don't personally

Adám

@rak1507 I just polyfill ⍥ and ⍤ and ⎕C

rak1507

10:32 AM

Ah

Adám

@rak1507 Ö←{(⍵⍵ ⍺)⍺⍺(⍵⍵ ⍵)} ⋄ ö←{⍺⍺ ⍺ ⍵⍵ ⍵} ⋄ ∆C←{⍺←0 ⋄ ⍵(819⌶)⍨0⌈⍺}

rak1507

thanks

Adám

Also Z←⍳∘≢∊⍳⍨ for ≠

The extensions of ⍸ and ⊂ are tougher, and ⎕DT is almost impossible except for very specific and limited cases.

Elias Mårtenson

The binary operation for ≠ is XOR. But does = have a name?

rak1507

xnor

Elias Mårtenson

10:39 AM

Sounds a lot better than EQV that Common Lisp uses. Thanks.

Adám

I hate the name "XNOR". It is really NXOR, only that that isn't very pronounceable.

@EliasMårtenson Nice table here, though it is missing 5 entries.

Why isn't ← called CIMPLY and ↚ called CNIMPLY?

Elias Mårtenson

@Adám Well, I use the bitwise operator (∵), so I use ∨, ∧, ⍲, ⍱, ×, +, -, ≠ × (the last three being aliases for xor)

rak1507

having a bitwise operator is great

how are × and - aliases for xor?

Elias Mårtenson

Common Lisp has the full table here: clhs.lisp.se/Body/f_boole.htm

rak1507

× is and if anything, and - just doesn't make sense

Elias Mårtenson

10:45 AM

But I have never seen the need for ORC1 or ORC2, and I don't know what base APL functions to use for them.

Adám

@EliasMårtenson What are ORC1 and ORC2?

Elias Mårtenson

@rak1507 + and - are both xor.

rak1507

@EliasMårtenson they don't look very useful to me

@EliasMårtenson oh, are you doing it mod 2? I guess that makes sense...

Adám

Ah they are ~⍛∨ and ∨∘~

Elias Mårtenson

@rak1507 Yes, in those cases I am.

Adám

10:48 AM

@EliasMårtenson 0∵ and 1∵ make sense too.

@EliasMårtenson Same problem with ANDC1 and ANDC2, no?

rak1507

I don't think they're unique enough to warrant their own things, stuff like that where it's simple to make from composition can just be ignored imo anyway

Adám

@EliasMårtenson Any issue with using non-primitive functions as operands for ∵?

Elias Mårtenson

@Adám It would, if it wasn't for the fact that the parser has a limitation in that all operators must take a function on the left.

Adám

@EliasMårtenson So no 'a'@4?

And no 'abc'⍨?

Elias Mårtenson

@Adám Well... It could be done.

@Adám Correct. That syntax is not allowed. The reason is that the parser needs to figure out whether or not to parse a symbol as a function or operator with only one token lookahead.

So in that particular case, it could be done. But what if the symbol is both an operator and a function?

Adám

10:52 AM

@EliasMårtenson In fact, I'd say ∵ should be a general operator that allows the user to supply any function and simply applies it between the bit-representations of the arguments, and then converts the bits back. Similar to ⍢⊤

Elias Mårtenson

@Adám Conceptually, yes. It needs to do special things though.

Consider ⌽∵

Adám

Why?

Elias Mårtenson

@Adám Well, what should ⌽∵ 1 0 return?

rak1507

nothing, I don't think that makes any conceptual sense

Adám

@EliasMårtenson {×⎕NC'⍺':(⎕DR↑⍺⍵)⎕DR⍺⍺⌿↑11⎕DR¨⍺⍵ ⋄ (⎕DR⍵)⎕DR⍺⍺11⎕DR⍵}

Elias Mårtenson

10:58 AM

Well, in the current prototype it returns (2*63) 0

Adám

Actually {×⎕NC'⍺':(⎕DR↑⍺⍵)⎕DR⍺⍺⌿⌽↑⌽¨11⎕DR¨⍺⍵ ⋄ (⎕DR⍵)⎕DR⍺⍺11⎕DR⍵} might be better.

Elias Mårtenson

I don't know what ⎕DR does.

Adám

Reports and converts Data Representation.

{×⎕NC'⍺':(⎕DR↑⍺⍵)⎕DR 2|⍺⍺⌿⌽↑⌽¨11⎕DR¨⍺⍵ ⋄ (⎕DR⍵)⎕DR 2|⍺⍺11⎕DR⍵} if you want to be tolerant.

rak1507

(meant for TNB)

Adám

      _B←{×⎕NC'⍺':(⎕DR↑⍺⍵)⎕DR 2|⍺⍺⌿⌽↑⌽¨11⎕DR¨⍺⍵ ⋄ (⎕DR⍵)⎕DR 2|⍺⍺11⎕DR⍵}
      ⌽_B 100
38
      17∨_B 4
21
      ⌽_B 1 0
0 1

There may be some issues with higher rank arguments, but this is pretty close, I think.

Elias Mårtenson

11:01 AM

@Adám OK, I don't understand the logic there. With a single argument, I'd expect ⌽_B 1 to return 2*63

Adám

@EliasMårtenson Depends on what 1 is, no? Why specifically use 64 bits for it?

That's the problem with this sort of operator. You'd have to specify the bit-width of the given argument(s).

Elias Mårtenson

@Adám True. But in my case, a machine integer is specified to be 64 bit. Perhaps that's bad design and I'm willing to reconsider that.

Note that 2*63 is differerent from 2*63.0

Integer maths rules are similar to those of Java

Adám

Why not take a right operand that specifies the bit width? I'd think that working on 8-bit integers would be a fairly common one.

Elias Mårtenson

(not C, as C's overflow semantics for signed ints are undefined)

@Adám Because if you want to work on 8-bit units you can just use 255∧∵

The reason for this has to do with the fact that a 64-bit int is the smallest individual unit you can work with. It doesn't, like Dyalog, have dedicated 8-bit integer units with automatic conversion.

All integers are 64-bit.

Well... Not strictly true, as there is a special 32-bit unit but it's never exposed, and is only there for certain optimised operations working with array indexes, which are always 32-bit.

Adám

I think {b←⍵⍵⍴2 ⋄ ⍺←⊢ ⋄ b⊥⍺ ⍺⍺⍥(b∘⊤)⍵} is most general and easiest to understand:

      _B_←{b←⍵⍵⍴2 ⋄ ⍺←⊢ ⋄ b⊥⍺ ⍺⍺⍥(b∘⊤)⍵}
      ⌽ _B_ 64 ⊢ 1
9.223372037E18
      ⌽ _B_ 8 ⊢ 1
128
      ⊖_B_ 8 ⊢ 100
38
      17∨_B_ 8 ⊢ 4
21
      ⊖_B_ 1 ⊢ 1 0
1 0

Elias Mårtenson

11:11 AM

But yes. I could adopt the Common Lisp semantics with unsized binary operations, but then I'd need something like CL's LDB and DPB.

dzaima

@Adám CIMPLY and NCIMPLY :P

Adám

Your current ∵ seems awfully machine and implementation specific. Not a very APLy thing.

Elias Mårtenson

@Adám Yes it is.

dzaima

@Adám i mean, bitwise stuff is pretty specific and not APLy

Adám

@EliasMårtenson Such things are usually made into quad-names or I-beams.

dzaima

11:13 AM

@Adám but that's ugly

Adám

@dzaima But how to pronounce NCIMPLY (and NXOR)…

Elias Mårtenson

The eason is that I have been thinking about bitwise operations in terms of low-level bit-fiddling and not as part of general APL operations.

dzaima

@Adám i know, i was making a joke about that

Adám

@EliasMårtenson Yeah, I find it extremely rare to actually need this in everyday APL programming.

dzaima

@dzaima even having ∧⎕B is 3x longer than the equivalent in most other langs, and specifying 32 or 64 somewhere too makes it unusable without custom definitions

Adám

11:14 AM

@dzaima Ah, I was somewhat suspecting that. Knimmpleye works…

rak1507

@Adám it's no rarer than matrix inversion

dzaima

@Adám I actually find myself falling back to prototyping things in JS quite often for binary stuff, which i encounter quite frequently

Elias Mårtenson

@Adám I understand that. But one of the things I'm trying to achieve (although I have no idea if I'll succeed) is to make non-APL-style (or "imperative style", or "pascal style" if you like) natural in Kap.

dzaima

(I definitely use binary ops a couple orders of magnitude more often than matrix inversion/division/addition)

Elias Mårtenson

In other words, it should be just as easy to write a solution with a while loop and iteration as it is to do it using an APL expression.

(now, the APL expression is terser and usually around 10 to 100 times faster, but it will work)

rak1507

11:16 AM

@dzaima same but python/c++

dzaima

@rak1507 python is understandable, but c++?

Elias Mårtenson

JS for binary stuff sounds a bit painful given that the language doesn't have a clear integer type.

I do it in Common Lisp.

Although I want to use Kap for it :-)

rak1507

@dzaima speed

dzaima

@EliasMårtenson JS binary stuff is always effectively 32-bit (and there are bigints when there's a need for that)

Elias Mårtenson

@rak1507 Why not CL then?

rak1507

11:18 AM

@EliasMårtenson because I don't know it

also it's probably hard to do imperative stuff

Elias Mårtenson

@rak1507 Yeah, that was just my personal dislike for C++ talking.

rak1507

fair enough, I don't like it either

dzaima

@rak1507 2x-10x slowdown for temporary prototypes is acceptable imo. unless you mean for more serious prototypes

rak1507

@dzaima me and a few people were trying to do something the fastest possible way so clearly the only way to do that was to reimplement the mersenne twister in c++...

Elias Mårtenson

@rak1507 In CL? Not really. CL is a multiparadigm language, and usually the imperative approach is the proper way there. Which is why CL is often the target of complaints from functional people. It's not "functional enough". It is, however, very fast, and the only language I know of that has both interactive REPL-based development as well as native compilation with C-like performance.

dzaima

11:20 AM

@rak1507 ah okay

rak1507

@EliasMårtenson that's a pretty good sales pitch you've got there, I'm convinced! will give it a try at some point in the future maybe

Elias Mårtenson

@rak1507 Thanks. :-)

Anyway, I wrote a blog post once showing the what native code generation looks like in CL. Perhaps it's interesting to someone who has just looked at CL superficially: write.as/loke/common-lisp-code-optimisation

rak1507

that's really cool how you can specify types and stuff to help with compilation

Elias Mårtenson

@rak1507 Yes. And it also support type inference, so you don't have to specify types. Only if you want maximum performance and the compiler isn't able to infer the actual type. I should probably have mentioned that in the post.

rak1507

I assumed that anyway

dzaima

11:27 AM

@EliasMårtenson if i wanted to work exclusively, say, with wrapping 32-bit ints, i assume i'd be able to define a custom addition function that handles that?

Elias Mårtenson

@dzaima In CL?

dzaima

@EliasMårtenson yeah

Elias Mårtenson

@dzaima Well, there is a function called DPB which allows you to manipulate a portion of an integer. It allows you to say "set bits 8 to 40 of this integer to the value 1234"

You can use that as the basis for your new number stuff, and then use the macro system to build a nice syntax on top of it.

It all depends on the requirements, but the tooling is there.

dzaima

but will it figure out to always stick to 32-bit integers in registers? (cause "C-like performance" is a pretty damn strong claim)

arbitrarily falling back to bigints (and everything needing to work with possibly bigint arguments) sounds pretty bad for performance

Elias Mårtenson

@dzaima It's a strong claim, and does come with some caveats of course (one is that you need type declarations). But the benchmarkgames site used to have Common Lisp solutions within a few percent of C in some cases.

And usually within 2x C runtimes.

@dzaima But yes, the optimiser is smart enough to stuff things into registers if they fit (which normally is integers up to 63 bits)

dzaima

11:33 AM

63 - oof

Elias Mårtenson

@dzaima It depends on the compiler. I'm talking about SBCL here. It uses 63-bit integers so that it doesn't have to box most values.

dzaima

lisp/sbcl and node seem similar in the benchmarks game, lisp being ahead by a bit most of the time. Both are pretty behind C

Elias Mårtenson

That allows linked operations on values which can be both pointers or numbers to be very fast.

@dzaima Which Lisp are you referring to? SBCL is an implementation of Lisp.

dzaima

@EliasMårtenson just the Lisp SBCL that's there

Elias Mårtenson

@dzaima Yeah, SBCL is generally the fastest. But the benchmarkgame disqualified some Lisp results.

dzaima

11:38 AM

(annoying that there isn't a page for every combination of languages)

@EliasMårtenson how so?

Elias Mårtenson

@dzaima Not sure. I haven't actually looked. It's hearsay.

But there used to be several results where it was within a few percent of C. But the code was not very nice. It was not idiomatic Lisp.

For fun, here's my optimised version of a simplex noise generator, ported from JS and added optimisations to make all the floating-point operations fast:

gist.github.com/lokedhs/…

That compiles to something at least resembling what you'd expect from a native static code generator. As you can see, you don't need that much declarations.

Anyway. Sorry for derailing the discussion in my usual fashion.

I'm off for now

LdBeth

12:00 PM

@EliasMårtenson hello

I bet most benchmarks on "obscure" languages are poorly written and not idiomatic.

dzaima

they certainly would be trying to go for max performance whatever the cost

LdBeth

So don't take these seriously, until there has been a noticeable magnitude of difference in production cases.

Adám

1:18 PM

CMC: Generate a random APL array :-)

That is, it has to have random rank, shape, depth(s), and type(s).

xpqz

1:37 PM

WS FULL

Adám

:-D

Wezl

2:05 PM

I'm glad we can at least discuss Common Lisp, if not K+BQN :)

Adám

@Wezl It was all in the context of using APL and implementing an APL or at least very-close-to-APL language.

Wezl

I disagree

this looks like the last message APL was mentioned

@dzaima thanks

nathan rogers

3:41 PM

@rak1507 No guaranteed Tail Call Optimization in the spec means that the general consensus is use the loop macro, not recursion. You can do general FP, but the main work that's done in CL is very imperative

@user41805 I tried your TIO, and it only works for the upper left corner. Specifying other input cells and you get bleed over the rest of the matrix

@user41805 actually disregard, you had a 1-⍨ in your board without specifying ⎕IO. No problem