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
