> Another fascinating possibility becomes available: 'i._'...
Two more cents...
This was also contemplated more than a decade ago by none other than one of
the designers of J [0]. You are in good company. :)
Is it all academic? (My understanding is that Haskell supports infinite
lists.)
[0] [Jgeneral] infinity
http://www.jsoftware.com/pipermail/general/2005-December/026024.html
On Mon, Feb 26, 2018 at 12:48 PM, james faure <[email protected]>
wrote:
> I have 2 major propositions:
>
> Recently, I (to my chagrin) demonstarted to a friend that '>: i.1e7' takes
> almost twice as long as 'i.1e7'. Of course I expected them both to execute
> instantly, not after a full second. So my suggestion: i. should return a
> 'range' (or 'i.') object containing three vars: 'start end step'. In this
> way, '+ - * %' and indeed any linear combination of linear operations can
> be executed on only 3 variables rather than #y . besides the immediate
> speed and memory improvements here, other operations (on i. objects), like
> '+/ */ e. i.' etc.. can now be found by direct calculation, without ever
> spawning a physical array! Another fascinating possibility becomes
> available: 'i._'. Thus something like '*/ x * y ^ - i. _' is now able to
> return the result of the infinite geometric series. In fact in general it
> may be very profitable to use virtual arrays only, unless forced otherwise.
> Another concrete example: when searching for the first number to satisfy a
> certain property, one could use 'i.@u seq i. _' rather than some likely
> inefficent variation of ^: or while. . Perhaps this 'array only when
> forced' approach may even void the need for special combinations, a concept
> which feels suspicious to me.
>
> Secondly: operations on extended precision numbers are unbelievably
> slow... The most direct example: '! 100000x' takes 50 (!) times longer than
> python3's math.factorial(100000). It should be well worth looking into
> llvm's APInt and APfloats http://llvm.org/doxygen/classllvm_1_1APInt.html,
> or perhaps Cpython's bigint's https://github.com/python/cpython/blob/
> 65d4639677d60ec503bb2ccd2a196e5347065f27/Objects/longobject.c, I wouldn't
> think it's necessary to write another custom library.
>
> James Faure
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
