Jürgen,
Not to issue AXIS ERROR's on primitive functions where IBM APL2
does seems to be a fairly large deviation from Gnu-APL's claim to be
IBM APL2 compliant. Yes, having the ability to use axis specifications
with defined functions is a desirable extension to the language as long
as the
On the subject of copying arrays, I was wondering, in GNU APL, where in code
such as
A <- A,1 2 3
B <- A,4 5 6
A <- A,7 8 9
(in that order) A is copied. It has to be copied in the third line (unless some
weird bookkeeping is done) as B referred to A's previous value, but can be
modified in pla
Hi Fred,
this is actually a language extension which has a deeper background.
I define a language extension to be a (different) behaviour of the
interpreter when
the standard or the IBM language reference return an error.
Sometimes extensions
are introdu
Hi Blake,
The state of GNU APL is, I believe, this:
I am not aware of any unnecessary copying of arrays in GNU APL.
There were some suspicions
claimed earlier that some copying could be avoided. But it then
turned out that removing these
Hello Jürgen,
The IBM 'APL2 Programming: Language Reference' suggests that
axis specification is not allowed with the first function in that
'Figure 7. Functions and Operators That Allow Axis Specification', page
45, does not list 'First' by the '↑' symbol, whereas ravel, catenate
and la
In my own tests, I drew the conclusion that simply paralellising functions
over the arrays, and doing so on a function by function basis results in
too much time wasted on bookkeeping and waiting for each step to finish.
In my own prototype implementation, I implemented this by having functions
no
Hi Ellas,
I remember your earlier work and comments. In fact, that is the source of
my knowledge of this.
Putting more features on a base with known issues is problematic for the
following reasons:
1. The time and effort it would take to secure the base is being spent
elsewhere.
2. Adding ne
Hello Blake,
I agree those are important points too. Some time ago, I spent time trying
to improve those things. Unfortunately, my approach turned out to be a dead
end. I have some other ideas but those require a significantly different
underlying architecture. Essentially, it requires a garbage c
My list would be different:
1. don't clone arrays unnecessarily
2. improve support for parallel processing
With these, GNU APL would be much more efficient. I think moving the focus
to CPU and memory efficiency is much more important than adding extensions
of any sort.
--blake
On Tue, Jul
Thank you Jürgen,
I think we understand each others positions, and agree that they are not
entirely the same.
That said, your points are very well taken, and for the most part I
actually agree with you.
I have a wishlist of features that I personally believe are important. For
the most part, the
10 matches
Mail list logo
