This is the "sweep it under the rug" design aesthetic - very useful when dealing with infinities and/or any other calculations which you really do not want to perform.
That said, J already supports this kind of thing - albeit with slightly different syntax. For example, you can do: i. bind 1e7 and 1 + i. bind 1e7 and J will faithfully not perform the indicated calculations, quite yet (but still stashes them so that if you later change your mind it can instead perform them). And, yes, the current extended precision implementation is slow for multiplications (though fast for display). It's a design tradeoff, and perhaps one which should be reconsidered. (Though memory management and cross platform stability and support are critical issues which can take precedence over mere performance.) Or at least: that's how I understand this issue... Thanks, -- Raul 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
