Convert a string of numbers to a NSTimeInterval - iphone

I know I must be over-complicating this because it NSTimeInterval is just a double, but I just can't seem to get this done properly since I have had very little exposure to objective c. the scenario is as follows:
The data im pulling into the app contains two values, startTime and endTime, which are the epoch times in milliseconds. The variables that I want to hold these values are
NSTimeInterval *start;
NSTimeInterval *end;
I decided to store them as NSTimeIntervals but im thinking that maybe i ought to store them as doubles because theres no need for NSTimeIntervals since comparisons can just be done with a primitive. Either way, I'd like to know what I'm missing in the following step, where I try to convert from string to NSTimeInterval:
tempString = [truckArray objectAtIndex:2];
tempDouble = [tempString doubleValue];
Now it's safely stored as a double, but I can't get the value into an NSTimeInterval. How should this be accomplished? Thanks

You don't have to cast, you can just write this:
NSTimeInterval timeInterval = [[truckArray objectAtIndex:2] doubleValue];
The cast is needless, and extra casts just make your source code harder to update and change in the future because you've told the compiler not to type-check your casted expressions.

The variables that I want to hold these values are NSTimeInterval *start; NSTimeInterval *end;
Careful, NSTimeInverval is a typedef for a primitive C type, it is not an Objective-C object. I don't think you actually need pointers to these types in this scenario, so you should declare them like this:
NSTimeInverval start;
NSTimeInterval end;
You could be getting errors because in C, you cannot convert floating-point types to pointer-types.

Related

How to convert NSTimeInterval to int?

How do I convert NSTimeInterval into an Integer value?
My TimeInterval holds the value 83.01837. I need to convert it into 83. I have googled but couldn't find any help.
Direct assignment:
NSTimeInterval interval = 1002343.5432542;
NSInteger time = interval;
//time is now equal to 1002343
NSTimeInterval is a double, so if you assign it directly to a NSInteger (or int, if you wish) it'll work. This will cut off the time to the nearest second.
If you wish to round to the nearest second (rather than have it cut off) you can use round before you make the assignment:
NSTimeInterval interval = 1002343.5432542;
NSInteger time = round(interval);
//time is now equal to 1002344
According to the documentation, NSTimeInterval is just a double:
typedef double NSTimeInterval;
You can cast this to an int:
seconds = (int) myTimeInterval;
Watch out for overflows, though!
In Swift 3.0
let timestamp = round(NSDate().timeIntervalSince1970)
I suspect that NSTimeInterval values from NSDate would overflow an NSInteger. You'd likely want a long long. (64 bit integer.) Those can store honking-big integer values (-2^63 to 2^63 -1)
long long integerSeconds = round([NSDate timeIntervalSinceReferenceDate]);
EDIT:
It looks like an NSInteger CAN store an NSTimeInterval, at least for the next couple of decades. The current date's timeIntervalSinceReferenceDate is about 519,600,000, or about 2^28. On a 32 bit device, and NSInteger can hold a value from -2^31 to 2^31-1. (2^31 is 2,147,483,648
Swift 4, Swift 5
I simply cast to Int64:
Int64(Date().timeIntervalSince1970)
I had a need to store an NSDate in a Swift Number. I used the following cast which is working great.
Double(startDateTime.timeIntervalSince1970)

What is the fastest routine to convert NSArrays to C-style (double) arrays?

I have 2 NSArray (Mutable, actually) that I am trying to convert to a C-style double array for a c routine i am passing them to.
Here is my Objective-C routine:
NSMutableDictionary *childDictionary = [myParentDictionary objectForKey:resort_code];
latitudeArray = [childDictionary objectForKey:#"lat"];
longitudeArray = [childDictionary objectForKey:#"lon"];
int nvert = [latitudeArray count];
double laArray[nvert];
double loArray[nvert];
for(int i=0; i<nvert; i++) {
double dLat = [[latitudeArray objectAtIndex:i]doubleValue];
double dLon = [[longitudeArray objectAtIndex:i]doubleValue];
laArray[i] = dLat;
loArray[i] = dLon;
}
This takes upwards of 3-8 seconds on the 3G iPhone (instantaneous on the simulator -- yet another reason to test on the device )
is there faster way? I have to end up with laArray[i] and loArray[i] as c-style arrays of doubles.
(to expand on the question for the benefit of a commenter):
Each array consists of #"38.448745" (lat) and #"-122.9847684" (lon) style content. I do this cos to be pushed onto an NSArray, the lat and lon need to be objects. I simply used:
[latitudeArray addObject:[NSString stringWithFormat: #"%.10f",dlat]];
[longitudeArray addObject:[NSString stringWithFormat: #"%.10f",dlon]];
I suppose I could change that to:
[latitudeArray addObject:[NSNumber numberWithDouble: #"%.10f",dlat]];
[longitudeArray addObject:[NSNumber numberWithDouble: #"%.10f",dlon]];
...which may reduce the conversion time of
double dLat = [[latitudeArray objectAtIndex:i]doubleValue];
but wouldn't I still need that exact line to convert from NSString to double? It just may work faster?
thx
dlat is a double, right?
So instead of:
[latitudeArray addObject:[NSString stringWithFormat: #"%.10f",dlat]];
Do:
[latitudeArray addObject:[NSNumber numberWithDouble:dlat]];
They both respond to doubleValue but the NSNumber should not have to do any string parsing since it's stored as a numeric value already. And you never have to go to a string at all.
I suspect you have an array of strings like #"213.12385" that need to be parsed and converted when you call doubleValue on them. If that is where the issue is, the C arrays have nothing to with this.
Only thing I would add here is to throw Shark on this and see where it's spending it's time. If it's spending time in doubleValue find a different way to parse the strings with preprocessing in background or something. If it's in objectAtIndex: perhaps fast enumeration would help. If it's somewhere else entirely then you know it's not this snippet that's slow.
For the general case of converting an NSArray to a C array, you can use getObjects:. In this case, though, want you actually want is not to convert the NSArray, but to derive an array of doubles from an NSArray of some unspecified object type.
One obvious way to speed things up would be fast enumeration rather than sending a message to get the object for each iteration of the loop. I suspect the real solution, though, is outside your algorithm. The slowness probably comes from transforming whatever objects the array contains into doubles, in which case you'll need to find a way around that — maybe store doubles all along, maybe do the conversion in the background, etc. If you're creating the arrays yourself and there isn't some compelling reason for the objects to be strings, you should use NSNumbers instead. Those should be quite a bit faster.
The best solution is probably to make sure those values never end up in an NSArray as NSString values. I would attack this at the source.
So you edited your question and added that you are actually building those arrays. So why not use native arrays of doubles or floats from the start? I usually recommend against this but in your case it sounds like there is a huge performance gain.
Possibly using fast iteration, but I doubt that will really speed up your loop.

objective-c converting strings to usable numbers

I have strings that look about like this:
stringA = #"29.88";
stringB = #"2564";
stringC = #"12";
stringD = #"-2";
what is the best way to convert them so they can all be used in the same mathmatical formula?? that includes add, subtract.multiply,divide etc
Probably floatValue (as it appears you want floating-point values), though integerValue may also be of use (both are instance methods of NSString).
[stringA doubleValue]
These are all wrong, because they don't handle errors well. You really want an NSNumberFormatter.
If you have the string #"abc" and try to use intValue or floatValue on it, you'll get 0.0, which is obviously incorrect. If you parse it with an NSNumberFormatter, you'll get nil, which is very easy to distinguish from an NSNumber (which is what would be returned if it was able to parse a number).
Assuming that you have NSString variables.
NSString *stringA = #"29.88";
NSString *stringB = #"2564";
NSString *stringC = #"12";
NSString *stringD = #"-2";
suppose, you want to convert a string value to float value, use following statement.
float x=[stringA floatValue];
suppose, you want to convert a string value to integer value, use following statement.
NSInteger y = [stringC intValue];
Hope, it helps to you.

Secure and valid way for converting a "float integer" into a natural integer?

I have a CGFloat that contains only "integers", in the meaning that it actually wants to represent integers only but due to float inprecision it may happen that it internally has a 23.00000000000000000000000142 or something like that. I try to feed an NSDecimalNumber with clean input, so I need to make sure this is truly a naked integer with no dirt. Well, I think this is a good way, but maybe I am wrong:
NSInteger *intVal = floatVal;
That would just get rid of those fragmental parts at the end of the tale, right? Or is there a more secure way to convert it into a true integer?
If you just want to take the integer part of a float then I believe you can just do the following:
CGFloat myfloat = 23.0000000000142f;
int myInt = (int) myfloat;

Is it valid to ask an NSNumber for an NSDecimal value whe the NSNumber was initialized with an Integer?

Example: I have an NSInteger and I wrap that into an NSNumber object. Now I want to have an NSDecimal with the value of that NSInteger.
So could I ask:
NSDecimal myDecimalFromMyInteger = [myNSNumberObject decimalValue];
Or is this problematic on some way? Or must I always ask for the exact same value as I used to create the NSNumber object?
This is perfectly fine. From the docs:
"Returns the receiver’s value, expressed as an NSDecimal structure. ... The receiver’s value, expressed as an NSDecimal structure. The value returned isn’t guaranteed to be exact for float and double values."
As long as you're aware of the inherent precision implications, this is a perfectly legal and sane thing to do.