Looking at the specification for unums, I'm not sure how they would actually be implemented.
Supposedly, their values are supposed to represent a range of values, and operations on unums are supposed to create results which represent all values within that range. How does that work, for something like subtract, or divide? Thanks, -- Raul On Thu, Apr 28, 2016 at 12:44 PM, 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
