4 ms·
> Nobody is born having learned a language. It's something even babies have to learn and they know nothing! I meant a programming language (it gets confusing,
by gjulianm 7y ago
> Nobody is born having learned a language. It's something even babies have to learn and they know nothing!
I meant a programming language (it gets confusing, sorry). But anyways, our native language is much more embedded in the brain than programming languages.
> I think if you decided to write your "simple script" in even a well-known language like JavaScript, you'd cause some grumbles in a Python+C# shop; k isn't special in this regard.
Yes. And I'd cause even more grumbles if it was written in Haskell, and even more if it was on K. That's the point.
> HIBP offers the data pre-sorted, so I used that.
Yes, and that changes how you access the data. So the evaluation was not fair, as the OP was not using sorted data.
> db is a database in exactly the same way that Python could be if you just pickle/unpickle everything, except it's actually fast enough that people do this, even for large data sets.
That's nice, I'd actually wish Python had better serialization facilities.
> f=42 returns 010b and g=69 returns 010b -- do you see why
What if "f:42 1 2"? f=42 returns 100b (is that a value or a vector?) so under the common "and" definition "(f=42)&(g=69)" should return 000b, under the "less than" returns 010b?
- geocar 7y ago> our native language is much more embedded in the brain than programming languages. I think it's possible that might have more to do with the fact we use "our native language" more. > Yes. And I'd cause even more grumbles if it was written in Haskell, and even more if it was on K. That's the point. I don't know. I work in a place with a lot of q/k programmers, so this isn't a problem I face. > Yes, and that changes how you access the data. So the evaluation was not fair, as the OP was not using sorted data. You're mistaken. They did use sorted data, they just didn't know about the presorted file so they also wrote code to sort it. > is 100b a value or a vector? It's a vector of three elements (bits: zeros or ones). > What if "f:42 1 2"? f=42 returns 100b … so under the common "and" definition "(f=42)&(g=69)" should return 000b Yes that's right, and q/k would return 000b in that case. > under the "less than" returns 010b? 100b<010b is 010b. We need something that gives us 000b and that operation is "and". Say I have a table that looks like this: f g k -------- 10 9 kf 20 8 je 42 69 kf 42 0 lk That's written like this: t:+`f`g`k!(10 20 42 42;9 8 69 0;`kf`je`kf`lk); k has tables as a data type. You can think of them as a list of dictionaries if you want: q)a:`f`g`k!(10;9;`kf); q)b:`f`g`k!(20;8;`je); q)c:`f`g`k!(42;69;`kf); q)d:`f`g`k!(42;0;`lf); q)(a;b;c;d) f g k -------- 10 9 kf 20 8 je 42 69 kf 42 0 lf but I only do this to reinforce the idea this is a basic data type in k. I can write t.f=42 and get 0011b and t.g=69 and get 0010b. I can do queries like this: q)select from t where (f=42)&(g=69) and that's basically the same as this: t@&:(t.f=42)&(t.g=69) +`f`g`k!(,42;,69;,`en) (&: is "where" and not to be confused with &) And from there it should be clear why we need this "and" behaviour. The question is what should a&b do when they're not bit vectors that would be compatible with this behaviour? 42&69 should return 42 because it's the lesser; 0b&1b returns 0b because it's the lesser... Mathematics is already quite comfortable with the relationship between logical-and and min, so this has a precedent.