I guess I'm not sure what you think the word "execution" means, in the context of this proposition.
But it's also not clear to me why you think that all use of i. should require extra complexity which is already available through the use of bind. But there's an additional difficulty, here, which is two unrelated proposals making talking about either of them likely to bring in the other unrelated topic. Thanks, -- Raul On Mon, Feb 26, 2018 at 1:32 PM, james faure <[email protected]> wrote: > Bind is not relevant here, since I'm talking about the execution of i., which > must inevitably happen at some point to be of any use. > > > Also, I don't see how there could possibly be a tradeoff between the time > taken to write the results of a multiplication and evaluate it. In any event > my tests had both python and j print the result of '! y', which should favor > j even, since it only writes the first 256 digits, whilst python prints the > entire number. > > James Faure > > ________________________________ > From: Source <[email protected]> on behalf of Raul Miller > <[email protected]> > Sent: Monday, February 26, 2018 7:08:31 PM > To: Source forum > Subject: Re: [Jsource] Propositions > > 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. > [https://avatars2.githubusercontent.com/u/1525981?s=400&v=4]<https://github.com/python/cpython/blob/65d4639677d60ec503bb2ccd2a196e5347065f27/Objects/longobject.c> > > python/cpython<https://github.com/python/cpython/blob/65d4639677d60ec503bb2ccd2a196e5347065f27/Objects/longobject.c> > github.com > cpython - The Python programming language > > LLVM: llvm::APInt Class > Reference<http://llvm.org/doxygen/classllvm_1_1APInt.html> > llvm.org > Class for arbitrary precision integers. APInt is a functional replacement for > common case unsigned integer type like "unsigned", "unsigned long" or > "uint64_t", but ... > > >> >> James Faure >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > J Forums<http://www.jsoftware.com/forums.htm> > www.jsoftware.com > Forums. The J forum mailing lists give life to the J community. They are the > best way to get help, help others, report bugs, and share your interest in J. > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > J Forums<http://www.jsoftware.com/forums.htm> > www.jsoftware.com > Forums. The J forum mailing lists give life to the J community. They are the > best way to get help, help others, report bugs, and share your interest in J. > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
