Hi!
There’s some hidden rule which keeps me off using dot notation for accessing dictionary properties, because it mostly never works.
Decided to nail it, and discovered following, how comes?
q) zz:ab`c!((10;11;12);(20;21;22);(30;31;33));
q) bb:ab`c!(10 11 12);
q) show zz;
name| 10 11 12b | 20 21 22c | 30 31 33
q) type zz
99h
q) show zz.a;
10 11 12
q) show bb;
a| 10b| 11c| 12
q) type bb
99h
q) show bb.a
evaluation error:type [0] show bb.a;
^
Cheers,
S.S.
Hi Sanny,
it happens because you have multiple values in the first case and only one value in the second case
please use the following syntax for case 1 and 2 :
zz`a
(Roundtrip: 000ms)
10 11 12
bb`a
(Roundtrip: 000ms)
10
??, 4 ???. 2018 ?. ? 17:13, Sanny Sanoff <sannysanoff@gmail.com>:
Hi!
There’s some hidden rule which keeps me off using dot notation for accessing dictionary properties, because it mostly never works.
Decided to nail it, and discovered following, how comes?
q) zz:
ab`c!((10;11;12);(20;21;22);(30;31;33));q) bb:
ab`c!(10 11 12);q) show zz;
name| 10 11 12b | 20 21 22c | 30 31 33
q) type zz
99h
q) show zz.a;
10 11 12
q) show bb;
a| 10b| 11c| 12
q) type bb
99h
q) show bb.a
evaluation error:type [0] show bb.a;
^
Cheers,
S.S.
–
Submitted via Google Groups
it is not hidden, you just have to look in the right place.
you can only do this when the ‘value’ of the dictionary is a mixed list (type 0h):
q)type value zz
0h
q)type value bb
7h
if you want to ensure this always works, start your dictionary with a null value:
q)cc:``abc!(::;10;11;12)
q)type value cc
0h
q)cc.a
10
note that this is how directories work:
q)0N!1#.q
(,)!,:: | :: q)0N!1#.o (,)!,::
| ::
q)0N!1#.h
(,`)!,::
| ::
On Sunday, November 4, 2018 at 6:49:20 PM UTC+2, Nick wrote:
if you want to ensure this always works, start your dictionary with a null value:
q)cc:``a
bc!(::;10;11;12)
q)type value cc
0h
q)cc.a
10note that this is how directories work:
q)0N!1#.q
(,)!,:: | :: q)0N!1#.o (,)!,::
| ::
q)0N!1#.h
(,`)!,::
| ::
Yes, funny:
q).new1.d:1
q).new1.c:2
q)show .new1.d
1
q)type value .new1
0h
q).new1 _:`
q)type value .new1
7h
q)show .new1.d
'type
[0] show .new1.d
^
Interesting that dictionaries internally seem to keep track of their mixed-ness.
Look:
q)d:(raze (sn1n2;(1000000?8)))!raze (`a;22;33;(1000000)?1000000)
q)\t:10 type value d
0
q)\t:10 d2:delete n2 from d
145
q)\t:10 d1:delete n1 from d
182
q)\t:10 ds:delete s from d
257
q)\t:10 type value ds
0
Note deleting single outlier (`s) took longer (reproducible). Probably typed dictionaries have different storage layout.
it is not hidden, you just have to look in the right place.
Q For Mortals 3 - dictionaries chapter - not right place.
/Tutorials/Dictionaries - not right place
/Reference/DotSymbol - not right place.
please share your sources here ;)
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 13.0px Arial; color: #232323; -webkit-text-stroke: #232323; min-height: 15.0px}p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; line-height: 15.0px; font: 13.0px Arial; color: #232323; -webkit-text-stroke: #232323}span.s1 {font-kerning: none}
page 57 of Q Tips:
A namespace is actually just a mapping from a list of symbols to a list of values. To ensure that any value type can be stored in a namespace, q automatically starts the namespace with a null key mapped to the generic null value (::). If q determines that all elements of a list are of the same type, it collapses the mixed list to a vector. This is normally a good feature, as it makes future operations more efficient. But namespaces must hold all types. Including a null value as the first element prevents q from collapsing the list to vector.
I was actually asking about the place in doc about dot notation (its applicability for mixed type map only)
Thanks
Thank you for advise.
I actually would prefer dot notation where possible because of 1) parsing precedence , and, as a result, *shorter* and more concise code and 2) speed:
q)q:ab!(100 200 300;1 2 3)
q)q.a
100 200 300
q)q.a+q.b
101 202 303
q)qa+qb
'type
[0] qa+qb
q)q[a]+qb
101 202 303
q[100000?`5]:100000#enlist (200 300 400);
q)\t:100000 q[`jikio]
18
q)\t:100000 q.jikio
8
That’s why I am genuinely interested in this limitation.
I believe, q[value] calculates hash of value at runtime, and q.value calculates it at parse time.
And I still wonder WHY are the limitations of implementation which forbid q.value for untyped dictionaries.
And, as perfectionist (and kdb authors seem to be all perfectionists too, due to chosen minimalism), I would like this to be included in doc.
That’s it.
dot notation is just a special cased find+index for dict with symbol key, ignores attributes on the key using lookup via linear search; as such better to keep the domain small.
q)q:ab!(100 200 300;1 2 3)
q)q[-100000?`5]:100000#enlist (200 300 400);
q)q:(`u#key q)!value q
q)-1#q
mphia| 200 300 400
q)\t:100000 q.mphia
6223
q)\t:100000 q`mphia
49
the implementation of the lookup via . requires that the value is type 0.
On Thursday, November 8, 2018 at 12:28:07 AM UTC+2, Charles Skelton wrote:
dot notation is just a special cased find+index for dict with symbol key, ignores attributes on the key using lookup via linear search; as such better to keep the domain small.
q)q:
ab!(100 200 300;1 2 3)q)q[-100000?`5]:100000#enlist (200 300 400);
q)q:(`u#key q)!value q
q)-1#q
mphia| 200 300 400
q)\t:100000 q.mphia
6223
q)\t:100000 q`mphia
49
Thanks for implementation detail!
I wonder why “find+index” can’t be applied to any kind of list. Different key storage?
the implementation of the lookup via . requires that the value is type 0.
With all respect, but no.
This is not fully correct. There’s at least one more special case not listed above in this thread:
q){show type value x;x.a}each(a:1 2 3;b:kl`m)
0h
'x.a
[2] {show type value x;x.a}
In fact, this is the case I miss most. And domain is small…
Regards,
S.S
On Wed, Nov 7, 2018 at 10:43 PM Sanny Sanoff <sanny…@gmail.com> wrote:
Thank you for advise.
I actually would prefer dot notation where possible because of 1) parsing precedence , and, as a result, *shorter* and more concise code and 2) speed:q)q:
ab!(100 200 300;1 2 3)q)q.a
100 200 300
q)q.a+q.b
101 202 303
q)q
a+qb'type
[0] q
a+qbq)q[
a]+qb101 202 303
q[100000?`5]:100000#enlist (200 300 400);
q)\t:100000 q[`jikio]
18
q)\t:100000 q.jikio
8
That’s why I am genuinely interested in this limitation.
I believe, q[value] calculates hash of value at runtime, and q.value calculates it at parse time.
And I still wonder WHY are the limitations of implementation which forbid q.value for untyped dictionaries.
And, as perfectionist (and kdb authors seem to be all perfectionists too, due to chosen minimalism), I would like this to be included in doc.
That’s it.
On Monday, November 5, 2018 at 6:21:53 PM UTC+2, Igor M wrote:
Hi Sanny,
it happens because you have multiple values in the first case and only one value in the second case
please use the following syntax for case 1 and 2 :
zz`a
(Roundtrip: 000ms)
10 11 12
bb`a
(Roundtrip: 000ms)
10
??, 4 ???. 2018 ?. ? 17:13, Sanny Sanoff <sanny…@gmail.com>:
Hi!
There’s some hidden rule which keeps me off using dot notation for accessing dictionary properties, because it mostly never works.
Decided to nail it, and discovered following, how comes?
q) zz:
ab`c!((10;11;12);(20;21;22);(30;31;33));q) bb:
ab`c!(10 11 12);q) show zz;
name| 10 11 12b | 20 21 22c | 30 31 33
q) type zz
99h
q) show zz.a;
10 11 12
q) show bb;
a| 10b| 11c| 12
q) type bb
99h
q) show bb.a
evaluation error:type [0] show bb.a;
^
Cheers,
S.S.
–
Submitted via Google Groups
Dot notation works on global variable and not on local variables. Thats why you are getting failure.
Local variable
q) {l:ab!(100 200 300;1 2 3); l.a}
'l.a
Global variable
q)l:ab!(100 200 300;1 2 3); l.a
100 200 300
Since ‘l’ is global now, it will work inside function:
q) {l.a}
p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #000000; background-color: #ffffff}span.s1 {font-variant-ligatures: no-common-ligatures}100 200 300
For Table example:
q)t:(a:1 2 3;b:kl`m)
q)r:first t; r.a
1
On Thursday, 8 November 2018 09:47:45 UTC, Sanny Sanoff wrote: