Well... an array type that could be two or three elements would be different from an array type for only two elements and also would be different from an array type for only three elements.
Ultimately, though, it's just counting possibilities -- mostly you could take 2&^. on the underlying numbers to count bits. And that, I think, is its biggest weakness. Conceptually, this means that four 8 bit characters and one 32 bit integer are the same. If the variables remain unbound (leaving open the possibility of using different numbers of bits for characters and "integers") the system works, but overall I agree with you that it places too much emphasis on the wrong issues. I think the methodology would be more properly named "an algebra of data sizes". -- Raul On Fri, Feb 3, 2012 at 7:13 PM, Roger Hui <[email protected]> wrote: > The methodology seems ill-suited for arrays, if it has to make such a big > deal out of the difference between 2-element vectors and 3-element > vectors. For APL/J/K programs, I'd want the type system to readily > distinguish between matrices of shape (r,n) for fixed r, matrices of shape > (n,c) for fixed c, ..., at the very least. > > > > On Fri, Feb 3, 2012 at 2:40 PM, Raul Miller <[email protected]> wrote: > >> http://blog.lab49.com/archives/3011 >> >> It's amusing to try to think of how to characterize J arrays using >> that methodology. >> >> Conceptually speaking, J has one type: array, and it's statically >> typed. But other concepts can either specialize that type (let's say >> that we have a context where we know that the array contains real >> numbers) or generalize that type (in the context of parsing we might >> need to deal with verbs). >> >> But, for example, the type of the result of i. 2 might be int*int and >> the type of the result of i. 3 might be int*int*int. So what is the >> type of i. i. 4? >> >> Maybe 1*(int)*(int*int)*(int*int*int)? >> >> No, that does not work -- we are not dealing with shape, yet, instead >> we want to count elements. So the value representing the type of an >> empty array is 1, and the type of a bit is 2, and the type of 2 bits >> is 4... >> >> So a 32 bit int would be 2^32 and a 64 bit int would be 2^64, and the >> type of a 3 element list of 32 bit ints would be 2^64*3 where the type >> of a J array is, approximately, _ (it's not really infinite since >> computers are finite, but on a 32 bit machine the type value that >> represents a 34 element list of 32 bit ints is too large to represent >> using a 64 bit floating point number, and J arrays can get a lot >> larger than that...) >> >> #":2x^32*34 >> 328 >> >> Similarly, the type value for an arbitrary precision integer might >> also be approximated as infinity... (In essence, it's the number of >> distinct values which and be represented using that data type -- so >> floating point and complex numbers should have type values which are >> slightly smaller than the amount you would get if you counted their >> bits and raised 2 to that power.) >> >> Of course, I am not supposed to actually compute these type values, >> but it's an interesting perspective. >> >> -- >> Raul >> ---------------------------------------------------------------------- >> 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
