iOS Object in array is being skipped

[moonman239]

So here's the deal. I have an NSTimer set up to fire an event when the given time elapses. This timer is reset, and the time interval changed, a few times. EDIT: This code is inside the changeText method. When I ran it on my iPhone, it practically skipped over the third string in the array. I should add that by the time the OS gets to executing the relevant code, it does not change the time interval on the timer. However, I just enclosed the second line in another if() block so the phone will to see if resetting the timer is necessary. I'll see if that solves my problem.

Because I don't want to accidentally give too many details, I will only include a small portion of the app's code. I've also taken out anything that might reveal what I'm working on.

if (thecount >= 12 & thecount <= 16)
            {
myTimer = [NSTimer scheduledTimerWithTimeInterval:7 target:self selector:@selector(changeText:) userInfo:nil repeats:YES];
                NSArray *atSentenceArray = // array of strings
                self.myLabel.text = [atSentenceArray objectAtIndex:(thecount - 12)];
}

 

[mjohnson1212]

if (thecount >= 12 & thecount <= 16)

I'm guessing you actually mean:

if (thecount >= 12 [B]&&[/B] thecount <= 16)

 

[moonman239]

I'm guessing you actually mean:

if (thecount >= 12 [B]&&[/B] thecount <= 16)

It seems to function quite well with just a single ampersand. Anyways, the code modification I mentioned in my OP was not a solution. However, I added the extra ampersand and will see if it makes a difference. Edit: Doing so did not help at all.

 

[dejo]

It seems to function quite well with just a single ampersand.

Do you understand the difference between & and &&?

 

[PhoneyDeveloper]

What does this mean:

it practically skipped over the third string in the array

What were the contents of the array when that happened?

What was the value of theCount when that happened?

 

[Sonnestah]

Your logic is the problem, so it is impossible to debug if you don't give us your code, the expected results and the actual result.

& is a reference, similar to a pointer
&& is the logical AND operator

As you can see & and && are two completely different things, you should grab a basic tutorial and study it from the beginning before moving to more complex stuff to avoid this kind of problem and if you wish to finish your app this decade still.

 

[dejo]

Your logic is the problem, so it is impossible to debug if you don't give us your code, the expected results and the actual result.

OP, if you don't want to reveal too much about your project, create a small sample app to demonstrate your issue. Then post that code, along with, as suggested, your expected and actual results.

& is a reference, similar to a pointer

True, but it's also a bitwise AND operator which is how it's being interpreted in the given example.

 

[chown33]

Your logic is the problem, so it is impossible to debug if you don't give us your code, the expected results and the actual result.

This part I agree with. Especially the parts about describing the expected result and the actual result.

I have no idea what "it practically skipped over the third string in the array" means. There is insufficent code or description to permit replication of the problem.

& is a reference, similar to a pointer
&& is the logical AND operator

This part I disagree with. The interpretation of & in this case is as the bit-wise AND operator. That is, the bit-pattern from the 1st expression is ANDed with the bit-patter of the 2nd expression, and the block is executed conditionally based on the zero/non-zero result:
http://en.wikipedia.org/wiki/Operators_in_C_and_C++
Both expressions are evaluated before their AND is calculated. Since both expressions use a magnitude-comparison, both values will be 0 or 1.

There's no way to interpret the single & as being an "address-of" operator. See C's rules for operator associativity and precedence.

 

[Sonnestah]

True, but it's also a bitwise AND operator which is how it's being interpreted in the given example.

This part I disagree with. The interpretation of & in this case is as the bit-wise AND operator. That is, the bit-pattern from the 1st expression is ANDed with the bit-patter of the 2nd expression, and the block is executed conditionally based on the zero/non-zero result:
http://en.wikipedia.org/wiki/Operators_in_C_and_C++
Both expressions are evaluated before their AND is calculated. Since both expressions use a magnitude-comparison, both values will be 0 or 1.

There's no way to interpret the single & as being an "address-of" operator. See C's rules for operator associativity and precedence.

True, my bad.

 

[1458279]

You can't expect us to help solve your problem without more of the code. All we should need is the part where you walk thru the array.

If you don't want to post the code, there should be tons of examples online and in books showing how to walk an array.

You can also put in a break point where the array is and step thru it.

 

[Duncan C]

It seems to function quite well with just a single ampersand. Anyways, the code modification I mentioned in my OP was not a solution. However, I added the extra ampersand and will see if it makes a difference. Edit: Doing so did not help at all.

Single ampersand is absolutely, without a doubt wrong, and will not do the right thing. You may think it is doing the right thing, but it's not. It will probably give the correct result most of the time.

A single ampersand, as others have said, is a bitwise AND. It takes the 2 arguments, left and right, and for each bit, only sets the bit of the result of both source bits are 1. That is not what you want in a logic statement.

In an IF statement like yours, you want &&.

 

[ArtOfWarfare]

Single ampersand is absolutely, without a doubt wrong, and will not do the right thing. You may think it is doing the right thing, but it's not. It will probably give the correct result most of the time.

A single ampersand, as others have said, is a bitwise AND. It takes the 2 arguments, left and right, and for each bit, only sets the bit of the result of both source bits are 1. That is not what you want in a logic statement.

In an IF statement like yours, you want &&.

You can actually use an & between things that return a 0 or 1 and it'll act nearly identically to an &&. The only difference is that && will short circuit if the first value is a 0 whereas & will not. If the second value is actually a function that has desirable side effects, a & might be better than a &&. Of course, you'll be relying on a somewhat obscure behavior of C so it's likely that at some point someone will come along and "fix" your code by replacing them with &&.

Now that I think about it, it makes me wonder: why don't other functions short circuit when they hit a 0? When the first operand of a multiplication or bitwise & is equal to 0, you know the result is going to be zero regardless of what the second operand is.

 

[chown33]

Now that I think about it, it makes me wonder: why don't other functions short circuit when they hit a 0? When the first operand of a multiplication or bitwise & is equal to 0, you know the result is going to be zero regardless of what the second operand is.

First, define your domain. Then explain where the opportunity for short-circuit lies.

Multiplication operates on domains of integer or floating-point values. The hardware (or software) may well have an optimization that looks for either operand being zero, and immediately returns zero without carrying out a full multiplication. When I've written software for extended precision multiplication, it may or may not be a speed improvement to look for zeros. Making a separate pass thru each multi-byte value adds cycles. If there isn't a zero, then those cycles were wasted, which increases the worst-case time. Sometimes it's better to have a smaller range of completion times, rather than lower zero-times and higher non-zero times. These days, single-cycle multipliers are fairly common, so the cost of looking for zeros may not be worth paying.

Bitwise AND operates on multiple bits stored in integer types. Since the result is another integer containing multiple bits, where would you put a short-circuit? Each bit in the result must be 1 or 0 according to the two corresponding input bits. I see no way to avoid evaluating some portion of the operands. An ALU performs all those bit-wise ANDs in parallel, not sequentially. In any case, AND and other bit-wise booleans are usually the fastest and simplest of all ALU operations.
http://en.wikipedia.org/wiki/Arithmetic_logic_unit

Finally, the C language guarantees that bitwise boolean operations evaluate all operands. So even if the CPU could short-circuit (and I don't see how that would logically work), a C compiler must still evaluate expressions as if it didn't.