rocuinneagain
Forum Replies Created
-
rocuinneagain
MemberSeptember 6, 2022 at 12:00 am in reply to: Accumulators – Access additional list / columnYes that’s much cleaner – as you only ever compute one value
c2
and only look back 1 step. this will do exactly as you need. -
rocuinneagain
MemberSeptember 5, 2022 at 12:00 am in reply to: Accumulators – Access additional list / columnchanging
c
toprev[c]
looks to be what was missingq)update c2:fills ?[(c1>prev c1) or prev[c]<prev c1;c1;0N] from t c c1 c2 -------- 30 10 10 40 20 20 25 5 20 20 25 25 4 5 5 4 4 4 1 3 4
-
rocuinneagain
MemberSeptember 5, 2022 at 12:00 am in reply to: Accumulators – Access additional list / columnLooking at your expected
c2
this logic may be what you are looking for:q)update c2:fills ?[(c1>prev c1) or c<prev c1;c1;0N] from t c c1 c2 -------- 30 10 10 40 20 20 25 5 20 20 25 25 4 5 5 4 4 4
-
m'[x]
is not parallel executionThere can be cases where the overhead of using multiple threads can make execution slower than single threaded. (.i.e performing many small operations)
.Q.fc
is available to help in some of these cases.https://code.kx.com/q/ref/dotq/#qfc-parallel-on-cut
If you measure memory usage with
ts
note that it only sees usage in main thread. It does not sum usage from all threads. So you cannot compare results directly.q)\ts {til 10000000;x}'[til 1000] // \ts shows real memory usage 5395 134250848 q)\ts {til 10000000;x}':[til 1000] // \ts only sees memory usage in main thread - not the sum of threads 5612 33408
q)\ts {x}'[til 100000] // Single core 8 4746288 q)\ts {x}':[til 100000] // Slower due to parallel overhead 13 4194864 q)\ts .Q.fc[{x}][til 100000] //Faster way to use multiple cores 1 3146512
-
rocuinneagain
MemberAugust 19, 2022 at 12:00 am in reply to: What is the difference between wj and wj1?You are seeing the same results as your
t2
has an entry for every secondIf we swap
til 9
for2*til 9
we can create gaps and then you can see the differences wherewj
will bring in prevailing values butwj1
will not.t1:([]sym:3#`ibm;time:07:01:01 07:01:03 07:01:05;price:100 101 105); a:101 103 103 104 104 107 108 107 108; b:98 99 102 103 103 104 106 106 107; t2:([]sym:`ibm; time:07:00:58+2*til 9; ask:a; bid:b); c:`sym`time; w:-2 1+:t1.time; o1:wj[w;c;t1;(t2;(max;`ask);(min;`bid))]; o2:wj1[w;c;t1;(t2;(max;`ask);(min;`bid))]; o1~o2; // 0b; q)wj[w;c;t1;(t2;(::;`ask);(::;`bid))] sym time price ask bid ------------------------------------------ ibm 07:01:01 100 101 103 103 98 99 102 ibm 07:01:03 101 103 103 104 99 102 103 ibm 07:01:05 105 103 104 104 102 103 103 q)wj1[w;c;t1;(t2;(::;`ask);(::;`bid))] sym time price ask bid ---------------------------------- ibm 07:01:01 100 103 103 99 102 ibm 07:01:03 101 103 104 102 103 ibm 07:01:05 105 104 104 103 103
-
rocuinneagain
MemberAugust 17, 2022 at 12:00 am in reply to: Is there a way to call .Q.hmb and not have it do SSL certificate verificationFrom: https://code.kx.com/q/kb/ssl/#tls-client-mode
By default, kdb+ will try to verify the servers certificate against a trusted source, using the certificates from
SSL_CA_CERT_FILE
orSSL_CA_CERT_PATH
to verify the servers certificate. If you don’t wish to verify a servers certificate, set$ export SSL_VERIFY_SERVER=NO
-
In the basic kdb+ tick the RDB does do the write at EOD.
No data is lost, it will buffer in the outbound queue from the TP process.
As long as you have a safe memory overhead for this buffer then the system will continue to run.
Queries will also buffer while the RDB is performing the write.
More advanced architectures avoid the RDB being blocked, such as all the KX platforms. .e.g https://code.kx.com/insights/1.1/
-
rocuinneagain
MemberJuly 29, 2022 at 12:00 am in reply to: How to write local function which can be called from different levelsYou could pass it in to a projection
q)f:{[xF] g:{[xG] xG + 2}; h:{[g;xH] g[xH] + 3}[g]; g[xF] + h[xF]} q)f[40] 87
Or composition in this basic case
q)f:{[xF] g:{[xG] xG + 2}; h:+[3] g @; g[xF] + h[xF]} q)f[40] 87
-
Some ways:
q("{((),x)#y}", numpy.string_("iq"), numpy.string_("t")) q("{value"select ",string[x],"from ",string y}", "iq", "t") q("select %s from %s" % ("iq","t")) q("{?[y;();0b;{x!x}(),x]}", numpy.string_("iq"), numpy.string_("t"))
- Using # https://code.kx.com/q/ref/take/
- Using value https://code.kx.com/q/ref/value/
- Python string formatting
- Functional select https://code.kx.com/q/basics/funsql/
Functional selects are the most powerful way https://code.kx.com/q/wp/parse-trees/
-
See docs for more on how the library handles difference between symbols and strings:
https://qpython.readthedocs.io/en/latest/type-conversion.html#string-and-symbols
(Answer above updated to use
numpy.string_
to pass symbols as needed) -
You want to store it in a global variable in q?
Then you can use a lambda and
::
orset
q('{`mydict set x}', qdict) q('{mydict::x}', qdict)
-
Do you have any details of your specific issue or error?
This request is vague. https://stackoverflow.com/help/how-to-ask
-
Pass variable
a
to APIxxx
on remote handleh
and save to local variablet
:t:h(“xxx”;a)
More about IPC:
- https://code.kx.com/q/wp/ipc/#synchronous-queries
- Interprocess communication | Basics | kdb+ and q documentation
Formatting tips:
-
A user has written qrapidjson which implements .j.j but not .j.k
The underlying rapidjson library does allow a parse flag kParseNumbersAsStringsFlag
http://rapidjson.org/namespacerapidjson.html#a81379eb4e94a0386d71d15fda882ebc9
Although in a quick test the library looks to already parse numbers without decimal places as longs by default:
q)rapidjson:.p.import`rapidjson q)rapidjson[`:loads]["1471220573128024107"]` 1471220573128024107 q)type rapidjson[`:loads]["1471220573128024107"]` -7h q)type each rapidjson[`:loads]["[1471220573128024107, 1471220573128024107.0]"]` -7 -9h //Same for default json library in python q)json:.p.import`json q)json[`:loads]["1471220573128024107"]` 1471220573128024107 q)type json[`:loads]["1471220573128024107"]` -7h
-
iasc gives you the sorted idexes which you can use
q)update sVec:sVec(@)'iasc each sNum,asc each sNum from tbl sVec sNum ----------- a b c 1 2 3 a b c 1 2 3 a b c 1 2 3