Hi Louis,
most people will assume that
A←A,1 2 3
simply appends 1 2 3 to A. But don't
bet your life on that:
)CLEAR
CLEAR WS
∇Z←A B
[1] ⊣⎕EX 'A' ◊ Z←42,B
[2] ∇
GNU APL currently copies the array in this situation. You can see the code
that does this in the function ScalarFunction::eval_scalar_AB.
The reuse of one of the arguments is what I attempted to do with my early
experiments. When it works, it makes certain benchmarks incredibly fast,
but in order
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 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
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
Hi Elias,
thanks for explaining your position.
My concern about free software is not so much political but more
practical.
If I look at programming languages, then my impression is that
those languages that make the
exchange of sof
Hello Jürgen, and thanks for your thorough reply.
In terms of the usefulness of Key, I don't disagree with you. I'd certainly
like to see even more flexible solutions.
Where we do disagree is what the goal of free software is. Arguably there
are probably as many goals as there are people.
What f
Hi Elias,
thaks. The explanation is a bit clearer but the problems remain.
Key is a non-standard APL function and we should be careful with the
implementation
of non-standard functions.
Every function in GNU APL is an invitation to use it. If the
fu
The key function is better described in the Dyalog reference manual, on
page 153 here:
http://docs.dyalog.com/16.0/Dyalog%20APL%20Language%20Reference%20Guide.pdf
Essentially, it's a grouping function. It's used to create groups of
similar things, and apply a function on the individual instances.
Hi Elias,
I am not quite in favour of it and it has problems.
It is not on my keyboard (even though I am using a Dyalog
keyboard).
Not to talk about other keyboards.
It does not really look like need-to-have function and I suppose
How about implementing the key function, ⌸?
It's described in this article on the Dyalog site:
https://www.dyalog.com/blog/2015/04/exploring-key/
Jürgen, are you in favour of this function?
Regards,
Elias
15 matches
Mail list logo
