Hi Christian,
The problem with floats for absolute times is that the standard ieee
floats have a 48-bit mantissa.
The seconds since epoch currently eats up about 32 bits of them, leaving
only 16 bits for the sub-second part.
That means that the precision of an absolute time expressed in floats
cannot be more that about
1/65000 seconds = 15 micro-seconds.
The same holds for the popen() method which opens a file, and probably
re-schedules the calling process,
resulting an unpredictable delay between the timing source (no matter
how precise it is) and the APL code
receiving it.
All this makes it difficult, if not impossible, to improve much on *⎕TS
*with its 1 ms resolution.
On the other hand we have ¯*1 ⎕FIO*, which returns the CPU's cycle
counter (which has a precision of
about 300 picoseconds on a typical 3.2 GigaHz CPU). You simply cannot
beat that precisions with any
of the timing sources that are provided by the kernel.
I cannot think of a reasonable use of an absolute time with a micro
second resolutions. I would argue
that times are either short-term (for benchmarking and the like) but
then they are relative with a high precision,
or long-term (but then ⎕TS is good enough).
I also believe that your earlier request (2016-Jun-16 ?) was about
measuring the timing of APL functions and
was not mentioning localtime() or gettimeofday(). And I did not refuse
it but rather assumed that the answer
that I gave at that time would solve your problem. BTW *⎕TS* is almost
localtime() with slightly different
offsets and milliseconds resolution instead of micro-seconds.
/// Jürgen
On 02/08/2017 05:19 AM, Christian Robert wrote:
I love that.
Of course it will possibly/eventually crash your APL session if you do
the smallest error in your parameters definition.
"libffi" as mentioned by Elias is also a great possibility, already
available by default on Fedora, CentOS-7, debian, ...
I just had to install libffi-devel to be able to run some successful
tests in C.
all this is very promising.
My last struggle with this kind of thing is that I wanted a
Quad-FIO['datetime'] (refused a year ago or so, but needed now)
able to return
a) a float meaning the current time in milli or microsecond since
epoch if called with arg=0.
b) a Quad-TS array if called with 1 arg when arg>0 and assuming it's
an epoch at milli/micro/seconds accuracy.
c) a float when arg is an array of length 7, eg: in the Quad-TS style.
I ended up to write the function in C and call it via a wrapper
function written in APL using FIO['popen'], FIO['read'] and FIO['pclose']
very painful, slow (it invoke calling an external program on each
invocation), but it work pretty well.
what I really wanted at that time was an interface to "localtime()"
and "gettimeofday()", the former using a r/w reference to a struct tm.
not easy to program the (libffi and/or the x15.c) wrappers to APL, I
agree.
Xtian.
On 2017-02-07 12:30, Xiao-Yong Jin wrote:
It would be nice if one doesn't need to write wrappers and the APL
system can do the
structure conversions within the APL interpreter. In J, you can
dlopen a library
and pass J values directly without writing and compiling C, see
http://www.jsoftware.com/help/user/call_procedure.htm
and the relevant code is at
https://github.com/jsoftware/jsource/blob/master/jsrc/x15.c
It would simplify using external libraries a lot.
On Feb 4, 2017, at 7:38 AM, Juergen Sauermann
<juergen.sauerm...@t-online.de> wrote:
Hi,
yes there is: native functions. You can load shared libraries and
⎕FX functions in
them to be called from APL code. The src/native directory contains a
few templates
that you can use as a starting point and to call your favourite
library from them.
Of course you need to provide wrappers from/to APL values to/from
the data
structures expected or produced by the libraries.
Coming back to your other problems, if you do not like the terminal
I/O of GNU APL, then
you can write your own one and call libapl from it. I have extended
libapl recently, giving
you the full functionality of GNU APL without the specific ways how
it handles terminal IO.
/// Jürgen
On 02/04/2017 02:52 AM, enz...@gmx.com wrote:
is there method for loading a c lib and using it in apl ? cdecl?
like this in fpc?
ftp://ftp.freepascal.org/fpc/docs-pdf/CinFreePascal.pdf