There seems to be some confusion here, so to clarify, this concept of range is only of concern for the C sources of j, it's a performance increase, but all happens behind the scenes of the i. primitive. the ability to handle 'i. _' is simply a corollary, should the result of i. be represented as a range, and not a huge physical array. I am absolutely not saying that the j interpreter should print the i. differently, nor am i proposing any change to the J language. (note. that 'i._' is currently a domain error, due to system limitations associated with an infinite phyiscal array, but it could be represented as a start of 0, end of _ and step of 1. since j only prints the beginning of an array anyway, there is even no problem with displaying it as usual).
As for bind, it is a tool for creating verbs, and doesn't help when evaluating a noun expression in this context:(i.&1000000) creates a verb, but when it comes (inevitably) to producing a noun, it remains just as slow as the direct request, due to the current implementation of i. (ie. produce a physical array immediately). To further illustrate: (internally in C!), there is a huge difference between ( i.1000): create a i. object, by doing 'start end step' =. 0 ; 1000 ; 1 (1 + i. 1000): add 1 to range object by adding 1 to start and end. and (i.1000): create an array of size 1000 (1 + i.1000): create another array of size 1000, by adding 1 to each element from first array All of this is just a huge waste of time, especially if the result is unused, or one is in the interpreter and only the first 256 or so elements will be printed, or the i. is then reduced by a dyadic i., dyadic e., +/, */ or something else that can be calculated directly from (start step end). Of course, if the user then (in j), requests something more complicated, or a write to file, then this internal (and invisible to the user) i. object must decay to a physical array. One very useful example for this, as presented before, is when performing dyadic i. searches on a sequence. I would like to write 'i.&1@:condition seq i._', to search for the first term of an infinite sequence that matches a condition. Currently, one has 3 main choices: guess an upper bound for i., which is potentially slow, especially if one underestimates, use ^:, or use a while. All of these are simply slow in j, as anyone who has solved project Euler problems (many of which ask for searches on the set of natural numbers) will attest to. Finally, I am aware that one could calculate all this manually, in scalar style, however this really should be optimized by the interpreter, in my opinion. Besides none of this should be particularly difficult to implement, after all one can always fall back to producing the physical array if it encounters a verb which has not yet been written to work with a range, no harm done. Xiao-yong, I was testing with extended precision, sorry for ommiting that. ________________________________ From: Beta <[email protected]> on behalf of Xiao-Yong Jin <[email protected]> Sent: Monday, February 26, 2018 9:01:27 PM To: [email protected] Subject: Re: [Jbeta] Propositions > On Feb 26, 2018, at 12:07 PM, james faure <[email protected]> wrote: > > 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. I'm not sure what takes a full second for you. JVERSION Engine: j806/j64/darwin Release: commercial/2017-11-06T10:20:33 Library: 8.06.09 Platform: Darwin 64 Installer: J806 install InstallPath: /applications/j64-806 Contact: www.jsoftware.com<http://www.jsoftware.com> timespacex'+/i.1e7' 0.048982 1.34219e8 timespacex'+/>:i.1e7' 0.056063 1.34219e8 timespacex'{.i.1e7' 0.040631 1.34219e8 timespacex'{.>:i.1e7' 0.048932 1.34219e8 timespacex'i.1e7' 0.040085 1.34218e8 timespacex'>:i.1e7' 0.051184 1.34218e8 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
