On Sat, Oct 28, 2017 at 7:05 PM, kenneth mcfarland <kennethpmcfarl...@gmail.com> wrote: > Hi Chris, > > One instance is fluo-recipes under core/combine/CqConfigurator line 50. > > Another is line 36 under FluoConfigurator in fluo-recipes/core/export > > Looking at those lines describes the context in which I would change the > literals, not in the encoding functions, just variable assignment. > > Would those changes make sense?
I think for those two cases expanding to 2^x would be a bit more human friendly. Would be nice to use _ also to make the literal easier to read. > > > On Oct 28, 2017 1:48 PM, "Christopher" <ctubb...@apache.org> wrote: > >> I'm guessing that most, if not all, of the places where bit-shifting is >> used in Fluo, is in the manipulation of the Accumulo timestamp field, which >> is customized to contain flags for Fluo. In these situations, it really is >> the position of the bit that matters, and not the numerical value. The >> position is easily identified by the bit-shifting. It's much hard to look >> at an integer literal and immediately recognize which bits are "1" and >> which are "0". This is important if we're trying to create a bitmask to >> extract the value of a particular flag from the timestamp. >> >> If these can be improved to make them less cryptic, by adding comments, >> that might be better than converting them to numeric literals. >> >> There might be some places in the code where a literal does make more >> sense, but I think they'd have to be considered on a case-by-case basis, >> rather than simply discussed generically. Which specific ones did you have >> in mind? >> >> On Sat, Oct 28, 2017 at 3:19 PM kenneth mcfarland < >> kennethpmcfarl...@gmail.com> wrote: >> >> > I obviously meant 11 in the addition line so while you laugh the point >> > stands :) >> > >> > On Sat, Oct 28, 2017 at 12:11 PM, kenneth mcfarland < >> > kennethpmcfarl...@gmail.com> wrote: >> > >> > > Hi everyone, >> > > >> > > I was thinking about opening an issue and eliminating as much of the >> bit >> > > shifting in the code as was appropriate. My reasoning is two fold. >> > > >> > > First its simply cryptic. I'm normally used to seeing something like it >> > > crop up in the LMAX code as a hackish way to do super fast powers of >> two. >> > > So reason one is readability and clarity. >> > > >> > > I'm not going to fuss over bytecode but the logic is to use the shift >> > > operator as an operator, In the event the compiler doesn't optimize the >> > > shift out ahead of time its causing an extra couple of cycles, not a >> big >> > > deal but it is a very small optimization. >> > > >> > > var = (1<<15); //could just say 32768 and be done; >> > > int a = 1 + 3 + 2 + 5; // could just say 10 and nobody would argue >> > > >> > > I am curious if I will get grief for suggesting this. The other context >> > > I've seen bit shifting in is platform agnostic code, which is also of >> no >> > > concern here. So please give me your thoughts on this, does this make >> > sense? >> > > >> > >>
