The major limitation of SAC, at present, is its lack of a one-bit Boolean data type. ... If somebody wants to volunteer to do the one-bit Boolean support for SAC, we can find out!
I believe a high performance implementation of bit booleans for all the relevant APL primitives requires several years of work. Intellectually challenging and rewarding work. See, for example, the bit (ha!) about x[b;…;] in In Praise of Magic Functions, Part II <http://www.dyalog.com/blog/2015/06/in-praise-of-magic-functions-part-two/> On Thu, Apr 28, 2016 at 9:44 AM, Robert Bernecky <[email protected]> wrote: > One of the great advantages of SAC is that you can solve the > "...define words like..." problem with it, with NO loss of performance > or clarity. > > In fact, you can define those functions and give them names of +, -, *... > without confusion. These can be used to expand the standard library > of functions, or they could be placed in a different library, such as > unums. [Objections to unplanned execution of unums are, IMO, the same > as objections to unplanned execution of complex numbers, etc.] > > SAC has a clean (ish), minimum set of primitive functions defined in > the compiler, then defines EVERYTHING else as stdlib (standard library) > code. For example, the scalar functions over arrays are all defined > in the stdlib, in terms of data-parallel operations over operations > on scalars. This simplifies the compiler considerably. > > Moving array-based function definitions to a standard library > offers SAC two significant advantages over languages like APL and J, > which still allow the language implementor to rule over (and overrule) > the user: > > - Introduction of new data types can be done by ANYBODY, without having > to beg, bribe, or become the implementor. > > - The array optimizations in the sac2c compiler give those new data > types equivalent performance to hand-coded, specialized versions > of them. > > In fact, SAC usually offers superior performance to primitives > that are > hand-coded in C (or equivalent language), because the functions > written in > SAC are exposed to the compiler's optimizations, often generating > better-performing code. Elimination of array-valued temps is key > here, > because of the dismal performance of contemporary memory subsystems. > As a trivial example, consider: > > z = A + transpose( B); > > If transpose is written as a high-performance built-in primitive, > as it is in APL and J, > then things work this way: > > tmp = transpose(B); // Transpose the array and generate an > array-valued > // intermediate result, tmp. > z = A + tmp; // Do the addition > > This is very slow, because it has to write, then read, all > elements of tmp, > and perform array allocation, deallocation, and initialization of > tmp's > array descriptor. > > In SAC, the transpose and tmp are optimized away > by one or more flavors of "with-loop folding", > so the resulting C code would be something like: > > for( i=0; i< shape(A)[0]; i++) { > for( j=0; j<shape(A)[1]; j++) { > z[i,j] = A[i,j] + B[j,i]; > } > } > > Also, in SAC, gauss-jordan, etc., would work on unums with no changes > to the J/APL code, and with no need to kowtow to an implementor > (or to become one yourself). > > The major limitation of SAC, at present, is its lack of a one-bit Boolean > data type. Introduction of one-bit Booleans, which would require modest > sac2c compiler enhancements, would do a lot for unums. > Perhaps Sven-Bodo has something to say about this topic, which > is why I've CC'd him on this message. > > However, there are still a few places where specialized primitives (or > stdlib > functions) could outperform such an implementation, as described above. > I suspect that they are, in practice, not frequently encountered. > If somebody wants to volunteer to do the one-bit Boolean support for > SAC, we can find out! > > Bob > > On 16-04-28 06:16 AM, Raul Miller wrote: > > Btw, just to be clear: when I said "implement in J" I did not mean > > "modify the interpreter" or anything like that. I would not expect > > (p.inv) to work on native unums. > > > > Instead, I meant to define words like add, sub, mul, div, fmt, ... > > which work like +, -, *, %, ": and maybe a few others on some > > representation of unums. (Perhaps a box of bits - each box > > representing one unum and the contents of each box being a list of > > bits. This will not be high speed, but would be good for a first > > implementation because of its transparency.) > > > > Then, once you have that, you use those to build relevant algorithms > > using these new "primitives" and see how guass-jordan reduction (or > > whatever) works with them. > > > > The question is: are these just a gimmick, optimized for a certain set > > of algorithms, or do they have general utility? (Or, if you prefer, > > the question is: how much utility does this representation have?) > > > > Thanks, > > > > -- > Robert Bernecky > Snake Island Research Inc > 18 Fifth Street > Ward's Island > Toronto, Ontario M5J 2B9 > > [email protected] > tel: +1 416 203 0854 > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
