## bitwise reversal

Nov 03 2008 | 2:31 am
hi,
how would you reverse the order of bits in an integer?
for example: 00010011 -> 11001000 10000010 -> 01000001
thanks, james.

• Nov 03 2008 | 5:13 am
There might a super-easy solution to this (perhaps an mxj object?), but a sort of brute force method would be to convert the number to a list of binary values, reverse the list, and convert it back to decimal. There was a thread about decimal to binary conversion a while back that might be helpful: https://cycling74.com/forums/index.php?t=rview&th=35324&rid=7743
• Nov 03 2008 | 9:13 am
hi james,
the [bitlist] external in my collection offers the two bit ordering modes you are looking for. to get the reversal you convert an int to binary using one mode and convert back using the other.
the following patch also shows how to convert to and from a list of bits using iterative bit-shifting and masking using stock objects only.
hth
/*j
max 4.x version below
• Nov 03 2008 | 9:13 am
An example with standard objects:
_ johan
• Nov 03 2008 | 3:55 pm
johan,
Your solution is very interesting, it seems that the radiogroup object will do the binary/list translation pretty much by itself. Makes the complex solutions posted by Stephen Lee seem redundant: https://cycling74.com/forums/index.php?t=rview&th=35324&rid=7743
The only maths in your patch is to resize the radiogroup objects depending on how many bits in the incoming integer. Since I am only dealing with bytes I can just leave the radiogroup objects at 8 long.
Max is restricted to 32bit integers, is it not? So you could just leave the radiogroup objects at 32 long and be done with it.
Thanks, James.
• Nov 03 2008 | 4:54 pm
Another problem for me would be that the radiogroup is a gui element. I avoid those like the plague...
Although jasch rules, can't you just:
?
• Nov 03 2008 | 7:12 pm
Quote: Bas van der Graaff wrote on Mon, 03 November 2008 09:54 ---------------------------------------------------- > Another problem for me would be that the radiogroup is a gui element. I avoid those like the plague...
I agree, but it does work with the least amount of objects.
Your example doesn't work for numbers.
• Nov 04 2008 | 10:08 am
You mean leading zeros? Correct, hehe. It's near impossible to treat those correctly in max, even things like [sprintf "%s"] and [unpack s] like to remove them. Explicit annoyance.
• Nov 04 2008 | 11:39 am
On 4 nov. 08, at 11:08, Bas van der Graaff wrote:
> You mean leading zeros? Correct, hehe. > It's near impossible to treat those correctly in max, even things > like [sprintf "%s"] and [unpack s] like to remove them. Explicit > annoyance.
[sprintf symout %.3d] seems to be really happy here. Don't forget to output a symbol, otherwise it get automatically converted back to an integer.
HTH, ej
• Nov 04 2008 | 1:45 pm
Hmm, are you sure? Even when i use [printit] directly after [sprintf symout %.3d], i've already lost my leading zeroes.
Mind you, i don't need this for my patch or anything, just generally interested how things work. Personally, I might prefer more strict use of datatypes, as things like these are hardly intuitive, but it remains to be tested how this influences workflow...
• Nov 04 2008 | 2:00 pm
My proposal for Max 6 (seriously):
1 -> int 0.1 -> float 1 0.1 -> list of int and float "hello" -> string "hello world" -> string "hello" "world" -> list of two strings hello -> message / keyword hello world -> list of two messages hello "world" -> list of message and string
Special cases: 000111 -> int (equal to 111) 00.0111 -> float (equal to 0.0111) "000111" -> string
- if an object doesn't understand a keyword, it throws an error - we lose the term 'symbol'
Mattijs
Quote: Bas van der Graaff wrote on Tue, 04 November 2008 14:45 ---------------------------------------------------- > Personally, I might prefer more strict use of datatypes, as things like these are hardly intuitive, but it remains to be tested how this influences workflow... ----------------------------------------------------
• Nov 04 2008 | 3:14 pm
On 4 nov. 08, at 14:45, Bas van der Graaff wrote:
> Hmm, are you sure? Even when i use [printit] directly after > [sprintf symout %.3d], i've already lost my leading zeroes. > > #P window setfont "Sans Serif" 9.; > #P window linecount 1; > #P newex 573 325 39 196617 printit; > #P newex 537 325 32 196617 print; > #P message 473 363 50 196617 111; > #P newex 473 325 62 196617 prepend set; > #P message 473 178 46 196617 111; > #P newex 473 236 103 196617 sprintf symout %.3d; > #P connect 0 0 2 0; > #P connect 0 0 4 0; > #P connect 0 0 5 0; > #P connect 1 0 0 0; > #P connect 2 0 3 0; > #P window clipboard copycount 6; > > Mind you, i don't need this for my patch or anything, just generally > interested how things work. Personally, I might prefer more strict > use of datatypes, as things like these are hardly intuitive, but it > remains to be tested how this influences workflow...
well if you send 111, you get 111, not more leading 0. On Max 5 (don't have the time to open 4.6 right now), when I use [sprintf symout %. 3d], and I send 11, the symbol sent to the output is 011 (that's what is printed in the Max window, that's also what is sent to the message box). Am I missing something?
ej
• Nov 04 2008 | 3:14 pm
Quote: Bas van der Graaff wrote on Tue, 04 November 2008 03:08 ---------------------------------------------------- > You mean leading zeros? Correct, hehe.
No, I mean numbers, integers. You are reversing a message.
You are taking message that looks like the binary representation of a number and reversing it.
Have a look at johan's patch and see how it differs form yours.
The real revelation for me here is the radiogroup object. It seems to do the job of converting a number into a list of the binary version straight off. I agree that it's a shame that it's a gui object, also a shame that you need to know how many bits in your number, but it still seems that this is the best solution for this problem.
• Nov 04 2008 | 3:22 pm
Quote: Emmanuel Jourdan wrote on Tue, 04 November 2008 08:14 ---------------------------------------------------- > Am I missing something?
Yes. We're talking about numbers here, not messages that look like numbers.
• Nov 04 2008 | 3:54 pm
Mattijs Kneppers schrieb: > My proposal for Max 6 (seriously): > > 1 -> int > 0.1 -> float > 1 0.1 -> list of int and float > "hello" -> string > "hello world" -> string > "hello" "world" -> list of two strings > hello -> message / keyword > hello world -> list of two messages > hello "world" -> list of message and string > > Special cases: > 000111 -> int (equal to 111) > 00.0111 -> float (equal to 0.0111) > "000111" -> string
This would mix a bit the difference between presentation of a number (or visualisation) and the number itself, it would create an overhead not worth it. Each simple number would have to carry a presentation along with it... I doubt that anybody would want her patches 100% broken when switching from Max 5.x to Max 6, though computing power might be so much higher, that you don't know anymore how to burn it...
It is like with going from C to C++, it had to be a new language. (And the world is still using this bad hack of a language called C...)
Stefan
-- Stefan Tiedje------------x------- --_____-----------|-------------- --(_|_ ----|-----|-----()------- -- _|_)----|-----()-------------- ----------()--------www.ccmix.com
• Nov 04 2008 | 4:44 pm
Presentation? O.o?
Internally, all variables have C data types already, so the only difference would be that you could get rid of all the excess automatic conversion, only objects presented with incorrect data types would generate an error.
You're correct by stating some patches may be broken in Max 6, but the errors will be easy to trace and fix by adding a simple [i], [f] or [str] object for typeconversion. Most of your data is type-specific, only rarely one datatype is used as another.
Of course, these are only ideas, but can't harm to discuss whether it needs change, as it's clearly not very easy-to-use at the moment.
Quote: stefantiedje wrote on Tue, 04 November 2008 16:54 ---------------------------------------------------- > This would mix a bit the difference between presentation of a number (or > visualisation) and the number itself, it would create an overhead not > worth it. Each simple number would have to carry a presentation along > with it... > I doubt that anybody would want her patches 100% broken when switching > from Max 5.x to Max 6, though computing power might be so much higher, > that you don't know anymore how to burn it... > > It is like with going from C to C++, it had to be a new language. > (And the world is still using this bad hack of a language called C...) > > Stefan >