The APL Orchard

00:30

@dzaima Well, there are things like mapAccumL that let you map and reduce at the same time, but it gets a bit awkward.

@rak1507 Booleans made by random choices with the given probabilities?

rak1507

yes, I probably worded it badly

Bubbler

APLwiki article for ⊥ has an APL model, but not for ⊤. I think the precise APL model for ⊤ has been discussed at some point here...

Original Original Original VI

@rak1507 ⊢>(?0⍴⍨≢)

Not sure exactly how ? works but ?0 appears to give outputs in the range [0, 1)

Bubbler

@OriginalOriginalOriginalVI That's correct

Original Original Original VI

@Bubbler Oh great

Does ?n give outputs in the range [0, n+1)?

Bubbler

00:43

No.

Original Original Original VI

@Bubbler Ah

I really should read the docs more often

Bubbler

If n is a positive integer, ?n picks a random integer from ⍳n. ?0 is a special case, which returns a random real number in [0,1)

Original Original Original VI

I see

rak1507

01:50

@OriginalOriginalOriginalVI can be golfed to ⊢>∘?≠⍨

Original Original Original VI

02:06

@rak1507 Nice

rak1507

in dyalog extended assuming non 0 probabilities it can be ?∘=⍛<⍨ which is fun

Elias Mårtenson

05:17

@MortenKromberg Fractional or complex, in fact. :-)

As for ⎕CT, I don't worry about that one since Kap doesn't have that.

Morten Kromberg

07:53

Functions like ⌊ quickly become "unusable for math" without ⎕CT, IMHO:

     ⌊+/10⍴0.1
0

rak1507

It's 1 for me

Morten Kromberg

Not if you have no ⎕CT. Try ⎕CT←0

rak1507

It's still 1 for me with ⎕CT←0

oh, ⎕FR←645

imo that's not a reason to use CT, it's a reason to not use floats

Morten Kromberg

Is this in Dyalog APL? If so, what is your ⎕FR? If you are using decimal arithmetic, that particular example is fine.

Bubbler

...unless you have a rational number built-in, or you're perfectly OK to adjust for the error margin manually

rak1507

07:56

floats are imprecise, and implementing hacky ways to try and make them seem more precise is bad

Morten Kromberg

Well, except then you don't have a useful notation for ordinary people to do financial math.

Elias Mårtenson

@rak1507 Exactly.

rak1507

@MortenKromberg rational numbers work fine

using floats for finance should be illegal

Elias Mårtenson

@MortenKromberg I don't agree. Sweeping floating point issues under the rug is worse than being explicit about it.

@rak1507 Floats for finance is fine. It's floats for currency computation that is bad.

rak1507

@EliasMårtenson Ah, I thought the second one fell under finance too

Elias Mårtenson

08:00

@rak1507 Currency computation is a subset of finance. A lot of finance doesn't deal with monetary amounts directly. It's perfectly reasonable to use floating point calculations when pricing an option using the Black Sholes algorithms, for example.

rak1507

@EliasMårtenson makes sense

Morten Kromberg

Yup, there are cases where floats are problematic. But I don't think ⎕CT "sweeps things under the rug"; the use is well defined and there are cases where you set it to 0 and do your own thing. But in general it seems to work well in practice, is all I can say.

rak1507

How much more complicated does the implementation have to be to allow for it though?

Morten Kromberg

If you want it to use ⎕CT and be fast, there is very significant work to do.

Elias Mårtenson

@MortenKromberg But it complicates the implementation. Conversely I wonder if there are any cases where its existence truly justifies this complication? What are the actual usecases where ⎕CT actually is beneficial (other than, in my words, sweeping precision issues under the rug)

In other words: When implementing the numerical operations in an APL, are these suggested benefits of ⎕CT big enough to justify the implementation complexity?

Morten Kromberg

08:05

That is a difficult question for me to answer in that all the applications that I have worked on in 40 years have worked well with ⎕CT, and you "obviuosly" don't want (0=⌊+/10⍴0.1). My gut feeling / experience is that just about everything breaks quickly without it. Sorry I cannot be more precise. You would immediately be implementing your own delta-fuzz all over the place and make many more mistakes than if you just let the interpreter get on with it.

Elias Mårtenson

What is probably actually needed is interval arithmetic.

rak1507

@MortenKromberg with a rational data type there would be no need for implementing things like that

Morten Kromberg

No, but the performance of rats both in terms of CPU and memory is 1) bad 2) unbounded and unpredictable. And as soon as you used * you would be in trouble again.

Elias Mårtenson

@rak1507 Right. That was my thought as well. The value 0.1 actually means 0.1 plus/minus some tiny epsilon.

Bubbler

Time to give attention to limited-precision rats again

rak1507

08:10

@MortenKromberg the performance of floats is already made worse by CT, so it's not as if there's no tradeoff between accuracy and speed

Morten Kromberg

The answer of the early APL implementors was ⎕CT, and it has held up pretty well as a practical solution for hiding the problems caused by floats for 50 years, allowing nearly everyone to forget about the issue. Of course, there are cases where you need to take care.

@rak1507 Indeed. But the ⎕CT trade-off between accuracy, speed AND very importantly the difficult or writing and debugging code has been shown to be an extremely good one over half a century of use.

rak1507

Fair enough

Elias Mårtenson

@MortenKromberg In what way would you be in trouble?

rak1507

* has irrational results

Morten Kromberg

The whole point about a good notation is handing over issues like this to the language implementors. Without ⎕CT in the language, you would have to make your own decisions for every primitive function whether some kind of error needed to be allowed. The likelihood that you would get it wrong, or that the additional burden would make you make other mistakes, would be much higher.

rak1507

08:16

⎕CT is more than an implementation detail, and the user does have to choose what ⎕CT to use, along with ⎕IO, ⎕ML, ⎕FR, etc.

Morten Kromberg

In theory yes, in practice most real users never change ANY of those values other than in exceptional circumstances.

rak1507

Most users use ⎕ML 1 exclusively?

Elias Mårtenson

I thought a lot of people set ⎕IO to 0? At least that what people here seem to do.

Morten Kromberg

Unfortunately the user community is split about 50:50 between people who started using Dyalog APL as their first APL and use ML=1, and people who migrated to Dyalog APL from other APL interpreters and typically use 3.

@EliasMårtenson Yes, my point is that people don't usually change these values a lot, they decide where they want to stand and stay there. ⎕CT is VERY rarely modified, I have only really seen it done by people who want to do stuff like memoisation and want lookups to be really fast on floats, so they set ⎕CT=0.

Elias Mårtenson

Speaking of older APL's. Wasn't there a version of APL for MVS? I have 70's version of MVS running on Hercules on my machine, and getting APL running on it would be really neat.

I wonder if it's possible to get one's hands on a copy of that.

Morten Kromberg

08:21

I'm afraid I don't know what is available now. But many IBM APLs, SHARP APL and APL*PLUS were all available.

rak1507

@MortenKromberg in Jarvis, ⎕IO is set to 1 thrice, and 0 twice

Elias Mårtenson

@MortenKromberg I want to find a copy of the really old one. From the early 70's or even 60's.

I wonder if IBM would share it if I asked.

rak1507

actually, my grep didn't pick it all up, ⎕IO is set to 1 five times, and 0 three times

Elias Mårtenson

@rak1507 What is jarvis?

rak1507

github.com/Dyalog/Jarvis

Morten Kromberg

08:29

A tool like Jarvis (our "ultralight" web service framework), that need to be loadable into ANY client environment, needs to set ⎕IO and ⎕ML. ⎕IO is often set to zero locally because there are certain types of algorithms that work better. But I think you will struggle to find many instances of code that sets ⎕CT.

rak1507

yeah, 0 instances of ⎕CT, but my point is that people don't just pick one and stick with it

Morten Kromberg

I think it is fair to say that "people" generally do, except for the occasional ⎕IO setting. Tool builders need to protect themselves. Anyway, I'm not saying any of this is good, we'd be better off without the switches (except, IMHO, ⎕CT :)).

Without ⎕CT, you'd just have to implement it yourself.

Any you always have the option of setting ⎕CT←0 and implementing your own logic.

rak1507

true, ⎕CT is definitely the least bad

Morten Kromberg

I've also met people who exclaimed "wow, APL allows you to set index origin! that's the coolest thing!" :D

rak1507

just wait and see if they find it so cool once they waste an hour wondering why their ⎕IO←x algorithm doesn't work when they're using ⎕IO←y! :D

~~definitely hasn't happened to me before~~

Morten Kromberg

08:35

The worst by far is ⎕ML, due to that unfortunate accident when IBM changed their minds in the last few months before the release of APL2.

rak1507

@MortenKromberg yeah, having to maintain separate implementations of the same language or primitives sounds like a total pain

Morten Kromberg

Actually the implementation is mostly trivial, in that it is just the spelling that differs in ↑ vs ⊃. And now we have the IBM partition in all ⎕ML's as ⊆. I'm still hopeful we will effectively eliminate ⎕ML in my life time.

rak1507

that would be great

ngn

09:31

i'm surprised the problem with ='s transitivity hasn't been mentioned yet

rak1507

more of a theoretical issue than a practical one

a=b and b=c should mean a=c but it's not really like you lose too much from the rare occasion that doesn't hold

Elias Mårtenson

09:58

@rak1507 When doesn't it hold? Because of ⎕CT?

rak1507

yep

Elias Mårtenson

Well, you shouldn't do = on floats anyway :-)

Morten Kromberg

keiapl.org/anec/#fuzz

ngn

but usually carpenters don't earn billions

no transitivity => can't group things into equivalence classes => monadc U is impossible to implement correctly

Morten Kromberg

@ngn quite a few people who put their faith in ⎕CT did end up building very large businesses. Carpentry is not the only craft where measurements have limited precision.

Even in the case of ∪, the results are likely to be "more useful" (and might actually be right) with ⎕CT in a real application, although anyone who does ⍳ or ∪ on floats is skating on very thin ice, no matter how you define it.

ngn

10:20

they cannot not use floats, if floats are the only choice

1e14=1e14+1 is ironic :)

Morten Kromberg

@ngn My ideal array language would absolutely include both "rats" and "variable precision floats", but the performance differences are so huge even today that people will probably continue to choose floats for many things, especially if the combination of floats + tolerant comparison means they can forget about the problem nearly all the time.

ngn

i'm not arguing for rats, btw. just for floats with strict = and possibly a separate tolerant ≈

Morten Kromberg

My take on that is that, given that floats are the bread and butter of most calculations, you want tolerant = nearly all the time, so it is easier just to localise ⎕CT←0 in the extremely rare cases when you need comparisons to be exact.

Apropos nothing: as work winds down on Dyalog v18.1, I'm reviewing the road map for v19.0 and beyond today. Anyone want to shout something out for the todo list?

Julian Fondren

10:41

@ngn I thought of looking for a way to get that with ⍠ , since that's what J does, but this works: {⎕ct←0⋄⍺=⍵}

rak1507

@MortenKromberg Aside from the obvious things like scripting, package management, etc, I think it'd be great if there was a license update to make dyalog APL free for open source usage, it might encourage people to use it (or at least not discourage them), and I doubt it'd cost dyalog any revenue

Morten Kromberg

@JulianFondren There is a proposal to define =⍠0 to mean exact comparison. Another mechanism you can use in Dyalog APL is to define a namespace ct0 with ct0.⎕CT←0, and then you can (X ct0.= Y) or (ct0.∪ X).

rak1507

I think it'd be really nice if you could do =⍢(⎕CT:0) using under and array notation

Morten Kromberg

@rak1507 Thanks! Completing work on scripting is at the top of the v19.0 todo list.
Package management is something we are spending significant time thinking about but will probably run parallel to work on the interpreter, unless we discover that we need some new language mechanism to bring ⎕PATH/⎕USING together to make package references easier.

Re open source usage: Dyalog APL is already free to use if you are not making money with it. Can you explain more about what you would like to see?

rak1507

@MortenKromberg free for open source commercial use too, I think that's what some things do, but I could be wrong

Morten Kromberg

10:53

The reason why we haven't done more about making it easier to do intolerant comparisons is that there are so few real uses for it, which means that the existing mechanisms are really all that you need. If you want to do anything intolerant in your code, it is something that SHOULD be a bit awkward and shouty to attract attention to the fact that you are doing something quite extraordinary.

@rak1507 What sort of licence would be appropriate for that use, in your opinion - something really viral? And... if people feel strongly about creating open source software, would they build it on a closed source (but free) APL interpreter?

rak1507

Another thing is in the BAA meetings people always mention trying to get APL into schools, so I've been trying to think of some way that could be possible. Not had any ideas yet, but I think it would need to be something APL could do that nothing else could, and probably a very 'user friendly' (idiot proof) UI

@MortenKromberg yeah, good point, I know personally if I did anything 'commercial' I'd probably not use APL for it even if it was suited for it currently, but I might if the licensing was less annoying, but I don't do anything commercial so everything I say should probably be ignored

Morten Kromberg

11:09

Getting into education and training is something we are always thinking about and gradually gearing up to do more about, which is the reason for some of our recent hires. Unfortunately, the way most educational institutions work these days I think you need something that fits exactly into their curriculum and does not require teachers to do any extra work or take any risks, so this will be a long slog. Fortunately, we are used to long slogs (or we would not be here).

@rak1507 Thanks!

dzaima

@ngn as often is with floats, you can't really strictly use logic to think about them. whatever impl of ∪ one comes up with will probably be fine. I'd of course prefer if = and ≠ would be the only builtins that would use ⎕CT (if not the whole separate ≈), but as-is it's still usable

rak1507

@MortenKromberg having been not allowed to do a competition I really wanted to do, 'does not require teachers to do any extra work' definitely seems true

Morten Kromberg

@dzaima IMHO a language in which = and ≠ were tolerant but all the primitives that are effectively defined in terms of = are not, would be rather unpleasant. On a daily practical basis, I think one of the most important dependencies on ⎕CT is a function like ⌊.

dzaima

@MortenKromberg oh right, forgot about ⌊. Yeah, that's a pretty important one

Morten Kromberg

Imagine trying to do you own rounding, dividing by 10 and adding 0.5 and doing floor, without tolerant floor (well, you could just reinvent tolerant comparison and do it yourself, of course :)).

ngn

11:55

@MortenKromberg "rare cases when you need comparisons to be exact" - i always want them to be exact

if i want to check if two fp values are close, i'll do it explicitly - in my experience that is rare

i think ints are ok for most practical applications. you almost always know what the scale you're operating on is and how many digits of precision you need.

dzaima

ints often are okay, but it's an additional (very big) hassle

ngn

@dzaima how are ints more of a hassle than fp?

ints are simpler and behave predictably

dzaima

@ngn fp with ⎕CT usually "just works". ints with proper scaling require you to be absolutely sure about your scale and work by it everywhere

ngn

not necessarily "absolutely" sure. 2^64 is almost 10^20. that's a lot of tolerance for the scale.

if you're not sure whether your app will be dealing with cents or billions of billions of $, it may be too general :)

dzaima

that may change through the course of time though. and updating everything to use a new scale could be pretty annoying

ngn

12:05

even carpenters (to the best of my knowledge) don't care about lengths <1mm or >10m. that's only about four orders of magnitude - it could fit in a 16bit short int

dzaima

also fixed-point isn't safe from weird behavior too - (n÷1e5)×1e5 loses 5 digits of precision

whereas with floats that'd lose maybe a ulp or two

ngn

@dzaima not if you measure in units of 1e-5 or smaller

Morten Kromberg

@ngn I seems to me that you and I have very different requirements for programming languages and environments. When using APL, you should run with ⎕CT←0. In my case, the default setting has generally served me very well, but I will admit that I have set ⎕CT to 0 about once or twice a decade.

dzaima

@ngn no? division on fixed point always loses information

ngn

@dzaima same can be said about addition/subtraction on fp

dzaima

12:14

@ngn well yeah, i'm just saying fp isn't alone on things potentially losing a lot of precision on specific operations

xpqz

12:46

@Adám I've written the blog post (it's currently a notebook, but can export to something else if you prefer). How is it best for you to review?

LdBeth

13:25

hi guys, are there any APL idioms prints a checkboard for board games such as chess?

Morten Kromberg

' ⎕'[2|∘.+⍨⍳8] ⍝ ⎕IO←0

{(⍳⍵)⌽⍤0 1⊢⍵⍴' ⎕'} 8

ngn

shorter :) 1↓⍉8 9⍴'⎕ '

Morten Kromberg

@ngn nice

The first expression is commonly used as an exercise in reading APL during introductory courses

LdBeth

@ngn learned how to avoid '⎕ ⎕', thank you

ngn

↑8,/15⍴' ⎕' ⍝not shorter but i think worth mentioning

Morten Kromberg

13:37

@Ldbeth so now you have the first half of the problem solved, now you just need to write code to play chess :D

LdBeth

It's not chess, en.wikipedia.org/wiki/Senet

not as hard as chess, probably not even need to use dfs for a decent AI

Morten Kromberg

Too bad, can't find Senet pieces in Unicode yet...

⎕UCS 9800+20 22 21 19 18 21 22 20
♜♞♝♛♚♝♞♜

LdBeth

it's just fine to use ○ ⍟, although there're special marks required

Elias Mårtenson

14:01

Oh, encode and decode is working. Kinda.

@MortenKromberg thank you for your help.

Here's the commit: github.com/lokedhs/array/commit/…

If anyone want to test the behaviour, it would be appreciated: kapdemo.dhsdevelopments.com

dzaima

2⊤5 is an error. it's 2|5 in the "proper APLs" I know, but that's not exactly useful, so Extended and dzaima/APL make it be 2(⊥⍣¯1)5 aka decode with as many digits needed, giving 1 0 1

Elias Mårtenson

Ah yes. Try (,2) ⊤ 5

It's a known bug. I have a failing test on it in fact.

dzaima

@EliasMårtenson shouldn't that give ,1 and not just 1?

Elias Mårtenson

Yes. Doesn't it?

Ouch. You're right.

Thanks. That's indeed a bug.

dzaima

also 2 2 2⊥3 5⍴1 is a thing that is implemented in Dyalog (and dzaima/APL too)

(test: 2 2 2{⍵≡⍺⊥⍺⊤⍵}⍳8)

Elias Mårtenson

16:16

@dzaima Thank you.

Although that one is known. Multi-dimensional decode is not implemented.

Transcript for