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
