There's an on-going discussion on adding J to Codewars, which is a competitive programming site and runs each submitted solution against some test cases in its own server.

Currently it is stuck at "needs a unit test framework" though.

BF has a unit test framework‽

Unit tests for BF are written in JS, with an API exposed for calling the submitted BF program.

There are many other languages on Codewars which use custom testing frameworks, e.g. Fortran, Factor, and even Coq.

CMQ: Does anyone know how to convert any (possibly boxed) array to its boxed representation (simple char matrix) in J?

Does anyone know if upong ⎕load'ing a workspace, Test becomes a reserved word or smth like that? It doesn't show up in my )vars, but typing Test gives me some weird error regarding metafiles not being found

@Bubbler Nevermind, ": always gives a char matrix for boxed array, so I guess I can work around simple arrays

@RGS There are not reserved words in a clear workspace. What does ⎕NC⊂'Test' give?

@Adám 3.1

@RGS That's a tradfn. Try )ed Test

@Adám that does show the tradfn; it looks like something related to leafpro or smth like that

leafpro may have been "loaded" into the workspace I ⎕load'ed, I'm not sure.

@Adám ah do you mean tradfns don't show up in )vars?

@RGS Right. They are not variables. Try )fns

@Adám yup, shows up there... that does clear some of the mystery, thanks

@Adám should I keep track of further typos I find in the book?

@RGS Sure.

what is the recommended -style for ]boxing? all my APL life I lived with the min style set without knowing I could change it; is it recommended to have it set to mid/max?

@RGS depends on the recommender

@RGS for me it depends on the situation. i usually have it on min but might occasionally switch to mid (max is way too much useless stuff for me)

@RGS I personally dislike the noise and verbosity of the higher levels, but there's no recommendation, and I often use max when demonstrating things. I barely ever use mid.

@ngn would you recommend min or box OFF altogether; doesn't matter though, I am not going to turn boxing off :P

Ah so turns out I am not that weird for having boxing set to min. Ty for sharing your experiences

@RGS It might be nice to have ]box on -style=off to get the side effects of boxing without lines.

@RGS i'm a language geek, so my personal favourites are: the one that does roundtripping (but i can never remember the incantation to enable it..) and display from dfns.dws. if i were staring at uniformly structured data all day, i'd probably go for something with minimum noise.

@RGS I unapologetically run ]box on -style=max -trains=tree -fns=on -- it doesn't play nice in RIDE with the output but looking at the boxing has improved my learning velocity for sure.

@Adám -style=off doesn't exist; I couldn't understand what you mean; aren't the only side effects of having boxing the fact that arrays are displayed with lines that make it easier to interpret the nesting levels..? what would an "off" style look like?

@ngn is the display from dfns.dws related to the DISPLAY I get from )copy DISPLAY?

@ngn (also no idea what you are talking about in the first case)

@RGS you mean )copy display? i didn't know this existed, but yeah - looks the same

@RGS No, boxing also shows function definitions when you enter a name, including a sensible display for tacit functions, and it normalises line endings.

@dzaima ah I do use that one quite often :P

@dzaima @ngn I have F11 set to '⎕SE.Dyalog.Utils.repObj '

@ngn hm yes, I thought the names were case sensitive and I read about it as DISPLAY, that's why I used upper case as well.

@Adám ah I see, so keeping all that and then having no boxing around arrays.

@RGS "roundtripping" means that if you copy the output, paste it as input, and evaluate it, you get an object matching (≡) the original (in cases where this is possible)

@ngn Now I understand, yes.

@Adám where does one go to create such a shortcut? Options > Configure didn't look promising and no other menu tab seemed appropriate

@RGS aplcart.info/?q=f-key#

@Adám has the idea of a ]cart ucmd come up yet?

@Adám nice

@Adám how does one make it permanent? I tried saving the session info on close but it didn't work.

@ngn That's trivial to make: ]open https://aplcart.info?q=f-key and in the IDE you can make F1 go to APLcart when F1 can't find anything.

@RGS You'd have to set it at startup time, either using SALT's MyUCMDs/setup.dyalog or Link's Dyalog APL Files/StartupSession/anything.apl? or modify ⎕SE.Dyalog.Callbacks.WSLoaded

@Adám ah ok, thanks

I'm sure I've seen this somewhere, but now I can't find it: is there a way to make a large(ish) integer print as an int, rather than (say) 3.41252E9

@xpqz 0⍕

What do I need to search the 'cart for here?

@xpqz Sorry, it isn't there ― yet.

@Adám can't one also increase ⎕PP?

@RGS Sure, up to a limit.

34

@Adám and 0⍕ works for arbitrary ints?

If so, it makes me wonder why ⎕PP is capped

@RGS Yes, except it'll use _ for unknown digits.

Ah yes, the ⎕PP trick was what I vagely recalled.

@RGS ⎕PP sets precision. There's no more precision to print.

@Adám I thought 0⍕ would print all the digits, but in fact 0⍕2*1000 has a bunch of underscores. I would just be baffled if 0⍕2*1000 had precision to print all the 302 digits of 2*1000 but then with ⎕PP I could only go up to 34

with ordinary fp you get only 17 digits

iirc 34 is for ⎕fr←1287

@ngn Heh, I should make it ]APLCART.Info so you can type ]info life

@ngn I've also added APLcart to the menu in RIDE, so Alt+h,a takes me there. Less typing than ']abcd '

@RGS that's why a single numeric tower is bad :) ideally ints would overflow into arbitrary-precision, like in python, and floats would be completely separate (wink @Marshall)

@ngn I think I'd still prefer a single numeric tower, but one where I don't need to worry about precision ;-)

@Adám sounds cool

@ngn I do like how my ints can grow huge in Python

@ngn Whaddya mean? You implemented the possibility of doing so!

@RGS yes, it's nice bigints aren't a separate thing in Py.

@Adám i'm glad you found good use for it

@ngn Well, it be even better if there was an additional variable called selection. Maybe I'll ask for that.

Also, it'd be nice if the menu bar allowed atomic items, so one could implement "buttons" rather than pull-down menus. Hm…

@Adám idk if electron's "native ui" api allows that

@ngn I can always ask. (Just did.)

@ngn 0) How do I get half of an even integer? 1) What is the type of ⌊1e100? It's a pretty pretty big increase to the language footprint to cater to the very small number of applications for integers past 2⋆53.

@Marshall I have no idea how this works in Python:

>>> 2**300
2037035976334486086268445688409378161051468393665936250636140449354381299763336706183397376
>>> 2**300 / 2 * 2
2.037035976334486e+90
>>> math.floor(2**300 / 2 * 2)
2037035976334486086268445688409378161051468393665936250636140449354381299763336706183397376

Oh, stupid me.

Yeah, it's just making up digits. Try subtracting 1e20 before flooring.

Right, I just did.

(or just math.floor(1e100))

@dzaima amusing XD and slightly sad

dzaima/APL

@Marshall 0) is this a trick question? just use intdiv by 2

1) whatever you decide to make it. either choice would make some sense. i'd prefer int.

@ngn intdiv? I.e. (⌊÷) or (_%)?

"Just" add a whole new kind of division to the language...

@Adám it's a separate operation, it isn't always ⌊÷

k had (-y)!x for intdiv. it became y/x in k9.

@Adám in python3 / is div, // is intdiv

python2 used the same (/) for both based on type, like c

@ngn So k9 has proper schizos like APL!

@Adám / is still an adverb

So you can't do 1 2 3/'4?

@Marshall "add" and "number of applications" are point-of-view. why "add" floating point when bigints (and fixed precision / rationals) work so well for most applications i target?

@Adám why not?

@ngn What does it give?

@Adám same as 1 2 3/4 because 4 is an atom (scalar)

@ngn Ah, but how about 10 20 30/'1 2 5 vs 10 20 30%'1 2 5?

noun-or-verb followed by an adverb makes a derived verb. it's similar to apl.

@Adám 10 20 30/'1 2 5 <-> (10 20 30/1;10 20 30/2;10 20 30/5) from the definition of "each" (')

@ngn Right, and 10 20 30%'1 2 5?

@Adám i.e. "yes, you can't"

@Adám 10 20 30%'1 2 5 <-> (10%1;20%2;30%5) likewise, but this time "each" is dyadic

@ngn Yeah, then I consider this / hack a lapse in sanity.

(more precisely: the derived verb formed by "each" is applied dyadically)

@Adám why? it looks pretty solid to me

think of 1 2 3/ as any other verb, like +

The fact that normal division and integer division have completely different semantics is just wrong.

@Adám it's mathematically right

???

@ngn that has nothing to do with syntactical semantic sanity

@ngn You're the one who said the ideal is arbitrary-precision ints and floats. But we have a pretty big difference in experience, since I'd say non-rational math operations like square root or sine are a hard requirement in about half of the programming work I do and floats are often convenient for the other half.

@Adám have you ever heard the phrase "field of integer"? no. it's always the "ring of integers". there's no division there.

@Marshall fair enough. again, it depends on the kind of applications you target.

k9, for instance, might not even have a square root built-in (formerly %x) because it's hardly ever useful to its users. it might be available through other means, like `sqrt@x or `e@(`e?x)%2 (exp(ln(x)/2))

@ngn I don't understand how that's supposed to support the strange behavioural difference between k9's / and %.

@Adám they are very different operations

intdiv results in quotient and remainder

floatdiv is like times the inverse

@ngn Wait, what‽

Isn't that divmod?

@Adám yes, usually we call the quotient "x div y", and the remainder "x mod y"

@ngn but k's / gives both? so it's not a scalar function verb?

@dzaima no. k9's y/x is "x div y" and y\x is "x mod y"

@dzaima yes, y/ and y\ are scalar verbs (or "penetrating" verbs, i'm not sure what the latest terminology is)

note that / is an adverb. y/ is the derived verb.

@ngn so it's still completely unrelated to the fact that / and % have completely different syntax despite being the same style of operation (i.e. i'd call % and + more unrelated than / and % )

@ngn The argument order is a little unfortunate since it's usually the denominator that's constant.

@dzaima well.. available syntax is in short supply in k :)

@ngn so that answers that

@ngn That's no excuse for this.

@Marshall yeah, pity. would have made a lot of sense in a reverse apl, but that's too radical :(

@ngn Well, x\y could have been ⌊y÷x, with x/y being x|y.

Some languages have a reverse-division using backslash.

@Adám ⌊y÷x - you mean treat _y%x as an idiom? sure, that's an option

x|y is "max" in k

@ngn No, I just meant to give the APL defintition.

x\y could be integer division, and x/y could be mod.

@Adám if you could break the chains of backwards compatibility :) but you can't

@ngn we're talking about k syntax, we precisely can

i'm lost

@Marshall btw, y is the denominator (or modulus) there!

@ngn Adám is proposing that, in k, x\y is APL(⌊y÷x) and x/y is APL(x|y)

@dzaima so, just swap / and \ in their current definitions?

@ngn yeah

@ngn Oh, I misread! A surprising break from common programming convention, but I do agree it's the better order.

@ngn (i also misread; in the case that x/y is already y÷x, swapping the two slashes makes even more sense)

I also misread, and yeah ^ and ^^

maybe. if you all feel strongly about swapping / and \, let k's author know.

Hm, if glyphs were cheap, I might just have included / as division, \ as reverse-division, 3↗2 as 3² and 3↖2 as 2³.

@ngn I think you should, if you can explain all this right.

Before anyone gets the wrong idea I'll boldly declare that I have no strong opinion.

2↙3 could be log₂3

@Adám i don't think i can, it doesn't matter much to me anyway

@Adám relevant, 6min video where 3blue1brown explains an alternative notation for logarithms, powers and roots, unifying everything

@RGS That's what I had in mind, but this is like an inline version of that.

in my wildest ideas of a programming language evaluation would be left to right. there would be no adverbs. x/y would be "div". x/(+) or x/+ (followed by a space) would be "fold".

@ngn Yeah, I think an APL-derivative like that would be really interesting, at least to experiment with.

@ngn Ah, the space or paren is to disambiguate from monadic (postfix) application of / or +?

@Adám i was thinking x/+-y could mean x/(+(-y)) but if you insert a space after + it could become a noun, so: x/+ -y would be (x/(+))-y

@ngn Why would you want monadic functions to be prefix in a LtR APL?

@ngn Iridescence sort of follows that convention. It's UFCS rather than truly left to right, so x.f is identical to f(x), but x/f applies f to a list or array of arguments x. It's not a true reduce, but the functions you would reduce with generally take any number of arguments; for exxample you can sum a list with l/+.

@Adám i'm not sure how much of an apl that would be :) but generally -x reads better than x-

@Marshall heh, i was just about to mention x.f :)

@ngn True, and I've been pondering how to get around that issue for - and ÷, but simply concluding that one could be explicit about the 0 or 1. Maybe your system is good.

@Marshall I haven't implemented the language but I found the ambiguity fairly annoying when testing it out. The ideal character is really * for the Kleene star, which is used in types, but since it uses ASCII, the overlap with multiplication is even worse.

@Marshall "making up digits" - i don't think it is. you know, ieee fp uses a binary mantissa. that doesn't map well to big powers of 10.

@ngn But it does map well to big powers of 2.

@Adám yes

@ngn Sorry, I didn't mean that it's arbitrarily selecting them, just that it's adding precision that the floating point representation doesn't have.

@Marshall not sure what you mean. how would print 1e100 then?

@ngn it acts as if the unknown mantissa was zeroes

@ngn You could print enough digits to uniquely specify the float (~17), or as many digits as the float guarantees (i.e. any number rounding to it would have those digits; ~14). Either way, 100 definitely gives the wrong picture about what's being computed, and converting float 1e100 to an exact integer is a dangerous thing to do.

@Marshall that would make sense for printing fp. you want the "simplest" representation (for some definition, usually number of significant base-10 digits) that rounds to the same fp number. but here you explicitly request "floor" - there's no reason to favour base 10 over any other base.

so, i think python's floor is doing the right thing - it renders as a bigint the exact value represented by the fp number.

@ngn I was answering your question about printing. If taking the floor of 1e100 is going to cause you to print all the digits later, but this is a bad way to print 1e100, it seems that allowing the floor is bad.

@Marshall after you floor it it's no longer fp

(at least in python)

@ngn Python uses the best bigint it possibly could. The question is whether this very easy conversion of any float to a bigint is good design.

@ngn If you consider a float to be a value with uncertainty, which is how most people use it, then the floor is still uncertain if the original uncertainty is greater than 1 or so. Keeping it float is one possible way to represent this uncertainty.

@Marshall fp has no uncertainty. the "error ball" representation adam mentioned is for that.

fp (apart from nans, infs, and subnormals) is the exact value (¯1*sign) × 1.mantissa × 2*exp-bias

just like the integer 123 means 123 exactly, not "some number between 122.5 and 123.5"

@ngn It has no rigorous handling of uncertainty. But it's reasonably modelled as a number with uncertainty, and that's definitely the most common model for it if the user cares about the error at all.

@ngn fp mentally has uncertainty. how the error between it and the symbolically evaluated precise real number is unrelated

I'm very familiar with the finite parts of IEEE-754 doubles.

@ngn the numbers represented by bit sequences in the IEEE-754 format obviously do have precise values, but actually relying on the fact that they're a 53-digit binary number with some shift most likely means you're using floating point wrong

@dzaima Or you're building CPUs or numerical software, but that's rare enough not to invalidate your point.

@Marshall that's the reason there's a "most likely" not a "definitely"

(i guess one could also say there's a difference between using floating point numbers and IEEE-754 binary64 - in the former you're (mentally) using uncertain calculations on some probably-correct digits, and in the latter you're using numbers with a 53-bit mantissa multiplied by some exponent)

@dzaima i think the presence of an exponent in the ieee format makes it by definition "floating point"

@dzaima @Marshall so what do you guys think the (presumably integer) result from floor(1e100) should be in a well-designed language?

@ngn I think it should be an error or a float.

And I think most scripting languages should just have floats.

@Marshall would there be some kind of cast-to-int operation available?

@ngn couldn't think of a good way to name the former case. the two were meant to be the same format, used in two separate mental models (the former being "informal"(?) and the latter - "formal")

@ngn my opinion would be there'd be separate int/float floor methods, i.e. not Math.floor but int.floor/double.floor; int.floor would error on out-of-bounds, double.floor would be the double version, and BigInteger.floor would convert to the proper precise bigint

@ngn ok "just floats" answers that. anyway.

@ngn I can't think of why that would be useful (if you want to use it as an int, surely you can generate it as an int?), but if there is one, it should be more of a "library" function than a "primitive" function. This only applies to numbers outside the integer floating-point range. A floor that returns an int but errors if there's more than one that would round to the argument is fine.

@dzaima as for if i could have only one floor, i'd keep only one numeric type :)

ok, so neither of you is arguing that floor(1e100) in python should return 10**100 then?

@ngn i'm definitely not

@ngn Yeah, the idea of my questions was to point out that having two numeric types with implicit conversion introduces a lot of complexity in how they interact. It might make sense, but "ideal" is not how I'd describe it.

@ngn No.

@dzaima i think i understand what you're getting at there but it makes me uncomfortable :) i'll try to explain why in a moment

so, uncertainty in floating point numbers could come from real-world measurements or floating point calculations (which are usually approximations of real-valued functions, not always rounding to the closest representable fp value). these uncertainties have nice properties - they are like probability distributions clustered closely around the representable value.

the problem is, when you perform an operation on two nice distributions, the result may not be distributed in the same manner. even for simple operations like +, the result's distribution gets distorted, and this effect accumulates the more operations you perform.

what is worse, the "shape" of the probability distribution of the error in the result could be different from those in the operands, and the fp format completely ignores that

so in a sense, there's loss of information at every step

All true. My only comment directly about these issues is that they usually happen when you have enough numbers and complicated enough operations that the calculation isn't feasable any other way. Which is why you get conservative solutions like Kahan summation that just increase the precision rather than a whole different number system.

@ngn oops s/representable value/actual value/

@ngn 1) if the precise error probabilities matter, fp probably shouldn't be used; 2) if my intuition is correct, unless there is continuous wrong rounding (which includes the magnitude difference in e.g. iterative sum), the error should still be about log(operation count) bad trailing bits

(also, as a fun side-note, stochastic rounding)

I like APL\iv's ability to configure the possible numeric types (or think I like; I haven't used it in practice). I don't like having two systems if types are implicit because it introduces a whole new class of bugs when a number's type isn't what you expect.

@Marshall i think it's important to have a type that never makes mistakes (int), and there's value in a separate type that makes practical compromises (float)

if i had to sacrifice one of them, it would be float. but i don't have to :) and i think you don't have to either.

as for the interaction between the two - casting, etc, i think it's ok for them to be completely separate, possibly allowing only explicit casting. that's how i started in ngn/k. i added implicit casting later because people seemed to expect it because that's what the original k does.

@ngn a nice thing about iee754 is that it doesn't really make mistakes on integers<2^52. but which out-of-bounds behavior is better is a good question (immediate "everything is wrong" vs slow&steady constant mistakes)

@dzaima there's no single right answer for "better"

@ngn I'd been thinking about a ⎕FR-like precision control that works at a scope level rather than a data level or primitive level. The main problem I had was that it's hard to specify precision in a meaningful way. But I guess it would at least make sense to say "behavior in this scope introduces no error" versus "this scope uses doubles". Too hard for me to implement, at least for now, but it's something to think about.

Pseudo-showcase: using n (m∘|⍤*⍨\⍤/) 2 to compute n consecutive squares modulo m, making use of ⍤ twice looks really nice.

@RGS So, m|2*2*⍳n without the large intermediate values? Where does that come up?

@Marshall powermod

@RGS But only base 2? Seems like you want a scan with initial value.

@Marshall that is left as an exercise for the reader