zholos / qml Goto Github PK

As title

--disable-fortran to allow building most of qml without gfortran.
--disable-lapack for a fast and light build if linear algebra routines aren't needed.

All qml routines will still be available but return 'disabled.

This issue isn't a problem as far as I can tell, but the behavior seems very strange to me, so I wanted to ask whether there is a simple explanation and whether it could be affecting other functions negatively.

In the example below, I

1. Start a new kdb 3.4 process.
2. Time the built-in exp function (first execution is slow because of cold-start).
3. Load qml (built from current git master).
4. Time the built-in exp function again and observe an unexpected and significant speed-up (1,710ms vs 2,511ms)
5. Time .qml.exp and observe a further (slight) speed-up, suggesting exp didn't simply get overridden by qml.exp somehow.

q)\t exp 100000000?1f
2776
q)\t exp 100000000?1f
2511
q)\t exp 100000000?1f
2511
q)\t exp 100000000?1f
2511
q)\l qml.q
q)\t exp 100000000?1f
1710
q)\t exp 100000000?1f
1710
q)\t exp 100000000?1f
1710
q)\t .qml.exp 100000000?1f
1698
q)\t .qml.exp 100000000?1f
1698
q)\t .qml.exp 100000000?1f
1698

gfortran does not pass the compile checks - how do you build this on windows?

In file included from util.h:6:0,
                 from wrap.h:4,
                 from libm.c:3:
../include/k.h:85:0: error: "isnan" redefined [-Werror]
In file included from libm.c:1:0:
/usr/i686-pc-mingw32/sys-root/mingw/include/math.h:376:0: note: this is the location of the previous definition

isnan (and finite and log) from math.h are defined conditionally for WIN32 by k.h.

Solutions:

• patch k.h to remove isnan — unreliable since k.h changes from time to time
• fetch specific revision of k.h from code.kx.com and apply precise patch
• #undef isnan after including k.h before including math.h (check whether k.h defines any reserved identifiers that could break math.h)
• #undef WIN32 and _WIN32 before including k.h (perhaps redefine afterwards)
• separate code so k.h and math.h aren't used in the same translation unit — overhead, especially in routines generated by wrap.h

Related:

• check how nf and wf, which are defined differently for WIN32, are used in code — consider replacing with NAN and INFINITY

It would be useful to have functions for sample skewness and kurtosis.

as title .

As mentioned in README of KxSysrems/kdb :

• This is not a high-availability hosting service
• Updates to the repo may break your application
• Code refactoring might return 404s to your application

Therefore, I believe it's better to include the content of k.h in this repo instead of downloading during compilation.

Right now (2017.07.25), when I try to compile qml. It fails because the content of iniclude/k.h is "404 not found".

A simple test case:
a:500 500#250000?1.0
a:.qml.mm[a;flip a]
.qml.mchol[a]

In particular I get a matrix full of 0n for larger matrix

A simple solution I came up with borrows from J software's implementation of Cholesky. found here:
http://code.jsoftware.com/wiki/Essays/Cholesky_Decomposition

Here is the code I used which recursively calculates the cholesky for larger matrices using smaller matrices
The Code assumes upper triangular Cholesky: I added this function to .qml
.qml.mchollarge:{[m] $[100>l:count m;
.qml.mchol[m];
[a:.5*l;
A:m[b;b:til l-floor[a]];
B:m[c:ceiling[a]+til l-ceiling[a];b];
C:m[c;c];
L0:.qml.mchollarge A;
L1:.qml.mchollarge C-.qml.mm[T: .qml.mm[B;.qml.minv A];flip B];
Z:(count first L3;count L3:flip .qml.mm[T;L0])#0f;
(l;l)#raze (L0,'L3),(Z,'L1)]]};

NLopt