I know I encountered this problem years ago, when 0$0 was changed to '' in the 5!:5 result (IIRC). I believe the 0$0 that I was using was boxed and was part of a list of boxes.
Roger fixed that, and my problems went away. I am glad to see that Roger expects to change the error reported here, because the 5!:5 form is a good portable way to pass values between machines and versions, and it is important to make sure that the values received are the same ones that were sent. Henry Rich > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Roger Hui > Sent: Tuesday, August 15, 2006 6:34 PM > To: Beta forum > Subject: Re: RE: [Jbeta] Linear Representation > > > By the way, a particular application failed to > > run because a J6 empty vector turned out not to > > be 'identical' to the corresponding J5 empty > > vector and it was difficult to see, via their > > linear representation, that they were actually > > different in some sense. > > There had been no changes in 5!:5 on empty vectors > or boxed empty vectors between J6 and J5. > > > > ----- Original Message ----- > From: Jose Mario Quintana <[EMAIL PROTECTED]> > Date: Tuesday, August 15, 2006 2:17 pm > Subject: RE: [Jbeta] Linear Representation > > > > Behalf Of Mark D. Niemiec > > > Jose Mario Quintana <[EMAIL PROTECTED]> wrote: > > > > "5!:5 y Linear. The linear representation is a string > which, when > > > > interpreted, produces the named object." > > > > > > [...] > > > > > > One of the idiosyncracies of empty arrays is that they are > > > considered equal, even if they have different data types. > > > This is rarely important, but the underlying data type can > > > reveal itself when fill elements are being used (as with {. or {:) > > > and certainly with 3!:0 > > > > > [...] > > > A problem with 5!:5 and 5!:6 is that they produce > > representations that are > > > equal to the original, but not necessarily IDENTICAL in all > > > aspects. For example, they do not preserve type: > > > > > > type f0=:-~1.5 NB. real clone of 0 > > > 8 > > > f0 > > > 0 > > > type "[EMAIL PROTECTED]'f0' NB. This forgets the 'realness' of the zero > > > 1 > > > f0+!20x NB. real 0 trumps extended precision > > > 2.4329e18 > > > ("[EMAIL PROTECTED]'f0')+!20x NB. freeze-dried and reconstituted 0 > > > does not > > > 2432902008176640000 > > > > > > (and, in the cited example, lr does not preserve the type of the > > empty> list either). > > > > > > > Behalf Of Roger Hui > > > It comes down to whether there is one empty vector > > > or more than one empty vector. (*) > > [...] > > > > > > I will probably change 5!:5 to preserve the > > > > That seems to make more sense than the alternative of clarifying > > that "when > > interpreted, produces the named object" but it might not always be > > 'identically' the same object. > > > > By the way, a particular application failed to run because a J6 > > empty vector > > turned out not to be 'identical' to the corresponding J5 empty > > vector and it > > was difficult to see, via their linear representation, that > they were > > actually different in some sense. > > > > > distinction between <i.0 and <'' without answering > > > (*) one way or the other. > > > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
