//it seems to me that it (a) it starts out with less precision than floating point (because of the extra bits being used for representing an estimate of accuracy)//
The size of these things is variable (within an algorithm-defined range), so you don't necessarily start with less precision unless you're REALLY constrained (or unless your data points really are that imprecise). In the process of computation you'll have much more data moving around, because the range of the values will sometimes split the computation into multiple parts (from what I can understand), and that'll make the algorithm have different performance characteristics. I'm impressed -- this seems like a very thoughtful design. I'm not sure it's really practical, but it's definitely well thought out. On Thu, Apr 28, 2016 at 10:15 AM Raul Miller <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
