haha, nice way of putting it.. 'it was just a prank everyone, just a prank!!'
This would be amazing though if we could make it happen, 'i.&1@:cond@:seq@:i._' especially would be nice for searching to infinity. ________________________________ From: Source <[email protected]> on behalf of Jose Mario Quintana <[email protected]> Sent: Monday, February 26, 2018 11:25:41 PM To: [email protected] Subject: Re: [Jsource] Propositions 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
