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
