> Actually, I think J has implemented support for VF=: 3 : '2+3*y.' Right, I suspect that Roger might have been aware of that.
> resolved. (For example, how would reshape work on that sort of array? > Throw an error?) You did not expect all related sentences to be clearly defined (|. i._) in a unique way (+/ i._). Did you? Regarding reshape: have you read McDonnell and Shallit's article? On Mon, Feb 26, 2018 at 5:42 PM, Raul Miller <[email protected]> wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
