|
Just off the top of anyone's head.
Are there any clever standard method or algorithm to detect a recurring series of numbers?
One of the programs that I work on uses an iterative function, with the resulting number being fed back in, to reach a set solution. Trouble is that sometimes it gets into an infinite loop whereby it 'toggles' between one, two, possibly three series of numbers.
So, are there any standard (and rel. easy!) mathematical methods to 'detect' numerical 'bounces'?
|
|
|
|
|
Are you asking if there is a mathematical way to fix your program's logic?
|
|
|
|
|
Not really a fix.
Just seeing if there are more efficient and standard methods to test recurrance. Otherwise brute (but clever brute) force is necessary.
|
|
|
|
|
I do not know about math, but if I understood you correctly you are looking for
std::count_if or std::count
|
|
|
|
|
Hi,
I would like to control the toolbar (highlights and presses) by using the keyboard. (Left/Right and Enter).
I can do all the UI of it, but i would like to simulate a button press ( and have it call thre relevant function ) right now all that I can do it make it look like the button is being pressed. Any Ideas?
Cheers
Asim.
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
There is a TB_PRESSBUTTON Message which should do the job.
Try this @ home. (B&B)
|
|
|
|
|
I'm using the MFC version of the function CToolBarCtrl::PressButton( int nID, BOOL bPress = TRUE );
It does give the UI of a button in a pressed state.
How do I actually call the function associated with a toolbar button (without clicking on it with the mouse button)?
Cheers
Asim
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Hi,
I'm using a normal windows progress bar with my program (common controls - CreateWindow(PROGRESS_CLASS...) etc). However, I would really like to jazz up the progress bar with a gradient fill - ie instead of being all one colour, it should blend from one colour to another. Does anybody know of a good way of doing this?
I'm not an expert programmer by a looong shot, and I'm only using the basic Windows API with no MFC. I've looked at articles here and over on codeguru, such as the gradient progress class by Matt Weagle, but they all seem to be for use with MFC and, because the explanation that comes with them is very brief, take a greater understanding of classes and programming than I have, unfortunately.
If anybody has any links or advice on how to go about this, I would be very grateful.
Many thanks,
KB
|
|
|
|
|
|
|
Thanks for the reply, I'm trying to get my head around the article you linked to. Unfortunately, though, it seems to be MFC based - I am using the very basic Windows API with no MFC, as I am an inexperienced programmer and I don't want to have to convert my whole app (a basic launcher and extractor) to MFC.
Thanks!
KB
|
|
|
|
|
This is mybe a stupid question  , but in the following piece of code
#define YOP 4*3+2
int i=YOP+3;
What will be compiled ? int i=4*3+2+3 ? or int i=17; ?
The question is, if I compile this, will 4*3+2 be done every time the part of code containing this is called, or is it done once by the (pre)compiler and coded as 17 ?
~RaGE();
|
|
|
|
|
Um... the macro will be expanded in place, but you'd hope the compiler will work out they are all constants and do the math for you. So maybe you'll get 17, but all you can hope for is 4*3+2+3.
Macros are evil anyhow. If it's a constant, use a const int instead.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
It'd probably be fairly easy to make a bot that'd post random stupid VB questions, and nobody would probably ever notice - benjymous - 21-Jan-2003
|
|
|
|
|
Christian Graus wrote:
Macros are evil anyhow.
No they are not. I love macros.
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Well, you're entitled to your opinion. I'm not even going to mention that Stroustrup spends two pages of his book warning people that macros are generally evidence of a bad design or a bad programmer, because I think that's a little over harsh. But I agree that they should be used very sparingly. You simply cannot read your code and see exactly what is going on, not to mention when you try to debug it.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
It'd probably be fairly easy to make a bot that'd post random stupid VB questions, and nobody would probably ever notice - benjymous - 21-Jan-2003
|
|
|
|
|
I guess it's because I'm more a C than C++ guy 
I do use C++, templates, classes and that stuff, but I never use STL.
I have used std::string a bit, but it's just too slow compared to char* :P
So.... What Stroustrup thinks about macros don't make me think much different about it...
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
Anders Molin wrote:
I guess it's because I'm more a C than C++ guy
Well, I guess bad habits die hard. If you're used to the pain of macros, then I guess there's no real reason to stop using them. 
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
It'd probably be fairly easy to make a bot that'd post random stupid VB questions, and nobody would probably ever notice - benjymous - 21-Jan-2003
|
|
|
|
|
So maybe you'll get 17, but all you can hope for is 4*3+2+3.
I think this is not true. These expressions are called constant expressions and it is guaranteed that the compiler will precalculate their value. Example follows:
const int size=4*3+2+3;
char buffer[size]; So, in this case we can hope for the best
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Joaquín M López Muñoz wrote:
So, in this case we can hope for the best
Is it really ? I did not know that the standard *guarenteed* this behaviour.
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
It'd probably be fairly easy to make a bot that'd post random stupid VB questions, and nobody would probably ever notice - benjymous - 21-Jan-2003
|
|
|
|
|
Well, if one gets really anal about it, the standard actually does not guarantee that the expression does not get executed at run time. One can always write en evil compiler that does the calculation at run-time just for fun and then throws the value away.
What my example shows is that any real compiler has to calculate the value of constant expressions.
PS: Even this is not entirely true if one imagines a pyschedelic compiler that does not reserve static memory for fixed sized arrays and prefers to do it at run-time. Or also, a conforming compiler can just translate to a high-level language and avoid calculating any constant expression at all.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
OK, so what I said is right - you might reasonably hope that the compiler will evaluate the constant, but there is no guarentee ?
Christian
No offense, but I don't really want to encourage the creation of another VB developer.
- Larry Antram 22 Oct 2002
C# will attract all comers, where VB is for IT Journalists and managers - Michael
P Butler 05-12-2002
It'd probably be fairly easy to make a bot that'd post random stupid VB questions, and nobody would probably ever notice - benjymous - 21-Jan-2003
|
|
|
|
|
You are utterly (en vogue word, ain't it) right, my dear.
In my defense I'd say that
int i=10000; reasonably gets calculated at compile-time, but there is no guarantee that the compiler does not generate the equivalent of
i=0;
for(int n=0;n<10000;++n){
Sleep(1000);
++i;
}just for fun.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
lol
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life!
|
|
|
|
|
I'm not 100% sure, but I think I remember reading that all harcoded expression, like yours, are resolved at compilation.
So YOP+3 would equate to (4*3)+2+3 = 17.
This result would then be used thoughout your code.
|
|
|
|
|
The preprocessor (which handles #define's) simply performs string substitution. It does not do any expression evaluation. The end result is that int i=4*3+2+3 is what is passed to the compiler. The compiler will evaluate the statement as i=17.
This is why it is so important to parenthesize macro arguments, along with the macro itself. Since the #define is just a string substitution, it can have problems based on operator precedence. For example, suppose you have:
#define macro(a,b) a / b If you use this macro like this:
int x = macro(4,2); the compiler actually parses and generates code for:
int x = 4 / 2; But, if you use it like this:
int y = macro(4,1 + 1); the compiler actually parses it as:
int y = 4 / 1 + 1; which has a different result from what you expect. Similarly, if you use the macro like this:
int z = macro(4,2) * 3; the compiler parse it as
int z = 4 / 2 * 3; Given operator precedence, the compiler will generate code for
int z = 6; Using the macro as follows:
int z = macro(4,1 + 1) * 3; causes the compiler to parse:
int z = 4 / 1 + 1 * 3; which generates code for
int z = 7;
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
