[Jprogramming] Strange behavior of 0x1

[Don Kelly]

The error doesn't appear in J806 Windows 10/64 bit /amd a10-7800

Don


On 2017-12-16 7:49 PM, bill lam wrote:
> On j android, it looks like that
> 0xn is evaluated as nxn
>     0x1
> 2.71828
>     1x1
> 2.71828
>     0x2
> 14.7781
>     2x2
> 14.7781
>     0x3
> 60.2566
>     3x3
> 60.2566
>
> On Dec 17, 2017 12:33 AM, "Henry Rich" <henryhrich at gmail.com> wrote:
>
>> When I try it (on a couple of different J versions) I get
>>     0x1
>> 0
>>     0x0
>> 0
>> etc.
>>
>> If your error persists please run
>>     9!:14''
>>
>> to indicate what version you are running, and report the error again.
>>
>> Welcome to J!
>>
>> Henry Rich
>>
>> On 12/16/2017 6:19 AM, rouanth at gmail.com wrote:
>>
>>> Hi.
>>>
>>> Could someone please shed some light on the following behavior:
>>>
>>>      1p1
>>> 3.14159
>>>      0p1
>>> 0
>>>      0p0
>>> 0
>>>      1x1
>>> 2.71828
>>>      0x1
>>> 2.71828
>>>      0x0
>>> 0
>>>
>>> I don't understand why 0x1 isn't the same as 0 * ^1 even though
>>> other constants seem to obey this form. I haven't found any
>>> explanation in
>>> http://www.jsoftware.com/docs/help806/dictionary/dcons.htm .
>>>
>>> <information irrelevant to the question>
>>>
>>> I am new to J and am yet to write a useful script in it, but
>>> I've already been greatly impressed by how consistent the
>>> language felt in most cases. For example, just the other day
>>> I wrote a monadic verb which took $n$ as an argument and
>>> returned $\sum_k {n \choose 3k}$. The verb was the following:
>>>
>>>       a =: [:+/(3*i.)!]
>>>
>>> But if you try to pass it not a single $n$ but a list, the
>>> verb doesn't work. Which is a shame because the intended use
>>> was to examine the series. And so I started searching for
>>> something akin to Haskell's `map`. After half an hour of
>>> sifting through J tutorials that expressed delight in the
>>> fact that J lifts operations to arrays of arbitrary ranks
>>> by default and therefore doesn't need `map`, I've finally
>>> found what I was looking for, namely `a "0 i.50`, the rank
>>> operator, and it turned out that `map` isn't magic after
>>> all and is just a single case of a more general operation.
>>> I hadn't seen the rank operator in any language before and
>>> was thrilled to feel the potential that this operator holds.
>>>
>>> So the language is great, and it seems that common use cases
>>> are handled by elegant general solutions, that is, the
>>> language is designed to be mostly free from corner cases.
>>>
>>> That's why the unintuitive handling of 0x1 seems to me
>>> especially weird. I could ignore it if Python did it, if
>>> C++ did it, but J simply doesn't look like a language that
>>> intoduces inconsistencies for no reason. So it is highly
>>> probable that it's me who doesn't understand higher purpose
>>> of the construct. And so I came here hoping that someone
>>> explains it to me. The J community has a reputation of
>>> being tolerant to uninsightful questions of beginners.
>>>
>>> </information irrelevant to the question>
>>>
>>> Sorry if my English has some mistakes or is in the wrong
>>> tone. The reason isn't negligence, it's just that English
>>> isn't my native language.
>>>
>>> Regards,
>>> Dmitry Khalansky.
>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>
>>
>> ---
>> This email has been checked for viruses by AVG.
>> http://www.avg.com
>>
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm