I think that is quite true; the discussion is not one about not being
able to understand, it's about optimizing solutions.
My takeaway so far is the use of &> instead of &.> as far as tidying up
at the end goes., and the niceness of {.&.": which suggests there is a
lot of treasure under Under.
As far as the 'why convert to and from strings?' question goes, the
'first digit of a number' concept _requires_ seeing numbers as strings.
My 'thing to research' is, is there a (built in, since it is easy
enough to define as a user verb)way to format into a base, sort of an
inverse of the 'b' notation:
16b1e
30
16 baseformat 30
1e
On 11/16/2010 2:00 PM, Don Guinn wrote:
> I thought the original issue was on how readable tacit expressions are, not
> the correctness or most efficient the expression. Based on the comments in
> this thread it seems that people can read the original tacit expression
> quite well.
>
> On Tue, Nov 16, 2010 at 11:53 AM, Roger Hui<rhui...@shaw.ca> wrote:
>
>>> My input is numbers and my output is numbers
>>> and fundamentally I'm doing arithmetic - so why should I have to
>>> translate to strings& back? (I know the answer, I'm just
>>> giving you my thought process. ...
>> I am curious regarding what "the answer" is.
>>
>> There is an analogy from mathematics. Number theory
>> (the study of integers) advanced by leaps and bounds
>> with the application of the the machinery of calculus and
>> complex analysis. Why should complex numbers
>> have anything to do with integers?
>>
>>
>>
>> ----- Original Message -----
>> From: Dan Bron<j...@bron.us>
>> Date: Tuesday, November 16, 2010 9:30
>> Subject: Re: [Jprogramming] tacit programming
>> To: 'Programming forum'<programming@jsoftware.com>
>>
>>> Raul wrote:
>>>> {.&.":&> seems more natural than anything involving #:
>>> or #.inv
>>>
>>> I'll buy that as a practical matter. But as a notational
>>> matter, it just
>>> doesn't "feel" right to me. My input is numbers and my
>>> output is numbers
>>> and fundamentally I'm doing arithmetic - so why should I have to
>>> translateto strings& back? (I know the answer, I'm just
>>> giving you my thought
>>> process. This similar to the reason I was nettled by
>>> "."0@": being
>>> optimized rather than 10&#.^:_1 [1] .)
>>>
>>>> An issue here is that #: and #.inv are designed to pad
>>> with leading
>>>
>>> Yep, that's what stymied the first correction I sent to Bjorn: I
>>> had [:
>>> ({."1) 10 #.^:_1 p:@:i. but I had to change it to
>>> {.@(10&#.^:_1)@p:@:i.for exactly this reason (naturally, I
>>> realized this 14 microseconds after
>>> hitting "send" - OTOH I am always pleased to find a natural use
>>> for @ as
>>> opposed to @: and since {."1 required parens anyway, the new
>>> formulationwasn't any messier).
>>>
>>> But #: padding on the left is helpful much more
>>> often than it is a
>>> nuisance (we're array programmers, after all), so I shouldn't
>>> complain.
>>> -Dan
>>>
>>> [1] http://www.jsoftware.com/help/release/digits10.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
