If you compile GNU APL with neither SQLite nor Postgres available, there
will be an undefined variable ‘p’ in Quad_SQL.cc.
Attached is a patch that fixes this issue.
Regards,
Elias
Index: src/Quad_SQL.cc
===
--- src/Quad_SQL.cc (
I wanted to use GNU APL to work on a dataset of star data. The file
consists of 34030 lines of the following form:
892376 3813 4.47 0.4699 1.532 0.0077306.69 0.823 0.4503 0 ---
1026146 4261 4.57 0.6472 14.891 0.1211742.56 1.405 0.7229 0 ---
1026474 4122 4.56 0.5914 1.569 0.006 3
I'm regularly getting a crash that I have not seen before. I don't know
when it was introduced but it must be within the last few months. Here's
the stack trace:
==
Assertion failed: items
in Function: at
in file:
Elias,
In just about any language, iterative string catenation is a real
performance killer owing to the repeated growing memory allocation
which just gets bigger with every iteration.
I would restructure the algorithm to work more like this: (sorry, on
a Windoze box and no APL, so metacode only
Hi Elias,
thanks, applied in *SVN 850*.
/// Jürgen
On 01/17/2017 04:11 PM, Elias Mårtenson wrote:
If you compile GNU APL with neither SQLite nor Postgres available,
there will be an undefined variable ‘p’ in Quad_SQL.cc.
Attached is a patch that fixes this issue.
Regards,
Elias
Hi Elias,
do you by chance know if this happens with *⎕SQ**L *or with SQL as
native function or both?
Looks like the dump is coming from the SQL area.
I remember that I replaced
*map providers;**
*
in *apl-squlite.cc*
with:
*static Simple_string providers;**
**static Simple_string connecti
I wasn't using the SQL stuff. The crash you see is happening in the code
for the backend connection to Emacs. This is code that hasn't been changed
(at least by me) in a very long time.
I could debug this myself, now that I noticed this, but before doing so, do
you have an idea?
The crash happene
You are right that doing array allocations in any language is slow, and in
order to get some kind of baseline to compare things to, I implemented the
same algorithm in Lisp, and I did so in the worst possible way: By
completely reallocating the array for each row, and copying the old content
into t
Sorry, I forgot to paste in the runtime for the APL version. It's
approximately *6:30*. That's only 7 times slower than the Lisp version
doing the same thing which is not fantastic, but acceptable I suppose.
Here's the source to the Lisp version. As you can see, it tries really hard
to replicate t
Hi Elias, Nick,
I would believe that most of the time in Elias' function is spent
in
Z ← Z⍪ pattern convert_entry¨ (line≠separator) ⊂ line
→next
more precisly in 'Z⍪'
. This make the function run in quadratic time because
Z gets bigger and bigger
On 18 January 2017 at 04:10, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:
> What I do not like about *⎕CSV* (actually I am only guessing here because
> I dont know what it reallly does,
> but I assume it is specifically for comma separated lists) is that it is
> supposedly only works
Hi Elias,
I believe in principle what we want is something like this:
Z←FOO¨Z←⎕FIO[N]
'filename'
where ⎕FIO[N]
reads 'filename'
line by line putting each line j into the nested item Z[j]
and FOO is a decoding function tha
Rather than jump to adding new quad functions, I'm wondering what the
timing of reading that CSV file is when you optimize the APL code like the
few suggestions made by Juergen.
Specifically, we all know APL is a dog when it comes to looping and doing
one thing at a time. Reading the whole thing
I always feel GNU APL kind of slow compared to Dyalog, but I never really
compared two in large dataset.
I'm mostly using J now for large dataset.
If Elias has the optimized code for GNU APL and a reproducible way to measure
timing, I'd like to compare it with Dyalog and J.
> On Jan 17, 2017, at
On Tue, Jan 17, 2017 at 7:39 PM, Xiao-Yong Jin
wrote:
> I always feel GNU APL kind of slow compared to Dyalog, but I never really
> compared two in large dataset.
> I'm mostly using J now for large dataset.
> If Elias has the optimized code for GNU APL and a reproducible way to
> measure timing,
It doesn't work.
I got many unknown type name _Atomic_word error.
./../Parallel.hh:70:38: error: unknown type name '_Atomic_word'
inline int atomic_fetch_add(volatile _Atomic_word & counter, int increment)
^
./../Parallel.hh:74:33: error: unknown type name '_A
request for improvement when specifying a specific workspace to load on the
command line. (avoiding CONTINUE even if it EXIST)
well, we can discuss about it. To me, when we request a specific workspace it
should bring that workspace, not CONTINUE.
my 2 cents,
Xtian.
[xtian@xtian:/home/xtian]
I work couple of hours this evening to try to fix the "array-bounds" problem,
(on rastbery pi 3 (very slow to compile))
and I got an easy solution for the first two warnings aka: Assert(r=0
&& r
https://gcc.gnu.org/ml/gcc/2009-09/msg00270.html
Juergen, I found this link that may possibly explai
18 matches
Mail list logo
