On Mar 2, 2015, at 20:18 , Patrick J. Collins <[email protected]>
wrote:
>
> The problem doing it this way s that
> sometimes I need this to work with an array of ints... NSNumber and NSArray
> gave me the flexiblity of being able to use floats/ints and not have it
> matter.
It didn’t *not* matter, really. If your NSNumbers boxed floats sometimes and
ints other times, you should strictly have been using ‘floatValue’ sometimes
and ‘intValue’ other times. Applying ‘floatValue’ to a boxed int only works if
the int is small enough to be representable as a float. So let’s assume that
and continue…
> Now, with this approach, I am not sure how to handle ints without having
> another method with duplicate code.
There are multiple approaches, depending on the level of performance you need:
— You can write duplicate code, which is probably not terrible if there are
only two underlying types. You can actually write the code only once, by
putting it in a macro, then invoking the macro in 2 different contexts.
(Welcome the world of C !)
— Since we’re assuming that the ints fit in a float, you could do one-time
conversion from int to float for your original input buffer, and a one-time
conversion from float to int for your final output buffer.
— You can use a pseudo-subscripting function to retrieve individual samples
from your buffer, and have the function know which type of value is stored. By
declaring the function inline, you can avoid function-call overhead, and the
compiler will probably do a pretty good job of optimizing the resulting mess of
code.
I’d be inclined to try the 2nd of these 3 options, since it simplifies
everything else by pushing the housekeeping to one place at the beginning and
end of each processing sequence.
I’d also be inclined to wrap the sample buffer, and its size, and its
conversions, in a custom Obj-C object. That way you don’t have to supply a
passel of arguments to every call, just a single object reference — or even
just make the larger units of behavior be methods of this custom object, so the
reference is implicit.
There’s some analogy here with NSString, which has high-level methods with
UTF-16 semantics for convenience, but which (sometimes) might have an internal
UTF-8 representation of its characters, and which (always) can return a UTF-8
buffer of its characters, if you want it.
> Also, I thought I'd also bring up my lack of familiarity with C gives me some
> confusion about how to pass arrays around.
>
> So, if I understand correctly, if I have an array of a large size (not sure
> what that means, or how large), I can't just do:
> float floats[] = { ... }
>
> I need to actually do
>
> float *floats = (float *)malloc(size * sizeof(float));
Correct, you must use malloc, or something equivalent, like calloc, or even
NSData. The ‘[]’ declaration form is only suitable for arrays that are fixed at
compile time.
> and then I have to use &floats instead of floats?
>
> [ClosestValueFinder indexFor:-1.0f floats:&floats size:size];
No, absolutely not. The earlier declaration makes the type of ‘floats’ be
‘float*’, which is what this method expects. The type of ‘&floats’ is
‘float**’, which isn’t the right thing.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Objc-language mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/objc-language/archive%40mail-archive.com
This email sent to [email protected]
