is it worth to intern 64bit int and float constants as syms?

@ktye bravo on the flip fn

i think it does need tweaks for scalar extension though, as you said

 f
{(,/x[;!n])@(n*!#x)+/!n:|/#'x}
 f("c";1 2)
c 2
1

@ksi what do you mean?

@chrispsn workaround: insert n#' before x[;!n]

it's amazing how fast ktye's flip is. last night i tried some alternatives but nothing beats gather-scatter indexing.

Everyone here is likely already on the shakti mailing list; but if you are not like myself, reddit.com/r/apljk/comments/fjdefh/… , you'll find this interesting

@beagle3 wonder if that's the entire k.h (ie all the macros in k9)

@ktye what about flips of empty lists?

 {(,/x[;!n])@(n*!#x)+/!n:|/#'x}()
{(,/x[;!n])@(n*!#x)+/!n:|/#'x}
                     ^
error: type

@chrispsn #'() may be a little wrong. it evaluates to () instead of !0. easily fixed with |/#'x -> |/0,#'x

but (!0)+/!0 looks wrong too and idk how to work around that

maybe special-case the empties?

@ngn do you intend to use the transpose implementation in ngn/k?

Yeah, I think the result of #'() is a bug in k9, not @ktye's code

@ktye i was talking about k9 above. use in ngn/k - yes, if you don't mind me stealing your idea

btw, the @ is redundant

@beagle3 have you applied? It's worth it!

@chrispsn just joined the group. And there goes my afternoon .....

@ngn i meant to create a global list for int and float constants, every time a int/float constant is declared, it's found/allocated in that global list instead of allocate and free it using the memory management. hopefully this way will be faster and save some memory. but ofc, in a real world use case, there aren't that many numeral constants after all. so, maybe save some byte code for the most common constants?

i know that q/k4 have special byte code for constant 0 and 1, but others like 0n 0w -0w maybe useful too

i am also curious about fix data type in k9. is it something like what i describe above?

@ksi constants are already stored in a list - not globally, just per function. see the last element of .{1+x} for example. i like the idea to use bytecode instructions for common constants.

@ksi i don't know. i thought it might be fixed-point (as opposed to floating-)

@ngn yeah, but the last element of .{1+x} is a general list right? to allocate a constant 1, you have to call the ma() again. oh, fixed point, must be it.

@ksi yes, it's always a generic list. what do you mean by allocate a constant 1? there's an instruction that gets the existing object from that list, puts it on the stack, and increments its refcount. there are no new allocations if you're just using a constant from your k code.

that's for 64-bit longs. as for 32-bit ints - they don't need to bother the memory manager at all. the 32-bit value is stored as part of the "tagged pointer" (which isn't really a "pointer" in this case..)

@ngn right, for a function, the constant list have the same life span as the function itself. so, we do not expect a defined function to die any soon. i was thinking about the expression evaluated in the repl

@ksi i compile that as if it's a function too

but yeah, it gets discarded after you press enter and the line is evaluated and the result is printed

@ngn anyway, i think repl is not something that performance critical, i'd rather go the bytecode way.

if i make a global list of such constants, i'm not sure that the cost of searching it would be less than the cost of allocating new memory every time.

@ngn how do you do it for syms, balanced trees or hash?

some stats from my codegolfs:

$ ag -io '[-]?\d+(\.\d+|[wn])?' --nofilename --nobreak|sort|uniq -c|sort -nr|head -n20
   2259 0
   2020 1
    502 2
    384 3
    300 4
    258 5
    188 -1
    156 6
    147 8
    136 7
    110 10
     99 9
     62 13
     62 12
     55 11
     53 15
     52 34
     49 30
     49 20
     47 25

@ksi an ordinary k list :) with linear searches

@ngn well, that's fair i guess, haha

@ngn looks like 0 and 1 are indeed very popular.

@ksi yeah.. and i thought -1 would be closer to the top

@ksi there's a more lucrative optimization - "constant folding". any subexpression involving only constants and operations on small enough constants could be pre-evaluated by the bytecode compiler. @ktye already did this

@ngn wow, that's very nice.