Speaking on own APL implementations, I'm currently facing a dilemma with mine: I have a half-implemented optimisation to support typed arrays (i.e. arrays where all elements are guaranteed to have the same type). This will give a very nice performance boost for certain operations, since values don't have to be boxed and unboxed all the time.
Sounds like a no-brainer right? Problem is that the codebase will grow a lot and testing is going to be harder (since there are now generic vs. optimised code paths in many cases).
So perhaps it's too early to do this... I don't know. That's why it's such a dilemma.
@RGS There's a difference too. .wiki and .chat literally describe what they are. apl.cart wouldn't be a good hint at what it does. apl.info would be better, but that isn't available.
> You can place an offer below the seller's listing price, however the seller will only respond if they are interested in negotiating based on this offer.
The point wasn't golfing the URL, IMO. Domain names are like the internet's real estate and it can be the difference between being in 5th Avenue or some dark alley
Also not saying you have to buy apl.info! Just arguing in favour of it.
@RGS When I set up aplcart.info, I considered neo-TLDs not well-known enough, so I went with a more traditional TLD. However, today, funky TLDs are becoming quite common, so I felt more confident about .chat and .wiki
@EliasMårtenson Bad registrar. Mine offers it for $546.33
@EliasMårtenson I think it'd be better to populate aplcart.info/pub and let it include the published blog posts (which then don't need a cool domain). If it takes off, I'll buy aplpub.info
<moon-child> so it's not a matter of 'have to', it's just that that's convention, and it's hard to get people to trust new authoritative domain servers
razetime: People can have any extension they want, but others won't be able to find the server. E.g. at Dyalog, we use .bramley (the town HQ is in) for our internal network.
> Like all alternative root DNS systems, OpenNIC-hosted domains are unreachable to the vast majority of Internet users, because they require a non-default configuration in one's DNS resolver.
APL (Dyalog Unicode), 60 bytes (SBCS)
Anonymous prefix lambda taking (and ignoring) a dummy argument.
{0::43↑22↓2⊃⎕DM⋄The quick brown fox jumps over the lazy dog}
Try it online!
{ dfn:
0:: if any error happens:
⎕DM get the Diagnostic Message (a list of three strings; the error message, the o...
<moon-child> finally started working on apl cas. Mathematica documentation helpful at times, but also contains horrifying gems like ‘Expression formatting uses several thousand pages of C++ code’
moon-child: Regarding the question of 64-bit INTs in Dyalog APL, we could declare them to be part of the "big tower" that you select in Dyalog APL by setting ⎕FR (floating-point representation) to 1287 (meaning 128-bit Decimal Float). What ⎕FR actually selects in Dyalog APL is the type that will be used for ANY COMPUTATION that requires floating-point.
Dyalog APL already automatically promotes and demotes between 1-bit, 1- 2- and 4-byte integers, so we could declare that (⎕FR=1287) ALSO means that I32 will blow up to I64 before going floating-point. On the other hand, one could argue that …
@dzaima well, if all you do is convert them back and forth it is not so bad, and this is not very widely used functionality (getting a handle and handing it back again). It also only happens (I think) if the I64 actually has a magnitude that requires it.
(i've been thinking about having explicit types, but still allowing the internal type to be a smaller one if that's better. Seems quite a bit more complex, but the actual implementation overhead isn't that much more than of the regular single tower afaict)
@dzaima Yup, writing an APL interpreter is a one-semester project. Writing an efficient one can take several lifetimes. But it is fun when some chief actuary in an insurance company can write a line of code that runs faster than C code which is hand-optimised by a pro :D.
@dzaima Been working more on BQN music scripts and at this point not having sine and cosine available is a problem. Do you think you can add a •Math or •Import"•Math" object that provides these? It's probably best for it to eventually include all of libc's real computations as scalar functions, but of course people (me) will mostly use trig.
FFT would be helpful too, since it's pretty hard to implement if the length isn't a power of two. Right now I just need it for reverb (convolution), which I can implement with power-of-two lengths but would rather not.
@rak1507 They may just not be able to justify putting as much effort into solving a single trivial application problem as an APL vendor can justify spending on something that will speed up a thousand different solutions.
(which I think is a point that Marshall makes in that talk)
@dzaima Makes sense. Looks like FFTW is really messy too. It would probably be a better use of time to add an FFI so it's possible to call the shared object like J does, not that there's any pressing need to work on that either.
@cannadayr Yes, eventually you'll definitely be able to use either •math or something like •Import"•math" in the same way dzaima's implemented. The reason I haven't yet added namespaces to the spec is that I'm not sure how things like trying to modify a member variable should work.
I just want to say that I have successfully created my first user command, wed, that opens the editor for (tra)dfns and (tra)dops in such a way that the whitespace is NOT squashed
The only "tricky" thing was dealing with the fact that the interpreter was getting hung up because the cmd was only finished when I closed the edit window, but some & magic fixed that.
APL (Dyalog Unicode), 60 bytes (SBCS)
Anonymous prefix lambda taking (and ignoring) a dummy argument.
{0::43↑22↓2⊃⎕DM⋄The quick brown fox jumps over the lazy dog}
Try it online!
{ dfn:
0:: if any error happens:
⎕DM get the Diagnostic Message (a list of three strings; the error message, the o...
