One concern with lazy evaluation is that errors may not be encountered
until something happens to make the evaluation go beyond what has been
encountered before. Particularly during development and testing. Is there a
way to turn off lazy evaluation in python during development and testing?
On Feb 28, 2018 8:43 AM, "Raul Miller" <rauldmil...@gmail.com> wrote:
> On Wed, Feb 28, 2018 at 10:21 AM, james faure <james.fa...@epitech.eu>
> wrote:
> > For J, where so much more is happening per statement, we could
> transparently replace all intermediate results by generators, except where
> a full noun is required.
>
> Worth considering in this context:
>
> $
> {
> |.
> %.
>
> > To translate the python statement to j, one would write (<./ 1 2 3 4 , 0
> 10 0 10), however we lose lots of time to python here due to calculating
> the intermediate catenation (unless we are fortunate enough that the
> interpreter has a Special Combination (SC) for this)
>
> How much is "a lot"?
>
> > For everyone who may be of the opinion that this is not worth it, I
> would like to direct your attention to the existing jsources, where vast
> amounts of effort for far smaller optimizations are apparent.
>
> As a general rule, J only accepts optimizations where there's a useful
> problem where that optimization produces at least a factor of 2
> improvement. (Often enough it's more like factor of 1000.)
>
> > for example p.c, where the parser itself tries to emplace arrays and
> avoid unnecessary copying. It is still unable to do this consistently
> however, as simple memory tests like 7!:2 'i.1000x' ,: '>: i.1000x' prove.
> (and yes I like using x for my benchmarks due to how much slower they are)
>
> I am not sure what you're talking about here - I took a quick look at
> p.c but most of what I saw was implicit in the definitions. I'm not
> comfortable calling that "optimizations".
>
> > another example is. jt.h, where a JFE's state information structure has
> been lovingly crafted to optimize it's use of cpu cache
> > or again the countless optimizations in the primitives, like n&i. hash
> tables, the immensely flexible /: etc..
>
> The hash tables aren't so good on large arrays, unfortunately - so
> that's something that could maybe use some good insights.
>
> But the thing that worries me is how many things would break if you
> tried to throw generators at them. That winds up being cases where
> generators would slow things down (because you have the work of
> building the generator and then interpreting the generator and you pay
> in both code bloat and cache pressure and in cpu pipeline breakage and
> of course any extra tests to keep things from breaking.)
>
> Put different: arrays are not "an optimization" in J. They are J's
> fundamental data structure.
>
> Or, for a similar perspective:
>
> gnu gmp's bignum library looks like a nice-to-have
>
> the lapack library is a nice-to-have
>
> But integrating both of them would not solve the hard issues
> associated with using them together.
>
> Also, thinking back to infinities: one useful tactic for implementing
> math which involves infinities is to work in the reciprocal domain.
> But - hypothetically speaking - there are potentially an infinite
> number of different ways to work with infinities.
>
> 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
