Code Optimization [java]

I'm working on a project that requires that I use processing. I am not too proficient with Java. I have written these retard-tier methods:


  color removeFromColor(int c, int subtraction)
  {
    for (int i = 16; i >= 0; i -= 8) {
      if ((c >> i & 0xFF) - subtraction > 0) {
        c |= (0 << i);
      } else {
        c -= (subtraction << i);
      }
    }
    return c;   
  }
 
  color addToColor(int c, int addition)
  {
    for (int i = 16; i >= 0; i -= 8) {
      if ((c >> i & 0xFF) + addition > 255) {
        c |= (255 << i);
      } else {
        c += (addition << i);
      }
    }
    return c;
  }

As you can perhaps guess, I would prefer if these methods were written as one private (factory?) method, with two wrapper methods for add and remove that modify the behavior of the main method. Unfortunately, I am not skilled enough to come up with an elegant solution. All of my design attempts thus far have resulted in overly-complicated, unnecessary bloat, or at least worse code than if I had just stuck to keeping two very-similar-yet-different methods.

Since in practice these are working just fine at the moment, I am asking this only out of curiosity. How would you optimize this? Or would you bother at all?

[java]
NO THANK YOU

Oops, I didn't revert my changes all the way. Here are the methods:

  color removeFromColor(color c, int subtraction)
  {
    for (int i = 16; i >= 0; i -= 8) {
      if ((c >> i & 0xFF) - subtraction < 0) {
        c |= (0 << i);
      } else {
        c -= (subtraction << i);
      }
    }
    return c;   
  }
 
  color addToColor(color c, int addition)
  {
    for (int i = 16; i >= 0; i -= 8) {
      if ((c >> i & 0xFF) + addition > 255) {
        c |= (255 << i);
      } else {
        c += (addition << i);
      }
    }
    return c;
  }

OP wants us to do his homework for us, that's nice. Now get lost.

>>4
Since in practice these are working just fine at the moment, I am asking this only out of curiosity.

It's not homework, expert. I have a feeling that the answer could lie among functional programming concepts, which is the only reason I laid my code at the foot of the λ knights.

This thread involves bitwise operation.  All bits are subject to controlled shifting in this zone.

>>5
Obviously you're a                           µ                         _expert programmer in your way through Java's enlighment path to develop TURNKEY SOLUTIONS.
The best approach to this problem could be having an interface and using a IOC container to inject a ^remote JavaBean. The implementation is left as an exercise to the reader.

c |= (0 << i);
How would you optimize this?
Using PSUBUSB and PADDUSB.

>>8
... in Java?

>>8
[IABT]Get rid of the statement[/IABT]

Just as expected. A thread full of typical, half-assed Java trolling. OP could have claimed he was writing in C and no one would have been any the wiser.

>>11
Alright, alright, shut up.  As this is Java you might as well make these static since they don't affect whatever this object is.  Secondly, how can the return type be declared "lowercase-color" but the actual return type an int?

static color modifyColor(int c, int mod)
{
   if(mod != 0)
   {
      int d = (mod > 0 ? 255 : 0);
      int i = 16;
      for(; i >= 0; i -= 8)
      {
         if((c >> i & 0xFF) + mod > d)
         {
            c |= (d << i);
         }
         else
         {
            c = (mod > 0 ? c + (mod << i) : c - (-mod << i));
         }
      }
   }
   return c;  
}

The only reason I used the ternary operation in the else case is because I can not remember if a negative number's two's complement is considered properly in this bitwise shift/addition statement.  I don't want to assume what you consider the correct output.  I'm assuming you already determined this is the case, however, since you are so confident that you did not check your input for its sign.  If not, then you can just use c += (modification << i);.

Further question: why do you want to make this class method private?

>>12
if((c >> i & 0xFF) + mod >  d)

Yeah, see, this is the thing. I accidentally let this logic be the same in both methods in the OP, because I had copy-pasted without fully undoing what I had done to the original code. It's corrected in  >>3. In add, I need to cap the value from increasing past 255, but in remove, I need to prevent it from decreasing past 0. So, in one case I need >, and the other, <.

Incidentally this is also the line that stumped me. I couldn't see a way around it aside from writing two separate if statements, which seemed like a clumsy solution.

color is just a processing "datatype"; it's really no different from an int and from my experience thus far can be used interchangeably, although for clarity the argument should be color (also corrected in >>3).

The method is private because the object as a whole is a shape, and this is a method used in both gradient and highlighting code, although you do make a good point in that it should probably be changing the state of the object.

As for the sign of the integer, this method is only being fed constants, but I appreciate your insight regardless. I guess there's no unsigned in Java?

>>13
All numeric primitives in Java are signed.  As far as I can tell, there's no way to change this. Except through effort.
http://darksleep.com/player/JavaAndUnsignedTypes.html

I submit version two:
int x = (d == 0 ? -1 : 1);
if( ((c >> i & 0xFF) + mod)*x > d)
If mod is positive, then addition and 256 > 255 is true if the addition goes over; if mod is negative, then subtraction and 1 > 0 is true if the subtraction goes under.  It does create one more conditional to evaluate but it saves on branching the whole method into two ifs.

If you want the positive constants for addition and subtraction, I'm at a loss what I could suggest right now.
On another note, I can REUSE x to get rid of my ugly ternary and its ambiguity:
c += x*(Math.abs(mod) << i);

I would prefer if these methods were written as one private (factory?) method, with two wrapper methods for add and remove that modify the behavior of the main method.
Son, I'm pride. You already seem to begin thinking in an ENTERPRISE fashion.
All of my design attempts thus far have resulted in overly-complicated, unnecessary bloat, or at least worse code than if I had just stuck to keeping two very-similar-yet-different methods.
But you're not quite there yet, unfortunately.
The best approach to this problem could be having an interface and using a IOC container to inject a remote JavaBean.
OP, listen to this person.
Also, in order to ensure proper SCALABILITY you should consider implementing those operations for a general abstract color representation first, and only then provide a way to process a less-general RGB.

You could just overload operator+ and operator- in your class to perform arithmetic with saturation.

Java

Nevermind.

>>14
You've been very helpful and your work is clever. I suppose the solution was much simpler than I had thought it would be, which is perfect!

Lest I turnkey into an ENTERPRISE programmerDEVELOPER.

bump

bump

>>18-19
Quit bumping my thread, ``faggot.''

bump

bump

BUMP MY ANUS

Don't change these.

Name:		Email:
Entire Thread Thread List