These are chat archives for boostorg/hana

20th
Jan 2016
Jason Rice
@ricejasonf
Jan 20 2016 09:24
      "name": "hana::map",
      "data": [[1, 0.3533264100042288], [6, 0.352144019001571], [11, 0.35156657100014854], [16, 0.35958893499628175], [21, 0.3495284200034803], [26, 0.35131487899343483], [31, 0.3586722390027717], [36, 0.3482181989966193], [41, 0.3752753449953161], [46, 0.3491084050037898], [50, 0.3498368250002386], [75, 0.3546147090019076], [100, 0.3510078990002512], [125, 0.3589944010018371], [150, 0.35030422799900407], [175, 0.35740598200209206], [200, 0.35042068300390383]]
:open_mouth:
Louis Dionne
@ldionne
Jan 20 2016 15:30
@ricejasonf For lookup with a hash?
@henrique-almeida Well, technically, -std::numeric_limits<int>::lowest() is not representable by an int, right? So the value of -std::numeric_limits<int>::lowest() is not defined by the standard, and you’re in UB land. When reading the laws, you should always pretend that you’re in a case where UB does not happen. The only problem is if we can break the laws without invoking UB, which is the case with unsigned int.
Louis Dionne
@ldionne
Jan 20 2016 15:39
@henrique-almeida Your big int example is quite interesting. However, the compile-time overhead for such a thing might be too large to use as a base for other algorithms. Also, I think it is out of scope of Hana.
But you might want to create a separate library for this; I’m sure some people would be interested in carrying complex number computations at compile-time. However, since these are all integers, there might be a way to represent them with homogeneous constexpr data structures, which would be more compile-time efficient than Hana.
henrique-almeida
@henrique-almeida
Jan 20 2016 18:26
one other thing that would be interesting (at least for the mathematically iclined) is to have Constant integers mod p, then prime p, that would give us fields, and fields are nice :D
i cant think of any practical applications for it tho, at the moment lol
the additional overhead would be that of a division after every operation
Louis Dionne
@ldionne
Jan 20 2016 19:56
Sure, it is interesting and might have a lot of applications, but my concern is that this is probably material for a different library.
Something like “compile-time algebra"
henrique-almeida
@henrique-almeida
Jan 20 2016 20:15
probably :p i just got overexcited is all, remembering the olden days of bit twiddling
Louis Dionne
@ldionne
Jan 20 2016 21:24
@ricejasonf I see you’ve created a PR for Hashable. Before we start looking at this, I’d like us to finish taking a look at the previous PR you did, which I modified quite a bit.
I’ve done some benchmarking for that other PR, and it seems like we’re not faster using the eager approach I had suggested.
That’s frustrating.
Basically, I’d like to filter out what we want to keep and what we don’t want to keep from that other PR. Then we can improve on top of it, perhaps by using a hash table. Altough for comparison purposes, your new Hashable PR would ideally create a new map in include/boost/hana/experimental/hash_map.hpp or similar.
Jason Rice
@ricejasonf
Jan 20 2016 21:35
Are you saying that the find_index_eager version is not faster than the version that is just a wrapper for tuple? What benchmarks are you talking about?
Louis Dionne
@ldionne
Jan 20 2016 21:36
Yes, this is what I am saying. I am talking about some local benchmark where I measure the time as a function of the number of keys looked up in a ~200 element map. This is the most common use case.
Jason Rice
@ricejasonf
Jan 20 2016 21:38
Then perhaps the only improvement was the construction time.
Jason Rice
@ricejasonf
Jan 20 2016 21:59
Was there any changes to my original PR that are not visible? It seemed like it had been ironed out for the most part.
The new PR sort of reverts some of your changes because it no longer has an std::index_sequence to work with.
And find_if and find need some refactoring of course.
Louis Dionne
@ldionne
Jan 20 2016 22:57
Do you mind if I push my changes to your benchmark/map branch on ricejasonf/hana? That’ll update PR #226 and it will be easier to talk about it then.
Or to see what has actually been done. I’m a bit confused otherwise.
Jason Rice
@ricejasonf
Jan 20 2016 23:53
of course