Raul Miller-4 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. > In other words, we are having here dynamic type.
> 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. > Exactly, there's no shape information here. In fact, the type you give is just int^6, i.e 6 ints, due to the associativity of the product of types, and since the unit type is, well, exactly like 1 wrt multiplication, it does not play any role here. More generally, 1*int is to be isomorphic to int in monoidal category. > 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... > What you're doing here, and then continue with more examples, is to try to build the type system starting from bits. That's not how we would like to use types however, but rather to just specify explicitly some types called, say, Int32, Int64, Word32, SingleFloat, etc. Types are only half of the story---there are also operations over types, and that's also what we need to take into account when talking about types. We should be provided with some operation like + that sums Ints, etc, and it is not necessary to have them defined at the bit level at all. So we start with some number of types and operations, and then algebraically build new types as well as operations, but the starting choice of types and corresponding operations is not necessarily fixed. More importantly, there is no some canonical choice of starting types from which everything else could be built up. > 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 > > -- View this message in context: http://old.nabble.com/algebraic-data-types-tp33260423s24193p33268577.html Sent from the J Chat mailing list archive at Nabble.com. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
