« first day (369 days earlier)      last day (1166 days later) » 

chrispsn
chrispsn
07:27
Why does this last dict give type error? 
 t: [[]a:1 2;b:3 4]
 (*t).a
1 3
 [a:1;b:3].a
1 3
 d: [a:1;b:3]
 d.a
d.a
^
error: type
ngn
ngn
07:51
@chrispsn the d.a notation probably requires the values of d to be a generic list 
 d:[a:1;b:3;c:()]
 d.a
1
chrispsn
chrispsn
now i look back at the examples before that one, none of them make sense to me
@ngn thanks. i wonder why it was designed that way
ngn
ngn
@chrispsn could it be that (*t) and the dict literal [a:1;b:3] don't squeeze the values to the smallest possible type? i don't know how to check that
chrispsn
chrispsn
well [a:1;b:3].a would result in 1 if dot notation worked, but it gives 1 3, which is clearly wrong 
 @:/. [a:1;b:3]
`I
ngn
ngn
08:07
@chrispsn interesting.. and [a:1;b:3].b is a value error
chrispsn
chrispsn
sounds like a bug
ngn
ngn
@chrispsn it looks like the letter a is special :) [c:1;d:3].a is also 1 3
@chrispsn maybe it parses like ([a:1;b:3])(.a) and there's a .a namespace similar to .z?
ktye
ktye
but 1 3 indicates it calls monadic .[...] , no idea about a vs b.
ngn
ngn
i wouldn't expect the something.key notation to work when "something" is not an identifier
@ktye [a:1;b:3]@.a also returns 1 3
maybe .a is something special, similar to the old :: which had two versions - one to represent the identity function, and one to represent missing values in projections
chrispsn
chrispsn
@ngn ah that would be it! .a is the default database so it's doing empty index i think 
 [a:1;b:2][]
1 2
ktye
ktye
08:21
.a exists. it's empty.
but #(.z) is 14, but #(.a) is an error.
ngn
ngn
@ktye @chrispsn my last guess was right! :) 
 .a~:/.{z}[1;]
1
ktye
ktye
.a~:/.{z}[1;]
error: nyi
what is z?
ngn
ngn
@ktye oops
apparently the space after .a was significant
try this: .a ~:/.{z}[1;]
z is there to force {z} to be triadic (for some reason it didn't work with {y})
ktye
ktye
:/ is last?
ngn
ngn
{z}[1;] makes a projection, then . decomposes it into a list, :/ takes the last item
@ktye yes, see .z`last
ktye
ktye
08:36
short time memory: chat.stackexchange.com/transcript/message/53740606#53740606
. p with projection over f is the list {f;a;b;null;..} ? f is the function, followed by the arguments with nulls
ngn
ngn
@ktye you mean (f;a;b;null;..) - yeah, i assumed . does that
. doesn't always work. k9 is in its infancy.
ktye
ktye
do you consider projections to be elemantary to k, or could you do without?
ngn
ngn
@ktye what's the alternative?
ktye
ktye
not having them. using a lambda instead.
ngn
ngn
what should happen when you apply an n-adic fn to n-1 args?
ktye
ktye
08:50
that would be an error.
ngn
ngn
@ktye i think i prefer projections. they are more concise and in many cases explicit currying would be impossible because we don't have closures
example: {f:{x+y*z}; f[1;2]'3 4 5}0
you can't write {f:{x+y*z};{f[1;2;x]}'3 4 5}0 because the inner {} doesn't "see" the f in the intermediate scope
ktye
ktye
ok, thanks
 
10 hours later…
beagle3
beagle3
19:15
@ngn If you are still fiddling with ryu you might also find this interesting lemire.me/blog/2020/03/10/fast-float-parsing-in-practice - it's only about speed (but then, it's parsing not printing).
ngn
ngn
@beagle3 yeah, i noticed it on hn. the problem with this one is it sacrifices accuracy, so it might not round-trip even if printing is correct
beagle3
beagle3
@ngn I didn't look at the code, but lemire claims in the blog post that it is exact, and at least so far whenever I did look at his work, he was very precise and dependable.
ngn
ngn
@beagle3 in the first paragraph he says: "However, we sacrifice some standard compliance. You see, the floating-point standard that we all rely on (IEEE 754) has some hard-to-implement features like “round to even”. Sacrificing such fine points means that you can be off by one bit when decoding a string."
i'm not sure if it matters for round-tripping. maybe the printer can be made to mirror the parse errors
and in practice it probably doesn't matter at all..
beagle3
beagle3
@ngn He is talking about his old json parser in that paragraph. Later it says: I was going to leave it be. Yet Michael Eisel kept insisting that it should be possible to both follow the standard and achieve great speed. Michael gave me an outline. I was unconvinced. And then he gave me a code sample: it changed my mind. The full idea requires a whole blog post to explain
ngn
ngn
@beagle3 oh.. i didn't get that far :)
beagle3
beagle3
19:28
(but I've not verified it myself ... so, caveat emptor + lector ....)
ngn
ngn
lol :D const bool structural_or_whitespace_or_exponent_or_decimal_negated[256] = {
a 55-char variable name :)
ngn
ngn
19:59
@beagle3 "We fall back on the standard library for the difficult cases." -README.md
that makes it unsuitable for ngn/k, unfortunately
beagle3
beagle3
@ngn forgot about that aspect of ngn/k ...
chrispsn
chrispsn
20:30
do you prefer L^ (cut) taking indices or deltas? 
 0 3 4^"thektree"
the
k
tree
versus 0 3 1^"thektree" for the same
btw i never fully understood why the zero at the start is not implicit
ktye
ktye
@chrispsn maybe to be compatible with drop (atom)
ngn
ngn
@chrispsn each number is the start index of a slice - this is simpler than also having an implicit slice before the first number
chrispsn
chrispsn
@ngn I think 'cut here and here' instead of 'start slices here, here and here'
ngn
ngn
20:47
@chrispsn the analogy with scissors doesn't capture what "cut" does with duplicate indices
if you cut a strip of paper at the N centimeter mark twice, you still get the same results
but 1 2 3^x is not the same as 1 2 2 3^x
chrispsn
chrispsn
@ngn ah, good analogy
still, could have that without zero at the front (2 2 3^x)
ngn
ngn
as an implementer i liked the fact that the lengths of the left arg and the result are the same
that promotes memory reuse
@chrispsn what do you think about each-prior - if #x is n, should the result be of length n-1?
ktye
ktye
did that just today.
cut:I:II{v2;(~xt~2)?!;(xn~1)?(r:y drop I xp;dx x; :r);r:5 mk xn;rp:r+8;xn/(a:I xp;b:I xp+4;(i~xn-1)?b:yn;(b<a)?!;rx y;rp::y atx seq(a;b-a;1);xp+:4;rp+:4);dxyr}
chrispsn
chrispsn
21:05
@ngn no - then you can't each-prior over an empty list
btw - inconsistent behaviour between k7 and k9 here 
2019-09-25 14:44:44 2core 3gb avx2 © shakti l test
 ,/""
""
2020.03.09 (c) shakti
 ,/""
" "
@ngn so you're saying you think of cut as a reduction?
or mapping or similar
ngn
ngn
@chrispsn more like an each(-left)
ngn
ngn
21:18
here's an attempt to implement the traditional cut as a k string: {y@x+!'1_-':x,#y}
@chrispsn with your modification, it would be: {y@(0,x)+!'-':x,#y}. maybe they are not all that different after all. but the length mismatch between x and the result bothers me

« first day (369 days earlier)      last day (1166 days later) »