You're right. The code for u^:vector (or u^:(<n)) follows a pattern
that used to be prevalent in the JE:
1. execute u once
2. if the result is boxed, abort to general case below
3. reserve a result area on the assumption that all results will have
the same shape and type as the first
4. run the rest of the executions of u. If there is a change of type or
shape in any result, abort to general case
General case:
Start over. Execute <@:u repeatedly, collect into a result array, then
return >result
At any time up to the end, the code is liable to restart.
I thought I had replaced all these forms with code that guarantees no
reexecution, but I missed the u^:vector case (probably because it's more
complicated than the rest). I will change it, but it will take a little
time.
Henry Rich
On 3/3/2020 5:31 PM, David Lambert wrote:
My 7-smooth generator depends upon side effects. We cannot depend on u^:
when u has side effects including appreciable resource consumption. Work
around example
for.i.20 do. x u y end.
thanks
Date: Mon, 2 Mar 2020 18:14:13 -0500
From: Henry Rich <[email protected]>
To: [email protected]
Subject: Re: [Jprogramming] ^:
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Sometimes it does an initial extra iteration. It does so in this >case.
I might work on eliminating the extra iteration. Someday.
Henry Rich
On 3/2/2020 6:10 PM, Raul Miller wrote:
I think he's asking why there's a second iteration.
Or, more specifically, why, when n is a list in u^:n why there is an
extra evaluation of u.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
