> > On 8 Aug, 2013, at 3:28 PM, Kevin Meaney <[email protected]> wrote: > >> I could well be wrong as I'm working from ancient memory but I believe c >> upgrades floats to doubles to perform calculations and then if result is >> stored in a float it will chuck away precision at time of assignment to the >> float. >> >> I would repeat the recommendations of other to try using vlib. >> >> I gather from original question when OP referred to narrowing down to a few >> functions that this was achieved by profiling. >> >> Kevin >> > > shouldn't do that as long as one uses the correct functions, ie sinf() and > cosf(). Indeed if you just use sin() and cos() it will upgrade them to doubles > and then cast them back down again, getting yet slower in the process than it > was before. > > Without seeing the algorithm it's hard to say for sure but the OPs comment > that float gave 'completely wrong answers' feels a bit odd. You'd have to have > a very long string of calculations for the error between floats and doubles to > add up to something which is 'completely wrong'. Could happen, but I'd look > for bugs before discarding floats totally. I'd also probably look see if > there's another algorithm, or if you can seed one day with the data from the > previous/next one and start close to the right answer. > > Regrettably OpenCL hasn't made it to iOS yet, dumping massively parallel > calculations like this onto the GPU can work wonders although I'm not > well-enough versed with it to say whether the trig performance on a GPU sucks > enough to make it not worthwhile. > > One last option is not to require a month at a time to be calculated. Much > like populating UITableViews, if you can focus on the day someone's looking at > right now and get that one done first, you can always calculate a few likely > next ones in the background. App looks super responsive, under the water it's > paddling like a crazed duck but always prioritizing the thing you need on > screen right now. That is sometimes just a matter of changing the UI a bit. > > Another last option is to pre-calculate a load of this data, see if there is a > bulk of the calculation which is say independent of the user's location, work > that out and cache it, then finish the calculation off for the user's actual > position. Again this all depends on exactly what you're trying to do. >
I am looking at caching things and I did find one stray time-waster: [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar] This is called from C (not Cocoa) so I am looking at the best way to do this once and pass the NSCalendar object to where it is needed. _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
