'the notion of infniite streams doesn't translate well to the notion of operating on the entire array':
Funny that you would say that, since It seems to me that the more lightweight the description of an array is, the easier it is to operate on the whole thing at once. Also remember that the slight complications associated with lazy evaluation are only of concern to the C code, and make no difference to J's semantics. As for python generators, there is a massive performance difference between a range object and an emulation of a range object using generators (something like def myrange(n): i=-1; while i < n: i+=1; yield(i) ), especially when testing if a value is in the range. ________________________________ From: Source <[email protected]> on behalf of Alex Shroyer <[email protected]> Sent: Wednesday, February 28, 2018 3:02:55 AM To: [email protected] Subject: Re: [Jsource] Propositions I don't have much to add to this other than some jargon and opinions. In Haskell (and Clojure maybe?) this type of "only evaluate the asked-for portion of an infinite sequence" idea is called "lazy evaluation", in contrast with "eager evaluation" used by pretty much every other language. In Python (and a few others) you can approximate laziness using "generators" which are function-like objects that emit the next value in a sequence when called. Both of these approaches attempt to avoid calculating unnecessary intermediate results, with the end goal of improved performance. In my experience this doesn't solve the problem but moves it; usually eager semantics are easier to understand, and avoiding intermediate results isn't as big of a savings as you'd hope. Although I do think that there's a niche for a language like J in many ways (syntax, regularity, brevity), but stream-oriented instead of array-oriented. The main thing that doesn't seem to translate to infinite streams is the notion of "operate on the entire array at once", which to me is a key feature that makes J, well, J-like. So while I think the idea itself isn't bad, I advocate for not adding it to J. -----Original Message----- From: "Jose Mario Quintana" <[email protected]> Sent: 2/27/2018 12:28 PM To: "[email protected]" <[email protected]> Subject: Re: [Jsource] Propositions > 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
