Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    David Chambers
    @davidchambers
    Then you can git add dist/ramda.js && git commit --amend to update your commit (assuming there's just one commit in your branch, which may not be the case).
    Michael Hurley
    @buzzdecafe
    at present branch is clean
    so lemme try that
    Michael Hurley
    @buzzdecafe
    success. i have two tests failing
    David Chambers
    @davidchambers
    Terrific!
    Michael Hurley
    @buzzdecafe
    thank you @davidchambers !!!
    David Chambers
    @davidchambers
    No problem.
    Michael Hurley
    @buzzdecafe
    btw, did you see the activity on ramda-fantasy?
    David Chambers
    @davidchambers
    I did. It's exciting to see. I'll probably chime in on that issue later today. :)
    Michael Hurley
    @buzzdecafe
    great -- i know you are doing work in that area anyways, so the timing is good
    David Chambers
    @davidchambers
    Definitely.
    Michael Hurley
    @buzzdecafe
    yay all tests passing
    ok, gonna check this in and come back to it tomorrow
    David Chambers
    @davidchambers
    Cool. I look forward to looking at the master...xduce compare view.
    Michael Hurley
    @buzzdecafe
    haha enjoy. there is actually a shload of work in there!
    Michael Hurley
    @buzzdecafe
    just ran some benches on these
    not pretty
    filter is particularly ugly
    Running suite filter [bench/filter.bench.js]...
    >> _.filter(nums, isEven) x 2,395,574 ops/sec ±0.98% (95 runs sampled)
    >> filter(isEven, nums) x 250,792 ops/sec ±2.93% (93 runs sampled)
    >> filter(isEven)(nums) x 209,959 ops/sec ±5.61% (82 runs sampled)
    >> filterEven(nums) x 190,297 ops/sec ±4.81% (73 runs sampled)
    Fastest test is _.filter(nums, isEven) at 9.6x faster than filter(isEven, nums)
    map:
    Running suite map [bench/map.bench.js]...
    >> _.map x 4,164,032 ops/sec ±0.18% (103 runs sampled)
    >> map(sq, nums) x 189,221 ops/sec ±2.74% (98 runs sampled)
    >> map(sq)(nums) x 192,269 ops/sec ±0.25% (102 runs sampled)
    >> mapSq(nums) x 194,960 ops/sec ±0.26% (99 runs sampled)
    Fastest test is _.map at 21.4x faster than mapSq(nums)
    Michael Hurley
    @buzzdecafe
    so preserving reduce as the means of iteration, but composing reducer functions instead
    would be nice to make this satisfy protocol, which would mean early exit from reduction, and flushing accumulated results
    David Chambers
    @davidchambers
    As far as I'm concerned, 10x the execution time of _.filter is perfectly acceptable. Presumably this would be somewhat offset in cases where more than one transformation is performed (e.g. filter + map + filter). I've never found JavaScript performance to be a bottleneck in the contexts I've used the language.
    Michael Hurley
    @buzzdecafe
    i hear you, but it seems a high price to support this style of transducer.
    i wonder if we can get similar benefits using fp style.
    with less cost
    Kevin Beaty
    @kevinbeaty
    Note that the initial release of transducers.js (and underscore-transducer FWIW) looked similar to the image you posted if I'm understanding it correctly, and the benchmarks created against the {init, step, object} implementation were much more favorable. Both transducers.js and transducers-js seem very concerned with performance and surprisingly converged to the same implementation. Just saying... no harm in trying, benchmarking is hard, etc. I'll be interested to see what you come up with.
    Michael Hurley
    @buzzdecafe
    yes, so once the array reaches 90,000 elements, perf gains show up
    i'm dubious about optimizing for that case
    Kevin Beaty
    @kevinbeaty
    Fair enough. Although it does seem that even from your benchmarks either option is likely "fast enough" for most reasonable use cases... Although my definition of "reasonable" may be different than yours.
    Whatever works though. My point had less to do with the benchmark (as neither convinced me either way ... the "speed" of transducers is very low on my list of features that make them interesting/useful), and more to point out the precedence to using a "functional style"
    Kevin Beaty
    @kevinbeaty
    Just to clarify my hesitation. If the transducers in ramda are defined according to the definition in transducers-js, transducers.js ramda can plug into any other library that supports that style (js-csp, kefir, RxJs, soon Highland, probably others and hopefully more to come). It seems like the difference between that definition and the one you propose is the difference between calling the reducing function as a method vs a reducing function created as a closure within the same reduce loop....
    I do completely understand that compatibility with those other libraries may not be a goal... it just becomes much less interesting to me. But, personal preference, n=1, etc.
    So my hesitation really has little to do with benchmarks, I should have left that out earlier :)
    ... and transducers created in that style for other libraries can be composed with functions in Ramda ...
    Michael Hurley
    @buzzdecafe
    i'm still interested in supporting the protocol. i just want to evaluate the field. and i've gotten distracted by haskell-y types again
    David Chambers
    @davidchambers
    Do you think it would be reasonable to open a pull request for https://github.com/buzzdecafe/ramda/compare/ramda:master...buzzdecafe:xduce? I realize it's unfinished but it would allow folks to review it in its current state.
    Michael Hurley
    @buzzdecafe
    more eyeballs would be welcome
    David Chambers
    @davidchambers
    Go for it, I say!
    Michael Hurley
    @buzzdecafe
    ok, will rebase from master
    David Chambers
    @davidchambers
    Cool.
    Michael Hurley
    @buzzdecafe
    btw, thx for joining in on that fantasy-land discussion
    my understanding of types/categories is pretty weak
    David Chambers
    @davidchambers
    It was a very interesting one. Thanks for linking to it. I'm now watching the repo so as not to miss out on similarly interesting threads in future.
    My understanding of types is weak, too. PureScript is beginning to make sense to me. :)
    Kevin Wallace
    @kedashoe
    Hey @buzzdecafe, is it cool if I submit a transducers pull request? I think I can have something ready by tomorrow night.
    Michael Hurley
    @buzzdecafe
    yes, i have been super slow
    so fire away @kedashoe
    Kevin Wallace
    @kedashoe
    cool, got things more or less where I want them, just would like to write some more comments/explanation/tests. will submit monday night