I like your leading-digit-negative idea better too. Rather than prepending a leading _1, you could just change the high-order 1 to _1 .
Henry Rich On 12/12/2011 5:57 PM, Marshall Lochbaum wrote: > Those are some very good arguments. Personally, I think my version is > mathematically more well-founded (for instance, when we define the decimal > for a real number, we simply make the first digit an integer and the rest, > those after the decimal place, nonnegative and less than the base). > However, you've convinced me that your version works better within J, at > least for arbitrary use. Within particular applications a user might want > something different, but he can code that himself. > I still wouldn't recommend changing J for that nuance, though. > > I do think that #: for scalar left arguments should act the same as #.^:_1, > rather than | . Some day, when I get that source working, I might look into > that... > > Marshall > > On Mon, Dec 12, 2011 at 5:25 PM, Dan Bron<j...@bron.us> wrote: > >> Raul wrote: >>> And (* * #:@:|) achieves this result. >> >> I used (*@:] * (#.^:_1 |)) because if we're going to change #: , we need a >> consistent definition for all bases. (But I hear your implication that we >> are not going to change #: .) >> >> Oh, and I just realized that my ab1 was not a faithful reproduction of >> Marshall's verb, so in my comments below, substitute his original for ab1 . >> Sorry about that! >> >> -Dan >> >> PS: >> >> Still bugs me that 2 #: y<==> 2 #.^:_1 y doesn't hold non-scalar y . It >> contradicts the dictionary, and makes discussions like this more difficult. >> >> For example, I want to be able to say *@:] * (#: |) is the >> radix-generalized equivalent of your binary * * #:@:| (i.e. the dyad to >> your monad), but it isn't. So I have to use circumlocutions like #.^:_1 >> . >> >> I reported this in 2006; maybe someone who's got the J source to build can >> fix it? >> >> >> http://www.jsoftware.com/jwiki/System/Interpreter/Bugs06#definitionofdyad.23.3Aincomplete >> >> >> >> >> -----Original Message----- >> From: programming-boun...@jsoftware.com [mailto: >> programming-boun...@jsoftware.com] On Behalf Of Raul Miller >> Sent: Monday, December 12, 2011 5:02 PM >> To: Programming forum >> Subject: Re: [Jprogramming] How #: should have been designed >> >> And (* * #:@:|) achieves this result. >> >> #. (* * #:@:|) i: 3 >> _3 _2 _1 0 1 2 3 >> >> That's probably good enough for now. >> >> -- >> Raul >> >> On Mon, Dec 12, 2011 at 4:34 PM, Dan Bron<j...@bron.us> wrote: >>> I don't think there's a violation of a uniqueness constraint. >>> >>> Consider: for a positive scalar argument y, then #:y is unique >> (trivially). >>> And, in the approach we're discussing, when the argument is negative, as >> in >>> #:-y, then the result is just -#:y . Therefore, #:-y is also unique, and >>> furthermore distinct from #:y. That is: the results of #: are always >>> strictly non-positive or non-negative. No individual result of #: will >>> contain both positive and negative digits. >>> >>> I also wouldn't mind your proposal of (#:-y) = _1 , #: y , but I think >> the >>> -#:y approach can claim some advantages. Given: >>> >>> ab0 =: *@:] * (#.^:_1 |) >>> ab1 =: (_1 * 0> ]) ,"0 1^:(0~:+/@:[) #.^:_1 NB. Distilled >> from >>> your code >>> >>> We note first that ab0 is simpler than ab1. That means it's easier to >>> understand and implement (and debug). >>> >>> Second, the results of ab0 are easier to interpret. Knowing the >> definition >>> of both verbs, you could tell me what decimal number _1 _2 _3 represents >> on >>> sight, but with _1 8 7 7 you'd have to do some mental calculation (they >> both >>> represent the quantity _123). This advantage is cumulative when >> reasoning >>> about arrays of results (i.e., in J). >>> >>> Third, critically, the shape of ab0's results doesn't change with the >> sign >>> of its argument. This is important and valuable in a J context. For >>> example: >>> >>> _5 + 6 >>> 1 >>> _5 +&.(2&ab0 :. #.) 6 >>> 1 >>> _5 +&.(2&ab1 :. #.) 6 >>> |length error >>> | _5 +&.(2&ab1 :.#.)6 >>> >>> Moreover, this feature is particularly important for digit-arrays, >> because J >>> pads on the right, but in the positional number system, right-padding is >>> anathema. That is, prepending a _1 exacerbates a problem #: already has >> (by >>> allowing more opportunities for it to arise): >>> >>> my_array =: 2 ab1 3 2 1 >>> my_array =: my_array , 2 ab1 _1 _2 _3 >>> #. my_array >>> 6 4 2 _1 _2 _3 >>> NB. Ouch! Where'd my 3 2 1 go? >>> >>> Finally, I'd argue that the -#:y also makes intuitive sense: _123 means >>> "subtract one hundred, [subtract] two tens, and [subtract] three units". >>> Though this is subjective, it does allow one to reason about negative >>> numbers in a straightforward and expected way: >>> >>> _123 + 456 >>> 333 >>> _1 _2 _3 + 4 5 6 >>> 3 3 3 >>> 10 #. _1 _2 _3 + 4 5 6 >>> 333 >>> >>> _123 * 456 >>> _56088 >>> _1 _2 _3 * 456 >>> _456 _912 _1368 >>> 10 #. _1 _2 _3 * 456 >>> _56088 >>> >>> BTW, though I am using decimal examples, all these comments apply >> equally to >>> binary numbers, and every other base. >>> >>> -Dan >>> >>> -----Original Message----- >>> From: programming-boun...@jsoftware.com >>> [mailto:programming-boun...@jsoftware.com] On Behalf Of Marshall >> Lochbaum >>> Sent: Monday, December 12, 2011 2:55 PM >>> To: Programming forum >>> Subject: Re: [Jprogramming] How #: should have been designed >>> >>> The problem with this is that we would prefer not to use negative numbers >>> in antibase, since they can violate uniqueness of base representation. >>> There's really no solution to this--my recommendation is to just never >> feed >>> negative numbers to #: . However, an option that minimizes negative >> numbers >>> (and is very close to simply having two's complement base representation) >>> is to make the first digit negative if the number is negative. Thus #: >>> becomes >>> base =. [: |."_1@:> |.@(#:`(_1,#:)@.(<&0))&.> >>> Basically, use J's #: , and prepend a _1 if the input is negative. Then >>> reverse, box, open everything for fill, and reverse again. >>> >>> base i:5 >>> _1 0 1 1 >>> _1 1 0 0 >>> 0 _1 0 1 >>> 0 _1 1 0 >>> 0 0 _1 1 >>> 0 0 0 0 >>> 0 0 0 1 >>> 0 0 1 0 >>> 0 0 1 1 >>> 0 1 0 0 >>> 0 1 0 1 >>> #. base i:5 >>> _5 _4 _3 _2 _1 0 1 2 3 4 5 >>> >>> Marshall >>> >>> On Mon, Dec 12, 2011 at 2:09 PM, Dan Bron<j...@bron.us> wrote: >>> >>>> Maybe we should explore a different track. Forget all about the history >>> of >>>> computing hardware, and the advantages of one representation over >> another >>>> when designing circuits. In purely mathematical terms, what are the >>>> decimal >>>> digits of the base-10 number -123 ? >>>> >>>> Working backwards: >>>> >>>> _123 NB. begin >>>> -123 NB. notation->operation >>>> _1 * 123 NB. definition of - >>>> _1 * (1 * 10^2) + (2 * 10^1) + ( 3 * 10^0) NB. positional number >>>> notation >>>> (_1 * 10^2) + (_2 * 10^1) + (_3 * 10^0) NB. distribution of * >> over >>> + >>>> _1 _2 _3 +/ . * 10^2 1 0 NB. array simplification >>>> 10 #. _1 _2 _3 NB. definition of #. >>>> >>>> Thus, to satisfy the purposes of inversion, we should have: >>>> [all examples from here on are purely theoretical, and the >>>> results differ in the extant implementations of J]: >>>> >>>> 10 #.^:_1: _123 >>>> _1 _2 _3 >>>> >>>> And, analogously in base 2: >>>> >>>> 2 #.^:_1: 2b_101 NB. 2b_101 is J's >> notation >>>> for -101 in base 2 >>>> _1 0 _1 >>>> #: 2b_101 NB. #:<=> 2&#.^:_1: >>>> _1 0 _1 >>>> #: _5 NB. _5<=> 2b_101 >> (numbers >>>> are analytic) >>>> _1 0 _1 >>>> >>>> QED.* >>>> >>>> -Dan >>>> >>>> * Backwards compatibility notwithstanding >>>> >>>> PS: What implications does this have for modulus, as in _10 | 123 ? >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> 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 >> >> ---------------------------------------------------------------------- >> 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
