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
