[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] using c libs in apl?

From: Juergen Sauermann
Subject: Re: [Bug-apl] using c libs in apl?
Date: Wed, 8 Feb 2017 16:49:53 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

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.


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


and the relevant code is at


It would simplify using external libraries a lot.

On Feb 4, 2017, at 7:38 AM, Juergen Sauermann <address@hidden> wrote:


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, address@hidden wrote:
is there method for loading a c lib and using it in apl ? cdecl? like this in fpc?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]