Hi Elias,
I believe the gain of coalescing functions (or slicing the values
involved) is somewhat limited and occurs
only when your APL values are small. For large values computing
one function after the other has a better cache
locality. And it has a
Hi,
I have revived Elias' in-place optimization for A⍴B and ,B
now usinng a different
way of figuring if B is in use. SVN 445.
/// Jürgen
Cool :-)
Speaking of this, I did spend quite a bit of time some time ago to try to
figure out an easy way to get generic copy-on-write semantics, but I never
came to a satisfactory conclusion. I might revisit it later.
Have you thought about it? It is, after all, related to this specific
optimisa
Hi Elias,
normally APL values are not written to. The exception is indexed
assignment.
I believe the clone() call in Symbol::resolve()
can be skipped completely.
This is probably the most frequently used clone() case. I
suppose copy-on-write semantics is
I ran into this after updating to 445.
This is in a pendent function.
''≡0⍴value
0
8⎕cr value
┌→───┐
│unix│
└┘
''≡0⍴'unix'
1
8⎕cr 'unix'
┌→───┐
│unix│
└┘
--
"The secret to creativity is knowing how to hide your sources."
Albert Einstein
http://soundcloud.co
Back on the subject of aplwrap integration:
I'm seeing a GNU APL behavior that I don't understand, and would
appreciate some hints on where to look. I don't necessarily consider the
following behavior to be buggy, I just want to be able to figure out how
and why it's happening so I can dig into th
