Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 15:06

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 24 07:47

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 23 02:04
    pthom commented #432
  • Jan 18 12:46

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 16 22:27
    ricejasonf commented #434
  • Jan 05 06:22
    ricejasonf commented #330
  • Jan 03 11:40

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Jan 02 00:33
    ricejasonf closed #434
  • Jan 02 00:33
    ricejasonf commented #434
  • Jan 02 00:04
    ricejasonf opened #434
  • Dec 27 2018 13:11

    ldionne on gh-pages

    Update benchmarks to 490dbf6 fo… (compare)

  • Dec 22 2018 11:56
    pthom commented #432
  • Dec 22 2018 11:55
    pthom commented #432
  • Dec 21 2018 15:48
    pthom synchronize #432
  • Dec 21 2018 09:19
    sdebionne opened #433
  • Dec 21 2018 00:08
    ricejasonf commented #432
  • Dec 21 2018 00:03
    ricejasonf commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:36
    pthom commented #432
  • Dec 20 2018 23:13
    ricejasonf commented #432
Louis Dionne
@ldionne
If you want, you can open a PR with the test code, and then we’ll see how this can be fixed. By opening a PR with the test code, the CI will tell us exactly the algorithms that are broken by this bug.
Jason Rice
@ricejasonf
$ ./test/test.bugs.github_221 
((0), (0, 1, 1, 2))
came in handy :D
Louis Dionne
@ldionne
cool!
Jason Rice
@ricejasonf
In the doc, the hana::partition benchmark graphic appears to suggest that mpl::vector outperforms hana::tuple. Is that right? :astonished:
Louis Dionne
@ldionne
@ricejasonf It very much looks like it! It means there’s room for improvement.
Louis Dionne
@ldionne
These cases where MPL outperforms Hana could probably be addressed with a dedicated container for types/integral constants, which brings us back to what I was saying about tuple_t and tuple_c.
Jason Rice
@ricejasonf
ah!
before you look at #222, I want to go back and get rid of that decay and do it the way filter does.
Louis Dionne
@ldionne
Sure, go ahead.
The PR looked good to me the last time I checked, though.
Jason Rice
@ricejasonf
This message was deleted
This message was deleted
Jason Rice
@ricejasonf
It appears broken for filter too if I use an lvalue for xs. (tuple_c is an lvalue right? :P)
because integral_constant<...> const& doesn't have a ::value
Louis Dionne
@ldionne
Oh gosh
Jason Rice
@ricejasonf
It only happens with hana::id because it just forwards the return value
Louis Dionne
@ldionne
Yes, I know it’s not of such a huge practical importance, but it’s still annoying.
Jason Rice
@ricejasonf
pretty high impact to go through and add decay all over the place. Is there a better way?
Jason Rice
@ricejasonf
This is just spit balling...
struct Predicate
{
  template<typename X, typename F>
  constexpr bool operator()(X&& x, F const& f) const
  {
    return !decltype(hana::not_(f(static_cast<X&&>(f))))::value;
  }
}
then you could just say that a predicate is a function that returns a Logical
idk if that adds too much overhead though
Louis Dionne
@ldionne
Predicates used to be required only to return Logicals, but I changed it for performance reasons.
Jason Rice
@ricejasonf
ah
Louis Dionne
@ldionne
Some predicates still only require a Logical, but I’d like to eventually clean this up.
Also, I generally find the Logical concept to be unsatisfying, and I’d like to get rid of it in the future.
Instead of Logical, I’d rather have something like a boolean algebra
Jason Rice
@ricejasonf
interesting
if you want, I can add tests with lvalues to create explosions :boom:
Do you think we should just get rid of the "convertible to bool" and just say it has to be a compile-time bool?
Louis Dionne
@ldionne
That’s a good question.

if you want, I can add tests with lvalues to create explosions

Yes, that would be nice.

Right now, I am inclined to think that we should allow predicates to return anything that can be converted to bool, as currently specified.
It’s more flexible, and also more consistent with the fact that an int is a Logical.
So it makes sense to say if(3, xxx, yyy).
Jason Rice
@ricejasonf
Which is more favorable, using std::declval<Pred>() or having a Pred const& pred member? hana::partition uses the former and hana::filter the latter. I figure I could make them consistent while I'm at it, unless you object.
Those are the only two with that problem with the predicate returning a const& btw
Actually idk, it looks pretty deliberate. I'll refrain from changing it.
Louis Dionne
@ldionne

Which is more favorable, using std::declval<Pred>() or having a Pred const& pred member? hana::partition uses the former and hana::filter the latter. I figure I could make them consistent while I'm at it, unless you object.

I have no preference. Off the top of my head, I can't think of a reason to use a Pred const& member over std::declval, except for the need to include <utlity> to use std::declval. But <utility> is already included everywhere anyway, so this isn't a strong reason.

Those are the only two with that problem with the predicate returning a const& btw

Cool!

Actually idk, it looks pretty deliberate. I'll refrain from changing it.

What looks deliberate? The usage of Pred const& over std::declval()? It probably just happened that way, because both algorithms were implemented at different times.

Jason Rice
@ricejasonf
It looked "deliberate" because filter.hpp actually had both (lift_or_empty uses declval), so I figured maybe there was a reason I didn't see. I just left it alone.
Louis Dionne
@ldionne
That’s fine.
Jason Rice
@ricejasonf
@ldionne Do you recommend any specific approach to named parameters?
Louis Dionne
@ldionne
Use a hana::map from arguments to values.
Represent the names of the arguments however you prefer, compile-time strings or types or whatever else.
Then, define an operator to create pairs (syntactic sugar).
template <char ...s>
struct NamedParameter {
    template <typename Value>
    auto operator=(Value const& v) {
        return hana::make_pair(*this, v);
    }
};

template <char ...s>
auto operator""_param() {
    return NamedParameter<s...>{};
}

int main() {
    some_function("a"_param = 3, "b"_param = 4, ...);
}
Something along those lines. Then, some_function may create a hana::map to search through its arguments.
Louis Dionne
@ldionne
It’s arguably annoying to have to create hana::map by hand inside some_function, so you might want to have a wrapper that does it automatically. Something like
auto wrapper = [](auto function) { 
    return [](auto ...args) { 
        return function(hana::make_map(args...)); 
    }; 
};
You can define function = [](auto args) { use(args[“a”_param]); }. You’ll need to make NamedParameter Comparable.
Jason Rice
@ricejasonf
:heart_eyes: nice! ty