C / C++ / MFC

Re: Will casting / passing 16 bit int as double harm FFT processing?

28-Sep-14 4:40

Vaclav_Sal wrote:
So casting is a bad idea?

Not at all, but you need to understand what you are doing when you use it. A cast is used to tell the compiler that you want to treat one object type as another, and that you understand the potential side effects.

Vaclav_Sal wrote:
What exactly is the difference between cast and redefinition?

Not sure I understand what you mean by "redefinition" in this context.

Vaclav_Sal wrote:
I pass a pointer to this int array either by redefining it as double or as a cast.

That does not make sense, you cannot use a cast to pretend that an array of integers is an array of doubles, they are totally different types.

Vaclav_28-Sep-14 6:10

Re: Will casting / passing 16 bit int as double harm FFT processing?

28-Sep-14 6:10

Richard,
I read it as you have redefined int variable as double variable.

OK, this is getting into "what if" area.
I am going to build the raw data as double to start with and later on find a microprocessor with more RAM than this one so I do not have to limit the sample length.

Here is yet another question - because the original data is 10 bits and I do not want to carry any garbage in unused bits - how do I mask the 10 bits into double ( 32 bits) variable?
Which in these four 8 bits are the value and which are after the "decimal points" values?
Sorry , I just do not know the proper mathematical English terms.
Or maybe I just use "redefinition" from int to double on the result of the AD conversion, as you suggested, just KISS.

BTW as I suspected - the original raw data gets processed few times over to various FFT data. I need to analyze the original code to find out how did the raw data started as int array and was processed into double. IMHO that would messed up the memory big time - unless the int array dimension is doubled to make room for the half sized double array.
FFT results are "symetrical" , thus the "samples" are cut in half.
Fun.
Cheers Vaclav

Richard MacCutchan28-Sep-14 6:41

Re: Will casting / passing 16 bit int as double harm FFT processing?

28-Sep-14 6:41

No that was not a redefinition but a conversion.

C++

int integerValue = 233;
double doubleValue = integerValue; // the integer value is converted to a double
                                   // and stored in the new variable

I am getting a bit confused as to your raw data and what format it takes. If it is in integer form and you need to convert it to double values then you need to use expressions like the above to convert it.

It's a long time since I did any serious maths, so forgive me if I struggle to understand your questions.

Vaclav_28-Sep-14 8:35

Re: Will casting / passing 16 bit int as double harm FFT processing?

28-Sep-14 8:35

Lets try this approach

int integerValue = 233;
Orignaly the integerValue valid data is 10 bits instead of full 16
It is in two 8 bits registers
Only 10 bits are defined so I mask it with 0x3FF, that may be ovekill, but safe.

double doubleValue = integerValue; // the integer value is converted to a double
// and stored in the new variable

I understand the above , I used wrong therm calling it conversion.

My basic question is
what is the difference between these

function( doublevalue,...
function( (double) integerValue,....

BTW the parameter passed is a pointer.

Richard MacCutchan28-Sep-14 21:58

Re: Will casting / passing 16 bit int as double harm FFT processing?

28-Sep-14 21:58

C++

// the value passed in is already a double, or if not it will be converted
function( doublevalue,... 

// the integer value will be converted into a double. But you do not need a cast.
function( (double) integerValue,....

However, if you are passing a pointer to the array of integers then you connot use anything like the above. You must pass it as an integer pointer and the called function will then do the conversion. Something like:

C++

double function(int* myArrayOfIntegers, int count)
{
    double result = 0.0;

    for (int i = 0; i < count; ++i)
    {
        double temp = myArrayOfIntegers[i]; // get next integer and convert to double
        // do some calculations
    }
    return result;
}
// ....

// create an array to hold all the values
int* theIntegers = new int[theCount];
// fill the array from the source values
// ...

// send the array to be processed
double theAnswer = function(theIntegers, theCount);

Vaclav_29-Sep-14 4:06

Re: Will casting / passing 16 bit int as double harm FFT processing?

29-Sep-14 4:06

Hello Richard,
this is getting really interesting.
Here is some stuff to think about.
It all started by compiler complaining about integer pointer being passed to function expecting double pointer.
Second - I put together two sources - one collecting 10 bits of data into 16 bits integer array and not processing anything, just collecting.
The second source builds / emulates sine wave into array of doubles and that gets processed by FFT. So I replaced the emulated (double) data with real (integer) collected data.
My thinking is - if I cast or build a new variable as double it will take an 16 bit integer and process it as double, than what will happen to the original array ?
I am still learning about FFT , but as far as I can tell the first FFT function puts new data (normal pointer behavior) into the original (integer ) array as what ? Integer? I don't think so. ( And how is the pointer advanced? If as double will it skip next ADC data?)
I think the only way is to collect the ADC data into double array from get go.
And that was the OP question.
Thanks for all your help.
Cheers Vaclav

Richard MacCutchan29-Sep-14 5:27

Re: Will casting / passing 16 bit int as double harm FFT processing?

29-Sep-14 5:27

Vaclav_Sal wrote:
this is getting really interesting.

Not really, it's pretty basic stuff. As I said before, you cannot send a pointer to an array of integers to a function that expects a pointer to an array of doubles. The types are totally different so your program would just be processing garbage. I showed you in my previous message how to pass the array of integers to the function that needs the values as doubles. That is all there is to it, the compiler will generate the correct code to convert each integer to a double as you process them. The resulting double values can then be used in your FFT calculations.

Albert Holguin29-Sep-14 9:36

Albert Holguin

29-Sep-14 9:36

Vaclav_Sal wrote:
one collecting 10 bits of data into 16 bits integer array

This is common for transferring along byte boundaries. If you transmit 10bits, how many bytes are you moving across a network? ...yeah, integer numbers are desirable for network operations. Pretty much all receivers/digitizers do this.

Vaclav_Sal wrote:
if I cast or build a new variable as double it will take an 16 bit integer and
process it as double, than what will happen to the original array ?

When casting, nothing happens to your original data, a copy is made. Although as Richard already mentioned, you can't simply cast a whole array, since your element spacing will be different (16bit vs 32bit array elements).

Vaclav_Sal wrote:
I am still learning about FFT , but as far as I can tell the first FFT function
puts new data (normal pointer behavior) into the original (integer )
array as what ? Integer?

Output of most FFT routines is a float or double (depending on whether it's "single" or "double" precision math).

Vaclav_Sal wrote:
I think the only way is to collect the ADC data into double array
from get go.

Not going to happen. Analog to digital converters (and most hardware for that matter) deal with integers (you'll commonly hear the term fixed point math, that's why).

SOLVED Will casting / passing 16 bit int as double harm FFT processing? YES

Vaclav_29-Sep-14 17:13

Converting a string to a double

29-Sep-14 17:13

Thanks for reply.
Somehow I did not get the message across and the main question is getting muddled by stuff I am not so concerned about.
The bottom line - which I actually just wanted someone to confirm - is that casting pointers from integer to double is a stupid idea.
Thanks
Case closed

Richard Andrew x6426-Sep-14 20:53

Richard Andrew x64

26-Sep-14 20:53

I need to convert a CString to a double, but the function

swscanf_s

only operates on float's.
What should I use to convert to a double?

The difficult we do right away...
...the impossible takes slightly longer.

Re: Converting a string to a double

Richard MacCutchan26-Sep-14 21:35

http://msdn.microsoft.com/en-us/library/hc25t012.aspx[^].

26-Sep-14 21:35

Re: Converting a string to a double

Jochen Arndt26-Sep-14 21:41

Jochen Arndt

26-Sep-14 21:41

You can use the wide char versions of atof()[^] or strtod()[^]. If the string does not begin with the numeric value (spaces are ignored), you must parse the string and pass a pointer to the value's offset.

Signed integers considered harmful?

harold aptroot26-Sep-14 8:38

26-Sep-14 8:38

Signed integers seem to be a minefield of undefined behaviour lurking around every corner. You can't even add them without potentially blowing up the Death Star, unless you test for potential overflow first.

Should they be avoided? How should this be dealt with? How bad is it to pretend it's not a problem?

image processing toolkits | batch image processing

C^hris L^osinger26-Sep-14 8:46

C^hris L^osinger

26-Sep-14 8:46

know your data. check bounds.

PIEBALDconsult26-Sep-14 9:02

PIEBALDconsult

26-Sep-14 9:02

And here I've been wrestling with unsigned longs (in C#) for the last few days... Sigh | :sigh:

Consider:

ulong max = 1UL << 63 ; // 63 is the maximum of a calculated value

for ( ulong i = max - 1 ; i < max ; i-- )

How many people will freak out when they see the test in the for statement?

Richard Andrew x6426-Sep-14 9:02

Richard Andrew x64

26-Sep-14 9:02

harold aptroot wrote:
You can't even add them without potentially blowing up the Death Star, unless you test for potential overflow first.

I'm interested to learn more about this. Can you provide an example of what you mean?

The difficult we do right away...
...the impossible takes slightly longer.

harold aptroot26-Sep-14 10:15

26-Sep-14 10:15

Not of Death Stars exploding (sadly?).

But there's a well-known (and infamous) optimization that GCC does where if on some code path a signed integer would overflow, it deduces that therefore that code path must be dead. In practice this often means that overflow tests that are done after the overflow has already occurred (such as maybe you calculate something, then don't use the result if the calculation overflowed) are deleted, so your program looks correct (after all, you tested for overflows, right?) but isn't.

jeron126-Sep-14 9:17

jeron1

26-Sep-14 9:17

Same could be said about unsigned integers.

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment

"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst

image processing toolkits | batch image processing

C^hris L^osinger26-Sep-14 9:22

C^hris L^osinger

26-Sep-14 9:22

or floats, or doubles or any numeric encoding that has to reside on a computer with finite storage.

it's all about what you need the numbers to do for you.

jeron126-Sep-14 9:25

jeron1

26-Sep-14 9:25

Exactly.

Chris Losinger wrote:
it's all about what you need the numbers to do for you.

Yes it is.

Richard Andrew x6426-Sep-14 9:34

Richard Andrew x64

26-Sep-14 9:34

I was wondering why he singled out signed integers. But now that you point this out, I think I understand what he means.

The difficult we do right away...
...the impossible takes slightly longer.

PIEBALDconsult26-Sep-14 9:45

PIEBALDconsult

26-Sep-14 9:45

Signed integers lead to singed digits. Big Grin | :-D

harold aptroot26-Sep-14 10:05

26-Sep-14 10:05

No. Unsigned integers wrap, signed integers cause UB. Wrapping can be "not what you wanted", but it does something perfectly predictable and well-defined.

Richard MacCutchan26-Sep-14 10:14

26-Sep-14 10:14

harold aptroot wrote:
Signed integers seem to be a minefield of undefined behaviour

Since their behaviour is completely defined, I find it hard to understand what you mean.

harold aptroot26-Sep-14 10:19