|
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
|
|
|
|
|
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.
|
|
|
|
|
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).
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
|
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 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?
|
|
|
|
|
know your data. check bounds.
|
|
|
|
|
And here I've been wrestling with unsigned longs (in C#) for the last few days... 
Consider:
ulong max = 1UL << 63 ;
for ( ulong i = max - 1 ; i < max ; i-- )
How many people will freak out when they see the test in the for statement?
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
Exactly.
Chris Losinger wrote: it's all about what you need the numbers to do for you.
Yes it is.
"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
|
|
|
|
|
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.
|
|
|
|
|
Signed integers lead to singed digits. 
|
|
|
|
|
No. Unsigned integers wrap, signed integers cause UB. Wrapping can be "not what you wanted", but it does something perfectly predictable and well-defined.
|
|
|
|
|
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.
|
|
|
|
|
It isn't. See for example 3.4.3 of C99[^],
An example of undefined behavior is the behavior on integer overflow This does not apply to unsigned integers, which can't overflow because they wrap.
Taking some other standard doesn't help either, as far as I know that's undefined in all version of C and C++ (but I'd really like to be wrong about that).
|
|
|
|
|
Lots and lots of things in C++ (and C for that matter) can lead to undefined behavior if preconditions are not met. Signed integer arithmetic is just one of many. If you're programming in this language, you should be used to dealing with narrow contracts.
So, no, they shouldn't be avoided. Deal with them depending on the situation, in many cases an assert will suffice. Pretending it's not a problem is fatal.
(and no, gcc isn't the only compiler that assumes that naive signed overflow checks are always false)
|
|
|
|
|
Hi,
i am trying to point my vector iterator to some vector index like this:
std::vector::iterator* it= myVec[i];
But it fails:
no known conversion for argument 1 from ‘Data’ to ‘std::vector::iterator
Please help 
|
|
|
|
|
std::vector<int>::iterator it = myVec.begin() + i;
«_Superman_»
I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) (October 2009 - September 2013) Polymorphism in C
|
|
|
|
|
Thank you, but can you explain why my version does not work?
Are the types not compatible? I can access vector elements by dereferencing iterators, does it not work the other way around?
|
|
|
|
|
It doesn't work because it is wrong.
Quote: std::vector::iterator* it= myVec[i];
You are trying to assign a value (not an address) to an iterator.
Please note, even
std::vector<int>::iterator* it= &myVec[i];
Would NOT WORK, because iterators are not exactly pointers.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
