|
fasked wrote: Why add 0.5?
To turn floor() into a round()
|
|
|
|
|
using strings for numeric information when you don't need strings is never the right approach. For numerical problems, use a numeric solution.
Here are some possibilities:
1. you might put an upper limit on the deviation, similar to:
float is=0.999999877543;
float closeTo=1.0;
bool closeEnough=abs(is-closeTo)<0.01;
that would be close enough within 1% (since closeTo itself is one).
2. you might opt for a relative deviation (assuming the ideal value isn't zero):
float is=12.999999877543;
float closeTo=13.0;
bool closeEnough=abs((is-closeTo)/closeTo)<1.0e-6;
that would be close enough when within 1 ppm (pars pro million)
|
|
|
|
|
as i mentioned in previous post those value can be changed so and it may vary from negative to zero and zero to +2.707 E06 so not sure if that would work.
|
|
|
|
|
of course it can work. Whatever you can achieve with strings can be done without strings.
FYI: electronic circuit simulators use a combination of absolute and relative tolerance, so they would do a convergence test similar to the following:
float previous=...;
float current=...;
float threshold=0.1e-3;
if (abs(previous)>1) threshold+=abs(previous)*100.0e-6;
bool converged = abs(current-previous) < threshold;
in reality the two magic constants are variables, as the user is allowed to choose their value.
|
|
|
|
|
|
Nice link!
|
|
|
|
|
don't convert it to text just decide what the acceptable error is and compare ...
float error = 0.00000013;
float lowv = 0.1 - error;
float highv = 0.1 + error;
if ((lowv <= myfloat) && (highv >= myfloat)) {
} else {
}
|
|
|
|
|
I'm debugging IPP face detection demo console and in particular in the middle of the main where are:
...
int k, shda, shim, allpos;
int h = (pm + roi2.width - 1) / roi2.width;
int N = (roi2.height - classifierSize.height + 1 + h - classifierSize.height - 1) / (h - classifierSize.height + 1);
int X = (roi2.height - classifierSize.height + 1) / N;
int rem = (roi2.height - classifierSize.height + 1) % N;
...
Those are neither present at the locals window nor quickwatch or mouse hover can recognize them. What is the problem?
It can not also see customly defined types e.g. typedef unsigned char Ipp8u; a variable declared as Ipp8u* pData; is also invisible for IDE debugger.
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: Those are neither present ...
Strange, I can see them in all those places. Are you sure they are in the block that you have stopped at, and also that you are running the Debug version of your project?
It's time for a new signature.
|
|
|
|
|
I always use debug version.
I stepped line by line after those variables declared and they are not visible
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: I always use debug version.
I thought so, but still had to ask.
Chesnokov Yuriy wrote: I stepped line by line after those variables declared and they are not visible
As I said, I put those lines in a small test program and all were visible.
I can only assume something has gone wrong with one or more of the files containing the debug information. Try rebuilding the project and see if that changes anything.
It's time for a new signature.
|
|
|
|
|
Have you created your own project and used IPP face detection main code or used original solution?
I do not want to create solution from scratch and add all those files and code.
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: Have you created your own project and used IPP face detection main code or used original solution?
Neither, I just pasted your code into a simple program to make sure I could see the variables in the debugger.
Chesnokov Yuriy wrote: I do not want to create solution from scratch and add all those files and code.
I'm not sure what this has to do with your problem. I merely suggested running a complete rebuild of your project to ensure all the compiler and linker debug information was up to date.
It's time for a new signature.
|
|
|
|
|
For sure if I put the same variables to the clean program it will work.
I cleaned it and rebuilt without profit.
Only after I moved them to the point where main() function starts execution (as with C style declare them all first) debugger started to see them.
Once I move them back to their original place they are invisible again!
Чесноков
|
|
|
|
|
Chesnokov Yuriy wrote: Only after I moved them to the point where main() function starts execution (as with C style declare them all first) debugger started to see them.
Once I move them back to their original place they are invisible again!
This does not make sense, can you show the code for both instances, and where you stop in the debugger when they can or cannot be seen?
It's time for a new signature.
|
|
|
|
|
That will be hard to investigate, you need to install http://registrationcenter.intel.com/irc_nas/1749/w_ipp-samples_p_6.1.5.060.zip[^] along with IPP and Intel compiler.
The console application is face detection one. It is too big to fit and you will not be able to debug it without all those tools installed.
When you get to the variables from my question post and step over them you will not be able to see them.
Чесноков
|
|
|
|
|
Well, I guess the problem lies elsewhere within this sample code, so unless you can find someone else who has tried it out you are at an impasse. Sorry I cannot offer any other ideas.
It's time for a new signature.
|
|
|
|
|
Have you turned the optimiser off? Compilers are quite good at creating code that's equivalent to your source with a lot of the redundant stuff you've put in for readability removed.
Cheers,
Ash
|
|
|
|
|
That is debug build from IPP project. There is No Whole Program Optimization and in Linker->Optimization all fields are cleared.
Чесноков
|
|
|
|
|
As Aescleal hinted at...
You will get this sort of thing in Release. There's not those variables to display, as the code is heavily optimised. You want to check this sort of thing in Debug first.
Iain.
I am one of "those foreigners coming over here and stealing our jobs". Yay me!
|
|
|
|
|
It is debug build. I can not see permanently only those variables but all stepping over the lines is normal.
In release even stepping in debugger is wierd.
Чесноков
|
|
|
|
|
configuration of your solution is "Debug"?
|
|
|
|
|
|
These are the debug build command lines
/I"..\..\image-codecs\ijg\include" /I"samples" /I"C:\Program Files (x86)\Intel\Compiler\11.0\ipp\ia32\include" /Zi /nologo /W0 /WX- /Od /Oy- /D "_DEBUG" /D "WIN32" /D "_WIN32" /D "_WIN32_WINNT=0x500" /D "_WINDOWS" /D "STRICT" /D "_MBCS" /D "_CRT_SECURE_NO_DEPRECATE" /D "_CONSOLE" /Gm- /EHsc /RTC1 /MTd /Zp16 /GS /fp:precise /Zc:wchar_t /Zc:forScope /openmp- /Fp"_bin/Win32/Debug/Face_Detection_obj\Face_Detection.pch" /Fa"_bin/Win32/Debug/Face_Detection_obj\" /Fo"_bin/Win32/Debug/Face_Detection_obj\" /Fd"_bin/Win32/Debug/Face_Detection_obj\vc100.pdb" /Gd /analyze- /errorReport:queue
/OUT:"_bin/Win32/Debug\Face_Detection.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"..\..\image-codecs\ijg\_bin\Win32\Debug" /LIBPATH:"C:\Program Files (x86)\Intel\Compiler\11.0\ipp\ia32\stublib" "ippcc.lib" "ippi.lib" "ipps.lib" "ippcore.lib" "ippcv.lib" "ippj.lib" "ijg6b.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "uuid.lib" "comctl32.lib" "Ws2_32.lib" "winmm.lib" "wininet.lib" "vfw32.lib" "winspool.lib" "ole32.lib" "oleaut32.lib" "odbc32.lib" "odbccp32.lib" /MANIFEST /ManifestFile:"_bin/Win32/Debug/Face_Detection_obj\Face_Detection.exe.intermediate.manifest" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\DATA\Program Files\Intel\ipp-samples\image-processing\Face_Detection\_bin\Win32\Debug\Face_Detection.pdb" /SUBSYSTEM:CONSOLE /OPT:NOREF /PGD:"C:\DATA\Program Files\Intel\ipp-samples\image-processing\Face_Detection\_bin\Win32\Debug\Face_Detection.pgd" /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE
Чесноков
|
|
|
|
|
Having a real-time app which main processing function is invoked as much as 20-30fps performing some image processing is it better to preallocate all temporary buffers used or it does not cost to invoke allocations?
E.g. having to build pyramid of images with specific rescaling for 640x480 image might not consume much of the memory using preallocation scenario.
On the contrary for 15Mpx image the pyramid preallocation is very costly in consuming OS memory.
Is there a frequent memory allocation cost in real-time apps performance?
I remember I tested it long time before and each ::new operation took about dozen of millisecs or so while malloc() was 0 ms.
Чесноков
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
