I had a teacher who would not say "x and y are equal" because the plural "are" implies they are NOT equal. He would say "If x is a number and y is a number ..." rather then "If x and y are numbers ... " when he wanted to allow the possibility that x is y. Some of us saw that by enforcing this kind of precision he was creating an esprit de corps for his graduate students in mathematics.
--Kip Murray Sent from my iPad > On Oct 6, 2013, at 8:34 AM, Raul Miller <[email protected]> wrote: > > Ouch.. > > I had meant to say a bit more about ambiguities, but my touchpad acted > in a way that sent the message within a small fraction of a second > from when I selected it to edit. That was not my original intent, at > least in the sense of how my personal taste would have expressed that > intent. > > Nevertheless, since my point was something along the line of > "ambiguities are, to some degree, unavoidable", perhaps it can also > serve as an illustration. > > We can squeeze ambiguities out of our expressions, but we have too > many concepts of abstraction to avoid ambiguities on all of them. > > In the case of my accidental sending of a message without content, I > can take that as an illustration of an ambiguity in the user interface > which I use to compose my email. Specifically: it has a "design > feature" where the machine can send a message nearly instantly without > me managing to use the keyboard at all. (And there are a number of > aspects about the touchpad implementation which I think could be > significantly improved, though I mostly ignore such issues.) > > All programming languages have similar characteristics. I just happen > to find J's approach to be particularly appealing to my personal > tastes. > > On a related note, $$y might be an expression for the rank of y, but > ($$) y is not. It's kind of interesting, though, to speculate on what > constraints and contexts would make ($$) into a useful operation. [If > we ignore its value, for example, it can be a mechanism for rejecting > values of y which cannot be valid shapes - but we would also need a > constraint on size unless were were prepared to ignore some denial of > service style resource overruns. (And before you entirely reject the > idea of allowing resources to be consumed without > application-imposed-bounds, realize that many web applications use > regular expressions which have been implemented with similar flaws.)] > > Thanks, > > -- > Raul > >> On Sun, Oct 6, 2013 at 9:23 AM, Raul Miller <[email protected]> wrote: >>> On Sun, Oct 6, 2013 at 8:59 AM, Henry Rich <[email protected]> wrote: >>> My view of ambiguities is less tolerant. Yes, English is a wonderful >>> language for expressing ambiguities, but it is not wonderful when you are >>> trying to avoid ambiguities. Legal writing & government regulations are so >>> ugly because that's the kind of English you are forced to use to say exactly >>> what you mean. >>> >>> Is 3 'more than' $0? I don't know. But I think it's wrong to seek the >>> answer in the result of the execution of a sentence. I could appeal to >>> >>> if. 3 > $0 do. >>> smoutput 'it's greater!' >>> end. >>> >>> as answering the question 'formally'. But then, >>> >>> if. -. 3 > $0 do. >>> smoutput 'it's not greater!' >>> end. >>> >>> I would find that my definition of 'formal' needs work. >>> >>> I don't think different expressions for the same computation represent >>> ambiguity. Ambiguity is multiple meanings for the same expression: magical >>> in poetry, abhorrent in technical writing, intolerable in a computer >>> language. >>> >>> Henry Rich >>> >>> >>> >>> >>>> On 10/6/2013 6:00 AM, Raul Miller wrote: >>>> >>>> If we think of this in J terms, we might treat "more" as a verb such as >>>> >>>> more=: > >>>> >>>> Then your first sentence becomes a question about 3 > ,2 which has an >>>> answer which matches ,1. >>>> >>>> Your second sentence would involve more work to translate to J. I >>>> could translate it as >>>> (3 > $0) +. 3 > 4 1 >>>> >>>> ... but this gives us a length error, and our distaste for errors >>>> might drive us further afield, to find another translation for "or". >>>> If we felt exploratory, we might try: >>>> >>>> or=: ; >>>> >>>> so another almost plausible translation could be >>>> ($0) ;&(3&>) $4 1 >>>> >>>> Put differently, english is a wonderful language for expressing >>>> ambiguities and translation tends to freeze some of those ambiguities >>>> in the resulting work. >>>> >>>> With J we are also faced with ambiguities, but because it is an >>>> executable notation we get another perspective on ambiguities of >>>> expression, where different expressions might achieve the same end. >>>> >>>> Thanks, >>> ---------------------------------------------------------------------- >>> 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
