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? 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? > > > > > >
