On Tue, Nov 11, 2008 at 4:42 AM, Steven Taylor <[EMAIL PROTECTED]> wrote:
> coef ([EMAIL PROTECTED] {. [: |. [: </. ] */ *) i.10
> OR
> 10 {. |.</. (i.10) */ coef * i.10
>
> A question on this-- I don't get */ and * in combination? I'm thinking that
> only */ is need for me. Am I missing something?
I think you have too much implied context here. If I use coef=: ?.~10
I can try out your examples, but I do not understand your needs, so I
can not comment intelligently.
> Tacit verb trains seem worth the effort. I'm not quite up to speed on when
> the hook or fork substitution should take place yet... getting there. I'm
> finding the box < operator to be very useful for pulling apart verb trains.
> Are there any other good debugging aides apart from the debug tool itself
> (which is quite reasonable but doesn't seem to be designed to pull apart a
> single line)?
I like extracting relevant subexpressions and trying them against
representative data (thus, my need for a representative value for coef).
I also sometimes use J's display forms to help me inspect verbs and
so on. For example, I usually configure J to use linear display form,
but if I enable Parens, then
[EMAIL PROTECTED] {. [: |. [: </. ] */ *
([EMAIL PROTECTED]) {. ([: |. ([: (</.) (] (*/) *)))
I have three trailing right parenthesis there, so I know that I have
three nested forks. I usually like to get rid of irrelevant
parenthesis before evaluating expressions (they clutter up
my thinking), so sample expressions that might or might not
be worth inspecting might include:
coef ([: |. [: </. ] */ *) i.10
coef ([: </. ] */ *) i.10
Ok, in this case, those are somewhat boring, but that's because
I expected those results. If I ever get something that surprises
or puzzles me, then that sub-expression typically deserves
further study.
(Note also that I could have just used the linear form and
deleted two "space delimited verbs" off the left hand side
to get the simpler expressions.)
> Now a few questions about execution.
>
> Is it an issue that we have (n * (n-1)) too many calculations?
I think that's the wrong question. In this case, the right question
would have been "Is it an issue that we have twice as many
calculations as we need". And, the answer around here is
often that a factor of two is sometimes worth bothering with and
sometimes not. The "noise level" on a modern computer
is usually less than a factor of two speed difference on repeated
runs but can be significantly greater than a factor of two for the
first run,
Also, technically speaking, it's (n*(n-1))%2 too many calculations.
Like I said before a factor of two typically is only sometimes
significant, but this discussion would get confusing later on if
I did not point out this issue.
> Does this balloon out memory usage for large arrays?
Sure, my approach uses n^2 time and space where a
completely optimal approach would use (n*n+1)%2 time
and n*3 space. On the other hand, it's generally the case that
any time and space that you are not using are being wasted.
> Is J smart enough to reduce the amount of memory required. We've got
> everything on one line. Perhaps there's cleaver usage of CPU registers
> going on? I keep thinking procedurally that there must be a large data
> structure for this.
When you consider all possible variations on all possible expressions, you
start running into the same kinds of infinities that give us the halting
problem. That said, J implements special code for certain simple
subexpressions. See
http://www.jsoftware.com/help/dictionary/special.htm
That said, I do not find anything that looks particularly relevant on that
page (for example, when I search for /.).
> Is there a layman's way of understanding how J optimises? Array based
> languages / loopless code / vectorisation are supposed to be fast right?
J mostly does not optimize, premature optimization being the root of
all evil in programming. (I hope you don't mind me using the american
spelling of "optimize").
Also, the best way to understand the timing issues relevant to your code
is to perform tests with relevant data.
> I took the above imagined constraints into account, and realised that in my
> case there was convergence going on, and that the problem could be broken
> in two... so these things don't really effect the algorithm that much.
I run into similar issues quite frequently.
> If the above (potentially imagined) impacts were important, they will become
> minimal anyway with only a few lines of J code. I must say that J helped get
> to this point.
I agree -- I love how J lets me re-architect problems as I gain understanding
of my problem space.
> Would love to know how far J can be 'pushed' though. Curious.
I still find myself using other languages but J occupies an irreplaceable
(and growing) niche, for me.
> Sorry for the long post.
No problem, though if this discussion migrates to issues without code,
we should probably move it into the general forum.
Thanks,
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
