Binary Literal ?
Hi!
Sorry, if I'm writing in the wrong forum, but I think, here's a good place...
I just realized that there's no literal for defining a binary constant in Java.... am I really right ?
We only have the praefixes 0x... for hex and 0... for octal ?
Perhaps I have overlooked something ?
I frequently need to work with bit-patterns, e.g. 110 110 110, that will not show their pattern when another radix is used, e.g. here: 0x1B6. So I would have to smash my brain when transforming them from binary to hex, and again when trying to read or simply change one bit in this pattern.
The only way I found is: x = Integer.parseInt("11001100", 2);
But that is not as fast as just defining a constant. (In fact when running in a 2000000-loop, it takes about ~640 ms here to call this line, but only ~10ms for doing just x=0x1b6 - that is a really big difference.
Will there be a literal for binaries someday ?
e.g. :100100101 or !10010101011 or #1001010110
[1034 byte] By [
wagalaweia] at [2007-9-30 20:25:00]
This is something I have also wished that Java had. The best way I've found to do it is to convert to hex and write it as 0xF0 or whatever, but as you point out that isn't always easy.
See also this thread on the same subject from earlier this year:
http://forum.java.sun.com/thread.jsp?thread=480508&forum=316&message=2239381
If speed is that critical, then how about declaring a final static value. It will get initialized when the class is loaded. Then your code just needs to use the variable. That's nearly the same functionality as having a literal, IMHO.public class Test {
private static final int BINARY_VALUE = Integer.parseInt("10010110",2);
public void someMethod() {
int value = BINARY_VALUE;
}
}
@scorbett
Oops. I used the forums' search before posting - but the one from the java tool's forums - and I thought that then really all forums of sun.com would be searched. But it seems that they weren't because I didn't get any result on 'binary literal'.
@atmguy
Yes, it would work this way - but you cannot use it >in place<, when this place is inside an often iterated loop, and further it's really wasteful to write e.g. if (A & new Integer.parseInt("100100", 2) == 0)
instead of e.g. if (A & :100100 == 0)
.
It's no big problem, of course, but I would found it much more comfortable to have those binary literals.
...and it would be no big deal to implement them.
> @atmguy
> Yes, it would work this way - but you cannot use it
> >in place<, when this place is inside an often
> iterated loop, and further it's really wasteful to
> write
Use of static class variables instead of putting in 'magic numbers' in methods is considered good programming practice by many on these forums. If you agree with that practice, then the only difference is using the Integer.parseInt() instead of using 100100b. No performance penalty, except using a few more bytes of code and running them when the class is loaded.
But if you argue this way, do you think that the literals for hex and octal are obsolete, too ?
...because you shouldn't use them as 'magic numbers', but define them by using e.g. Integer.parseInt(..., 16) ?
I just would find it a bit more comfortable to use binary literals as an option:
an example:
Atm I'm playing around with the Ulam-sequence (I don't know, if it is the right word for it in English) - this is the sequence you get when using x as a start number, and then divide it by 2 if it's even, or calculate x = 3*x+1 if it's odd (it seems that it will always ran to 1, but there's no proof for this until now)).
I try to find hidden regularities inside it. I already found a lot interesting stuff there, and much of it refers to bitpatterns. This is no wonder, because you could imagine 3*x+1 as 4*x+1-x, so bitshift left 2 positions and set most right bit to 1 (+1). So same as add simply concatenate '01' and subtrahate x from it.
Errrr... don't want to confuse, just:
While studiing them i use an often iterated for-loop that includes some cases,e.g. something similar to:
case (i & 1111111111111b == 0)
case (i & 1010101010101b == 0)
case (i & 1001001001001b == 0)
case (i & 1000100010001b == 0)
case (i & 0010000100001b == 0)
...
Using hex-values for this (0x1FFF, 0x1555, 0x1249, 0x1111, 0x421, ...) would be as uncomfortable & 'in-intuitive' & less good to understand/change/tune as first specifiing some constants outside the loop and than refer to them via an identifier. It's just the pattern that is self-explaining, clear, logical and easy to handle and fast.
No big deal, of course, but I would appreciate it, because I play a lot with binary patterns (not only Ulam).
[[ btw: the above code wouldn't work exactly like that, because case requests constant expressions ]]Question other way round :Is there any argument against binary literals ?
> But if you argue this way, do you think that the
> literals for hex and octal are obsolete, too ?
> ...because you shouldn't use them as 'magic numbers',
> but define them by using e.g. Integer.parseInt(...,
> 16) ?
>
I think the 'magic number' is more of an issue when you use the same numeric value in several places in your code. But I would say your code is more readable if it says something like case (i & ALL_BITS_SET == 0)
case (i & ALTERNATING_BITS_SET == 0)
Obviously, Sun believed it worthwhile to include hex and octal representation, so I don't see why they didn't include binary. I am only trying to point out a workaround that provides the performance with few drawbacks.
I'll put an oar in the water...I prefer not using any numeric literals. They are not self-documenting, for one thing. And maintenance can be a headache if there are multiple occurrences spread throughout the code body.
...and I prefer not using any comment.
;-)
But I would use an identified constant, if I would use this value more than once, too.
For more on this theme one should really read the topic mentioned above by scorbett, here the link again:
http://forum.java.sun.com/thread.jsp?thread=480508&forum=316&message=2239381
The same topic is handled in a more constructive way there.
