Picking a random bitwise value from a given number

[Legacy_Kato -]

               Okay I see, thanks everyone once more for these tons of infos, I'll probably dream of binaries this week lol.


Kato
               
               

               

                     Modifié par Kato_Yang, 14 novembre 2011 - 06:33 .
                     
                  

            

[Legacy_WhiZard]

               

Axe_Murderer wrote...

Watch out for the circular shift operator in NWN. It doesn't sign extend correctly so it isn't any different than the regular shift right op.

If you mean >> versus >>>, the difference has been described above.  If you can find documentation that the >> is intended to be "circular shift" and the >>> is intended to be logical shift, I would appreciate it.  But the documentation of the lyceum of the lexicon doesn't seem to have actually tested either >> or >>> before documenting them.
               
               

               
            

[Legacy_FunkySwerve]

               At the risk of straying very far off-topic...WOW at the 5-year dev cycle on NWN. And we wonder why poor Obsidian came up short on 2...heh.

Funky
               
               

               
            

[Legacy_WhiZard]

               Had a light shine on marble head.  The internal Toolset scripting uses a data-type not available in NWScript.  The designation "char" specifies a one byte character that is used for ability modifiers, etc.  When typed into NWScript "char" will show up in blue, but will be treated as a variable just like a random arrangement of letters would be.  Given the lyceum examples are all for one byte, it could be that what is being reported for >> and >>> could be for "char" and not "int".
               
               

               
            

[Legacy_FunkySwerve]

               A byte is 8 bits, and what is being reported by the shifts is 32, so no. The char type is just the building block of string lists in C - they dumbed it down slightly in nwscript.

Funky
               
               

               
            

[Legacy_WhiZard]

               

FunkySwerve wrote...

A byte is 8 bits, and what is being reported by the shifts is 32, so no. The char type is just the building block of string lists in C - they dumbed it down slightly in nwscript.

Funky

The shift return for integers (which is all we can test) returns an integer (32 bit).  Character is not used in NWScript as its designation "char" is not usable.  However, internally this is another story.  I am not talking about scripts viewable in the Toolset, but those like "x3_mod_pre_enter" which can be executed by NWScript but the script itself cannot be viewed within the Toolset.
               
               

               
            

[Legacy_FunkySwerve]

               Yes, I understand that. What I don't understand is how you could be suggesting the engine is using a char to hold or manipulate shifts, or why, given the additional bits involved. Can you elaborate?

Funky
               
               

               
            

[Legacy_WhiZard]

               

FunkySwerve wrote...

Yes, I understand that. What I don't understand is how you could be suggesting the engine is using a char to hold or manipulate shifts, or why, given the additional bits involved. Can you elaborate?

Funky

Reasons:
Lexicon definitions are all way off for >> and >>>.  The only examples used are 8-bit returning 8-bit values
"char" is colored as a datatype and its name appears in the text of multiple data files when viewing in NWexplorer
There are many game mechanics that are often "bugged" because of 8-bit loops
Char in C is used as storage for 8 bits
Some functions like GetSpellSaveDC() are only bugged (by 8-bit loop) for one of the arguments being added.

EDIT: I am not suggesting that a "char" is being used to shift an integer, I am suggesting that a "char" is a weird 8-bit value that itself is being shifted.
               
               

               

                     Modifié par WhiZard, 15 novembre 2011 - 02:15 .
                     
                  

            

[Legacy_FunkySwerve]

               I don't see what bearing a Lexicon example has on Bioware's original design, as they didn't write the Lexicon.

Likewise, I don't see the relevance of char being colored as a datatype - it's likely a holdover from C. Action is also colored, and we can't even use it. Pragma is also colored, but not used by the bioware compiler. And so on.

By 8-bit loops, I assume you mean field wraps - this is normal fallback behavior for a field, as I understand it. Also, the engine still handles the values correctly, unlike the bit field ops - take ab, for example. It wraps into negative values, but they are still handled as higher values. By contrast, the bit ops simply error, acting in ways they should not, as fox et al. have pointed out.

In C, char is 8 bits, but it isn't really 'storage' for them - it's just the number used by most character sets to define their characters - hence the name. A byte is the more common name for 8 bits.

I'm not trying to be belligerent, but I really don't understand your reasoning at all. If bit shifts were being passed through an 8-bit chokehole at any point, the function that I pasted on the previous page would've errored at FAR lower values than the 32nd bit. Unless, of course, you're getting at something I'm just not understanding...

Funky
               
               

               
            

[Legacy_WhiZard]

               

FunkySwerve wrote...

I don't see what bearing a Lexicon example has on Bioware's original design, as they didn't write the Lexicon.

No, but it is odd for information to be so far off left field if the writers didn't read something that BioWare said or posted.

Likewise, I don't see the relevance of char being colored as a datatype - it's likely a holdover from C. Action is also colored, and we can't even use it. Pragma is also colored, but not used by the bioware compiler. And so on.

"Pragma" and "pragma" is not colored in my Toolset.  "action" is still a data type and is not disabled so that it can be used as a variable.  Also "void"s can be stored as "action"s as in ActionDoCommand(), so internally "action" is used.

By 8-bit loops, I assume you mean field wraps - this is normal fallback behavior for a field, as I understand it. Also, the engine still handles the values correctly, unlike the bit field ops - take ab, for example. It wraps into negative values, but they are still handled as higher values. By contrast, the bit ops simply error, acting in ways they should not, as fox et al. have pointed out.

Like GetSpellSaveDC() adding 256 in some applications when the modifier is negative and not others.

In C, char is 8 bits, but it isn't really 'storage' for them - it's just the number used by most character sets to define their characters - hence the name. A byte is the more common name for 8 bits.

If the NWScript "char" is a data type I am suggesting, then it would be a weird one, possibly with IntToChar() and CharToInt() functions.

I'm not trying to be belligerent, but I really don't understand your reasoning at all. If bit shifts were being passed through an 8-bit chokehole at any point, the function that I pasted on the previous page would've errored at FAR lower values than the 32nd bit. Unless, of course, you're getting at something I'm just not understanding...

I am not saying all bit shifts just the bit shifts performed on characters.  For example ALT + 0255 character might left shift to a ALT + 0254 character.
               
               

               

                     Modifié par WhiZard, 15 novembre 2011 - 04:47 .
                     
                  

            

[Legacy_FunkySwerve]

               Sorry, pragma was a bad example - it's used by Skywing's compiler, but is colored because it's preceded by a #. The fact that C data types are highlighted by the NWN toolset doesn't really mean much to this discussion, was my point. It smacks of conspiracy theorizing. '>

I am not saying all bit shifts just the bit shifts performed on characters.  For example ALT + 0255 character might left shift to a ALT + 0254 character.

Still not really understanding what you're saying in the slightest. Earlier you said:

Given the lyceum examples are all for one byte, it could be that what is being reported for >> and >>> could be for "char" and not "int".

I don't see anything about bit shifts on characters there, or anywhere else in this thread. You've totally lost me. If bit shifts were somehow casting their results into an 8-bit datatype at any stage, you couldn't do what I did in the function on the previous page - data loss would produce wildly distorted results. I really have no idea what you're suggesting anymore. Is anyone else able to understand what WhiZard is suggesting?

Funky
               
               

               
            

[Legacy_WhiZard]

               

FunkySwerve wrote...
It smacks of conspiracy theorizing. '>

Theorizing, yes.  Conspiracy, well I'll just repeat '>.

I am not saying all bit shifts just the bit shifts performed on characters.  For example ALT + 0255 character might left shift to a ALT + 0254 character.

Still not really understanding what you're saying in the slightest. Earlier you said:

Given the lyceum examples are all for one byte, it could be that what is being reported for >> and >>> could be for "char" and not "int".

I don't see anything about bit shifts on characters there, or anywhere else in this thread. You've totally lost me. If bit shifts were somehow casting their results into an 8-bit datatype at any stage, you couldn't do what I did in the function on the previous page - data loss would produce wildly distorted results. I really have no idea what you're suggesting anymore. Is anyone else able to understand what WhiZard is suggesting?

Funky

I am saying there might be two different shifts for each bit shift symbol (>>, >>>, <<) one that will work for characters and one that will work for integers.  The result for integers may have been an afterthought, with the intended behavior provided for the use on characters.  Hope that helps.  And, yes, I am in far off speculation stage.
               
               

               

                     Modifié par WhiZard, 15 novembre 2011 - 01:58 .
                     
                  

            

[Legacy_FunkySwerve]

               I'm still waiting to hear what you think chars have to do with this thread. Even if they did, there is utterly no reason to think nwn's devs would've come up with a separate set of shift operators for them, since they are just truncated versions of ints, when it gets down to the bits. Lastly, there is utterly no evidence of this disparate treatment - it doesn't explain anything observed in this thread.

Funky
               
               

               
            

[Legacy_Lightfoot8]

               

WhiZard wrote...

Lightfoot8 wrote...

i.e. 
nNumber  logicly shifted right x bits would be: 

~(~nNumber >>> x)    
  

There is a flaw here.  ~nNumber would be using the master bit of 0, shifting it to the right, and then the next ~ would take the master bit and all its replications and turn them back into 1's.

EDIT This should work
int LogShift(int nNumber, int nPlaces)
  {
  if(nNumber < 0)
    {
    nNumber = nNumber ^ (1 << 31);
    nNumber = nNumber >>> nPlaces;
    //Reset the new bit position of the first bit
    nNumber = nNumber | (1 << (31 - nPlaces));
    }
  else nNumber = nNumber >>> nPlaces;
 return nNumber;
}

Yep,  you are right my version posted was also bugged.
your version works nicely, but I would still would prefer a version without an If statment in it.   Would: 

int Shr ( int Nnumber, int x)
{
 return (nNumber>>>x) & ( (1<< 32-x )-1);
}
meet your scrutiny. Whizard points out the flaw again

EDIT: If anyone is interested here is a IntToBinaryString function. 

string  IntToBinaryString ( int nInteger)
{
  int x;
  string sBinary;
  for (x=0; x<32; x++)
  {
    if (nInteger & 1) sBinary =  "1" + sBinary ; else sBinary ="0"  + sBinary ;
    if ( (x+1)%4 == 0 ) sBinary = "_" + sBinary;
    nInteger = nInteger >>>1;
  }
return sBinary;
} 
               
               

               

                     Modifié par Lightfoot8, 16 novembre 2011 - 11:30 .
                     
                  

            

[Legacy_WhiZard]

               

Lightfoot8 wrote...

Yep,  you are right my version posted was also bugged.
your version works nicely, but I would still would prefer a version without an If statment in it.   Would: 

int Shr ( int Nnumber, int x)
{
 return (nNumber>>>x) & ( (1<< 32-x )-1);
}
meet your scrutiny.

One flaw there for x (the shift places value) being 0 (or 0 mod 32).  1<< 32 == 1<< 0 == 1.  Thus we get a zero return value instead of a nNumber return.