Actually, I think J has implemented support for VF=: 3 : '2+3*y.' You could also use VF=: 2 3&p.
What we don't have, though, are "nouns" N where _ e. $ N is true. Perhaps we should? Might be some serious problems there, though, to be resolved. (For example, how would reshape work on that sort of array? Throw an error?) Thanks, -- Raul On Mon, Feb 26, 2018 at 5:25 PM, Jose Mario Quintana <[email protected]> wrote: > So, Roger's i._ and McDonnell and Shallit, > > " Furthermore, an infinite array may be stored as a function > of its indices. For example, to store the infinite vector > V=: 2+3*i._ we need only store the function VF=: 3 : '2+3*y.' . > Then it is easy to see that (k{V) <-> VF k . Any > particular element of V may be obtained by using the > associated function VF . Since the user can never > examine all the elements of V, it does not matter that > the entire infinite array is not in fact stored: > any portion of it may be computed as needed. > " > was just a big tease, or a joke? > > > On Mon, Feb 26, 2018 at 5:02 PM, Raul Miller <[email protected]> wrote: > >> Note also that Haskell has a lot of things to keep you from trying to >> access anything more than a brief prefix of those infinite lists. (And >> this includes a rather extensive system of errors and an involved >> "pattern matching parser".) >> >> You would basically have to give up on J's syntax (and some of J's >> convenience and features) to do a reasonable job of bringing in the >> Haskell way of doing things - and if you're going to go that far, why >> not just use Haskell? >> >> (Or you could go the other way, and build up J style arrays and >> primitives in Haskell - but to do an adequate job of that, you'd wind >> up having to disable and/or bypass a lot of Haskell's restraints... >> and if you're going to go that far, why not just use J?) >> >> Thanks, >> >> -- >> Raul >> >> >> On Mon, Feb 26, 2018 at 4:51 PM, Jose Mario Quintana >> <[email protected]> wrote: >> >> 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 >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
