In terms of literals, (16 16$a.)-:u:i.16 16 1
But they display differently, because that is what the standards say. But "display differently" is not something that only happens with literals. Consider, for example: 1r2 1r2 0.5 0.5 1r2-:0.5 1 Here, we have two different representations of the value "one half". They look different, but they are - mathematically speaking - the same value. Note that Arthur Whitney's K (and Q) take a very different approach. There, console output is all serialized - it's whatever would be needed to exactly reproduce that value in the interpreter. This limits what can go to the console, but makes deploying distributed systems particularly simple. And he introduces other mechanisms for displaying results, also. But for fine control you wind up using a different language. We can learn a lot by looking at how things are done in other languages. (But if we want exactly those things we should just use the other language, in my opinion.) Anyways... J was designed to teach concepts and abstractions, and one of those concepts is that "equality" in the mathematical sense is not the same thing as "equality" in the visual sense. A careful study of J will also reveal some other treatments of equality, like: 1.00000000000001-:1.00000000000000002 1 Equality is not always transitive, in J. While a variety of formal treatments of mathematics assert that equality is transitive, others assert something very different (and while in wom3 worst cases these are simple errors in other cases the reader is assumed to know these distinctions from the context where they appear, or by reference to someone's name). Anyways, at some point a person has to be pragmatic about these issues. Which reminds me of: In an early talk Ken was explaining the advantages of tolerant comparison. A member of the audience asked incredulously, “Surely you don’t mean that when A=B and B=C, A may not equal C?” Without skipping a beat, Ken replied, “Any carpenter knows that!” and went on to the next question. -- http://keiapl.org/anec/ (Paul Berry) The pragmatic reasons for this have to do with machine limitations. See also: http://en.wikipedia.org/wiki/Numerical_analysis -- Raul On Fri, Feb 28, 2014 at 8:05 AM, Björn Helgason <[email protected]> wrote: > u:i.16 16 > > is what I used to expect > 16 16$a. > to be > > - > Björn Helgason > gsm:6985532 > skype:gosiminn > On 28.2.2014 01:54, "chris burke" <[email protected]> wrote: > > > > The problem I am trying to point out is that the characters in _128{.a > > fall > > > in a no-man's land. They are ambiguous. Sometimes they are treated like > > > 8-bit extended ASCII. Sometimes they are treated like UTF-8 compression > > > characters. > > > > I don't agree that _128{.a. fall into a no-man's land. > > > > J text is utf8, so _128{.a. are ordinary bytes. They are not any kind of > > characters, since they are not valid utf8. > > > > Earlier versions of J (J5 and earlier?) treated them as 8-bit extended > > ASCII, but this is no longer the case. > > > > > > On Thu, Feb 27, 2014 at 3:14 PM, Don Guinn <[email protected]> wrote: > > > > > Everybody wants to talk about handling APL characters. I'm for that > too, > > > but first we need to make it clear on how to handle UTF-8 or > > UTF-whatever. > > > The problem I am trying to point out is that the characters in _128{.a > > fall > > > in a no-man's land. They are ambiguous. Sometimes they are treated like > > > 8-bit extended ASCII. Sometimes they are treated like UTF-8 compression > > > characters. > > > > > > u,U > > > þþ > > > shows how display got confused. Is it supposed to display UTF-8? Or is > it > > > supposed to display 8-bit extended ASCII? Looks like it ran into an > error > > > attempting to display it as UTF-8 so it switched to 8-bit extended > ASCII. > > > ": output is always literal. So > > > #":u,U > > > 6 > > > a.i.":u,U > > > 195 131 194 190 195 190 > > > switched all the 8-bit extended ASCII to UTF-8. But sometimes it just > > puts > > > in � when it can't figure out what to do. Maybe it should have > displayed > > > the 8-bit extended ASCII instead. The trouble is that the character þ > is > > > ambiguous. > > > > > > The reason why 7 u: 254{a. is an error is because 7 u. specifically has > > > UTF-8 or ASCII as a right argument. 254{a. is neither. It is what I > have > > > been calling 8-bit extended ASCII. > > > > > > Before we can even hope to effectively deal with APL characters we need > > to > > > be very clear on how to handle UTF-8. > > > ---------------------------------------------------------------------- > > > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
