What I wanted was for the sequence of digits to be unique up to leading zeros, so that (-:/@,:"1) -: (=&#."1) . That property is true for nonnegative representations, but with negative numbers we have 0 _1 0 1 and _1 1 0 1 as possibilities. It's not simple to move between representations if we allow both of those.
Marshall On Mon, Dec 12, 2011 at 8:57 PM, Henry Rich <henryhr...@nc.rr.com> wrote: > ? What 'uniqueness' do you mean? With only the MSB made negative, there > is a unique representation of any value in n bits. It is true that _3 is > > _1 0 1 > _1 1 0 1 > _1 1 1 0 1 > > etc, depending on the length of the representation. > > Henry Rich > > On 12/12/2011 8:44 PM, Marshall Lochbaum wrote: > > So something like this: > > (-@(<&0) ,. #:) i:5 > > _1 0 1 1 > > _1 1 0 0 > > _1 1 0 1 > > _1 1 1 0 > > _1 1 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 > > > > With that we lose all hope of uniqueness, though. > > > > Marshall > > > > On Mon, Dec 12, 2011 at 8:20 PM, Henry Rich<henryhr...@nc.rr.com> > wrote: > > > >> Agreed. What I'm saying is, make the 2's-comp sign bit a _1, and all > >> will be well. > >> > >> #: _10 > >> 0 1 1 0 > >> > >> I didn't know it did that! That seems wrong: > >> > >> #: _10 20 > >> 1 0 1 1 0 > >> 1 0 1 0 0 > >> > >> Just change the sign of _10 from 1 to _1: > >> > >> #. _1 0 1 1 0 > >> _10 > >> > >> The nice thing about this is, you know if a number is negative you have > >> to convert it to binary in 2's-complement; and if it has a leading _1 it > >> represents a negative; so #. and #: will handle positive and negative > >> numbers smoothly, and are compatible with current code except for the > >> behavior of #: on negatives, which we agree is anomalous. > >> > >> And you can do |@:#: if you don't like the negative sign bit. > >> > >> Still differs from 2&#:, though. > >> > >> Henry Rich > >> > >> On 12/12/2011 7:44 PM, Marshall Lochbaum wrote: > >>> You can't, unfortunately. _10, for example, is #._1 0 1 1 0 , which is > >> the > >>> shortest possible representation for it. In fact, my code only gives > >>> adjacent _1 1's on powers of two. In this case it is wrong-- _8 should > be > >>> _1 0 0 , not _1 1 0 0 . > >>> > >>> Marshall > >>> > >>> On Mon, Dec 12, 2011 at 7:07 PM, Henry Rich<henryhr...@nc.rr.com> > >> wrote: > >>> > >>>> 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 > >>>> > >>> ---------------------------------------------------------------------- > >>> 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
