bitwise reversal
hi,
how would you reverse the order of bits in an integer?
for example:
00010011 -> 11001000
10000010 -> 01000001
thanks, james.
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
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.
my object library can be downloaded here: www.jasch.ch/dl/
hth
/*j
max 4.x version below
An example with standard objects:
_
johan
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.
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:
?
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.
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.
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
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...
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...
----------------------------------------------------
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
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.
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.
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
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
>