So your parse is akin to my unpack.
I was going to say that my "operator" and "literal" were both dyadic
too, but checked,
and now find I'm wrong. But "unpack" itself is indeed dyadic; irs
input is initially 0 _ ,
holding the required part 1 total, and the number of sub-packets where
relevant.
I didn't know about apply, 128!:2 . Live and learn!
I find that both our unpacks run in ~ 0.005 seconds, but mine uses
~ten times as
much space, a comparison much as in day 22, discussed earlier. Maybe
that's because
you have globals, pos, packet, whereas I'm recursively applying
operator and unpack
to "tail" which is of course a partial packet.
Mike
On 06/01/2022 11:42, Raul Miller wrote:
Mine is recursive: parse calls operator, and operator calls parse.
That's why I added a trace mechanism (an echo statement showing the
string I used to represent what would happen to the value, along with
the value itself, for each packet) -- so that I could visualize what
was happening.
By the way, re-reading this, I see that my naming convention might
have been confusing -- 'operator' was a dyadic verb. I passed in a
string showing the operation which would be applied to the result.
Also, I could have instead used 128!:2 to implement the operation
itself. So I should also have added a "this could have been done
better" disclaimer.
Thanks,
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
