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
Yes. I feel like it might be easier to define the tuple once you have the values themselves.
Regarding hash: I just checked and you had const specializations for char and unsigned char only.
Jason Rice
@ricejasonf
I don't remember why exactly
lol
Louis Dionne
@ldionne
There were probably problems with char not being comparable to other integral types, but that was fixed separately.
What I do now for hash is simply discard the cv-qualifiers of the value in the IntegralConstant, for the cv-qualifier does not change whether two IntegralConstants are equal.
Jason Rice
@ricejasonf
ah right
Louis Dionne
@ldionne
I’m looking at your mpdef::Map right now and I see the add_const, but I don’t understand why it would ever be needed.
Jason Rice
@ricejasonf
If the map was made with a key of hana::int_c<1> that would be of type const hana::integral_constant<int> and it wouldn't match hana::integral_constant<int>
Louis Dionne
@ldionne
Oh shit, right.
But that’s an issue you run into when you use values for their type instead of “properly” storing them into hana::type or a similar container.
Jason Rice
@ricejasonf
Yeah, it's probably not something Hana needs to solve, but I run into the problem often. gtg eat ttyl
Jason Rice
@ricejasonf
#include<boost/hana.hpp>
#include<boost/hana/experimental/types.hpp>

namespace hana = boost::hana;
namespace hanax = boost::hana::experimental;

int main() {
  {
    constexpr auto xs = hanax::types<
      hana::int_<1>,
      hana::int_<2>,
      hana::int_<3>
    >{};

    BOOST_HANA_CONSTANT_ASSERT(
        hana::equal(xs, hanax::make_types(
            hana::int_c<1>,
            hana::int_c<2>,
            hana::int_c<3>
        ))
    );

    BOOST_HANA_CONSTANT_ASSERT(
        hana::equal(xs, hanax::make_types(
            hana::type_c<hana::int_<1>>,
            hana::type_c<hana::int_<2>>,
            hana::type_c<hana::int_<3>>
        ))
    );

    BOOST_HANA_CONSTANT_ASSERT(
        hana::equal(
            hanax::make_types(xs, xs, xs),
            hanax::make_types(
                hanax::make_types(
                    hana::type_c<hana::int_<1>>,
                    hana::type_c<hana::int_<2>>,
                    hana::type_c<hana::int_<3>>
                ),
                hanax::make_types(
                    hana::int_c<1>,
                    hana::int_c<2>,
                    hana::int_c<3>
                ),
                hanax::make_types(
                    hana::int_c<1>,
                    hana::int_c<2>,
                    hana::int_c<3>
                )
            )
        )
    );
  }
}
:grin:
sorry.. maybe i should have gisted that
If I accidentally call hana::make_types it says the only candidate function takes a single argument which is really, really weird considering there is no hana::make_types
flatten doesn't work yet because it unpacks as type_impl<types<T...>>
Jason Rice
@ricejasonf
ricejasonf/hana@8cc5f32
Louis Dionne
@ldionne
Actually, if you think of it, I don’t think it makes sense for hana::experimental::types to be a Monad, since it’s not possible for it to contain another hana::experimental::types.
For some Monad M, flatten needs to havea signature M(M(T)) -> M(T), which does not make sense for experimental::types since M(M(T)) does not exist.
Jason Rice
@ricejasonf
lol.. here I am hacking it in there. What if we thought of hana::type as a singleton hana::types?
Louis Dionne
@ldionne
Well then I think M(T) wouldn’t have sense anymore, it would always be M(M(T)) (where M is experimental::types_tag and T is hana::type_tag).
I’m not sure, let me think.
Jason Rice
@ricejasonf
template <typename T>
using type = hana::types<T>;
I'm not saying do that, but the idea is that they are the same.
so M would have to consider type_tag and types_tag as interchangeable.
Louis Dionne
@ldionne
Yeah, I understand your idea. I’m trying to see what it changes w.r.t. the ability to make it a Monad.
Jason Rice
@ricejasonf
I think unpack would have to not wrap a member with type if it is a hana::types.
Louis Dionne
@ldionne
I think there’s no level of sophistication that would make it legal for hana::types to be considered a Monad. I’ll let it sink in, though, because there might.
Jason Rice
@ricejasonf
yeah... static_assert failed "hana::equal( hana::monadic_compose(lift<M>, f)(x), f(x) )" :hurtrealbad:
Jason Rice
@ricejasonf
To be a Monad, does it have to be able to work with ANY kind of value? I definitely see that with Sequences as they are meant to be isomorphic.
I think, for my purposes, I will continue to use my empty list, but give it the same unpack specialization for Metafunctions because that is really useful. (or a special function or something)
Jason Rice
@ricejasonf
ricejasonf/hana@e55ef11
Louis Dionne
@ldionne
Technically, a Monad is required to work with ANY type. The fact that it works with anything it what gives us some interesting guarantees (the free theorems). However, I do think it is possible to make a sound Monad that only works on a subset of types, by considering the subcategory formed by those types. But clearly those types have to include M(T) itself, because otherwise we'll encounter the definition problem we talked about before with flatten.
Louis Dionne
@ldionne
@ricejasonf I managed to significantly cut down the compile-times for creating maps. If hana::make_map expects all keys to be distinct, and all their hashes not to collide, then we can create all the buckets in one pass, since we know each bucket will contain one and only one key.
And it seems like this is a reasonable assumption (no hash collisions), since 90% of the time we’re mapping distinct types, distinct integers, distinct strings or something else that won’t have collisions. If you need to allow for collisions, then one can use hana::to_map or use hana::insert recursively.
I’m running the tests now, but if it passes then I’m definitely making the change.
Do you think it’s stupid to have make_map require distinct hashes?
If I’m not forgetting something obvious, it seems like it’s totally reasonable.
Louis Dionne
@ldionne
@ricejasonf All tests are passing (after a tweak to your hash_collision.cpp test). I’ll wait for your thumbs up and I’ll push the change.
Jason Rice
@ricejasonf
👍🏻 Sounds great to me. practical
Louis Dionne
@ldionne
Ok, I’ll go forward with it.
Jason Rice
@ricejasonf
:+1:
Maik Klein
@MaikKlein
Not sure if you find this interesting but I "sort of" showcased the idea of hana in D https://www.reddit.com/r/programming/comments/48dssq/metaprogramming_with_type_objects_in_d/
Louis Dionne
@ldionne
@MaikKlein Thanks for the heads up, I’ll have a look!
Louis Dionne
@ldionne
Screen Shot 2016-03-01 at 08.48.40.png
@ricejasonf This is a benchmark of hana::make_map before and after the optimization I talked about yesterday. I’ll push the changes now.
Louis Dionne
@ldionne
@MaikKlein Cool article! I’m a D illiterate, but I see the idea. Did you measure the compile-times of these metafunctions? Is D doing much better than C++?