One case I was thinking of where laziness makes things more complicated in python is 'map'. In (eager) J, I can say 2 * 3 4 5 and get back 6 8 10. But in python, map([3,4,5], lambda x:2*x) returns an iterator object (I think). To eagerly evaluate and return the data, I need to wrap the whole thing in a call to 'list()'.
That extra step forces a particular style of composition (can't seamlessly mix and match eager and lazy, you have to wrap and unwrap) and is more complicated than either lazy-only or eager-only. That said, the"idiom recognition" of J has a similar effect of reducing extra work at run-time. Although it seems to require more effort from J implementors. -----Original Message----- From: "Raul Miller" <rauldmil...@gmail.com> Sent: 2/28/2018 8:09 AM To: "Source forum" <sou...@jsoftware.com> Subject: Re: [Jsource] Propositions Stalled processing: i.1e7 takes a finite amount of memory - either you have it, or you do not. But lazy evaluations encourage you to work with expressions which are more like i._ and if you are tackling non-trivial problems it becomes trivial set the machine to work on problems that do not fit in memory. These can still be solved, but only by shifting your resource tradeoffs to favor less memory at the expense of increased computational time. But since the design of the system hides those choices from the programmer it can become difficult to talk about. Yak shaving: http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html - this is basically a term for high investment in low priority efforts and low investment in high priority efforts. You have to have some tolerance for such things, because prioritization is based on estimation and guess work. It's ok to do things for fun, but take this too far and you get solutions looking for [irrelevant] problems and [critical] problems going without solutions. (A rule of thumb might be the 10% threshold. If you are not spending at least 10% of your efforts on things which have some generic utility, you should strongly consider rethinking what you are doing.) That said: if you want to build a version of the J interpreter which implements range handling like you've been suggesting, no one is stopping you. I personally am dubious of the value of that effort, but I can see the attraction of the effort, and if you write such a thing and need help debugging it, I might be inclined to help out at that point (this would be a low priority task for me, but I do spend time on low priority tasks). Finally: infinities are mostly impressive for people who do not try to use them, and instead are a great source of errors and slow systems for people who do make the attempt. As for the prefix of an infinite list thing - the attraction of working with a system which lets you say i.1e7 but not actually do that work is that later on you can go n{.1e7 and get the effect of i.n. But you can achieve the same thing more directly by performing i.n directly. There's a subtle complication here that you might want to use a value of n which is greater than 1e7 and that that result would be different from i.n but if that was the priority it might be that (* 1e7&>) is a better way of describing the useful part of the system. By focusing on creating a system which represents a subset of useful functions as ranges you've also built a system which does not support other functions. But what is the point of that? -- Raul On Tue, Feb 27, 2018 at 10:17 PM, james faure <james.fa...@epitech.eu> wrote: > 'Potential problems though include stalled processing and yak shaving' > > You need to elaborate on this, I don't see what this has to do with anything. > > 'but I do not draw the conclusion that this means that working with prefixes > of descriptions of infinite arrays is a particularly good idea' > > and this as well, after all, a prefix of an infinite list is no longer > infinite > > > Additionally, infinite arrays are of course not helpful for performing > calculations on data sets, they are mainly a theoretical exercise, although I > am of the opinion that they would be very helpful for solving problems > involving searches on infinite sequences, since 'while.' and '^:', are slow, > and having to guess an upperbound (here is the arbitrary prefix of an > infinite list) is just ugly. The physical impossiblity of an infinite array > has never been an issue for mathematics, and i.&1@:whatever@:i._ would be the > idiomatic solution. > > > Finally, a non negligible aspect of such infinite lists are how impressive > they are. J must impress newcomers or they will not be willing to spend the > considerable effort required to even get anything done in the first place. I > have no idea how many people choose to learn J nowadays, but I suspect > nowhere near enough. > > ________________________________ > From: Source <source-boun...@forums.jsoftware.com> on behalf of Raul Miller > <rauldmil...@gmail.com> > Sent: Wednesday, February 28, 2018 3:44:04 AM > To: Source forum > Subject: Re: [Jsource] Propositions > > On Tue, Feb 27, 2018 at 9:15 PM, james faure <james.fa...@epitech.eu> wrote: >> 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. > > Potential problems though include stalled processing and yak shaving. > Both of these have to do with hitting the problem at the wrong level > of abstraction. > > In my experience, working with J on large data sets, it's extremely > useful to run through the concepts on very small sets of data, first, > so that you can verify that things are working right and that you > understand the data. Working with very large sets of data can be quite > a burden (finding a conceptual error a month into the calculations is > quite different from finding an error an hour in or a few seconds in - > at that point you need to think things through and decide what you can > salvage). > > This agrees with the abstraction you brought up that "the more > lightweight the description of an array is, the easier it is to > operate on the whole thing at once" but I do not draw the conclusion > that this means that working with prefixes of descriptions of infinite > arrays is a particularly good idea. > > Thanks, > > -- > Raul > ---------------------------------------------------------------------- > 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
