Loop for 1/3+1/5+1/7...

Apologies for spelling laserlights name wrong - a typo - but since everyone seems to have understood what's the problem?

If you check my posts, you will see that I'm contributing - not asking for help. I've only posted one question - on fflush() with Windows 7 - and got no joy at all - with all this wealth of experience surely someone would know what Windows 7 is doing differently at low level?

It's interesting that imalc keeps referring to my team of 6 - ignoring the rest of the world - so when I suggest googling the rest of the world, it's back to the same old tune.

Did imalc actually try googling, or simply quoting one book. K & R originally designed a style of writing C that used the minimum no of lines - because their early work was on teletype machines. Doesn't mean that everyone followed, which is why C beautifiers were developed. The same applies to C++, evidenced by simply googling.

Try deciding who you are in this poem by Robert Graves

In Broken Images

He is quick, thinking in clear images;
I am slow, thinking in broken images.

He becomes dull, trusting to his clear images;
I become sharp, mistrusting my broken images,

Trusting his images, he assumes their relevance;
Mistrusting my images, I question their relevance.

Assuming their relevance, he assumes the fact,
Questioning their relevance, I question the fact.

When the fact fails him, he questions his senses;
When the fact fails me, I approve my senses.

He continues quick and dull in his clear images;
I continue slow and sharp in my broken images.

He in a new confusion of his understanding;
I in a new understanding of my confusion.

Originally Posted by johnggold

Apologies for spelling laserlights name wrong - a typo - but since everyone seems to have understood what's the problem?

The problem? The fact that I hinted it at you once very early in this thread and told you straight out a bit later and you still didn't get it right. That's the proof that you don't even read the messages that are being written except, perhaps, those that are short enough for you.
What point is there in discussing if you don't even read the points others make? And you don't seem to be doing it to just me either, as there are many points others made that you ignored completely.

I do read every one.

You didn't get the point then, or now on relevance to the question originally set by the original questioner.

What I have seen is quotes like "I am right", and "go read a book". That's being helpful?

You will note that I either provide code in my contributions or a link to code. This is after all a C++ programming forum.

If you check my posts, you will see that I'm contributing - not asking for help.

o_O

Okay. I'm curious. How many of your 52 posts actually contain helpful information? How many contain feedback from you regarding your own problem? How many are posts like those in this thread?

Never re-write code unless the user benefits

O_o

Just so as you know, I surely wouldn't work on any team with you.

Soma

Windows 7 is doing differently at low level?

Some do. Some of us have contacts as Microsoft that worked on the OS but since exposing that kind of information if it is not revealed or discussed in public documentation violates an NDA I doubt anyone is gonna start coughing up info about the kernel just yet.

To whom it may concern,

We used to take advantage of type promotion rather than both with an explicit cast, if we could state the function in such a way.

According to the text from Victor Shtern Core C++: A Software Engineering Approach 2000, typecasting is a little bit of an awkward topic...he put it back on page 1174, and he mentions that "...cast operators and conversion constructors weaken the strong typing system of C++." And that it can make it a little more troublesome during maintenance and integration.

So to take advantage of such a promotion, rather than intentionally circumventing strong typing, using the most recent piece of code:

Code:

val += (double) 1 / ( (double) ( 2*i - 1 ) );

Which should really read:

Code:

val += double(1) / ( double( 2*i - 1 ) );

Or even better:

Code:

val += static_cast<double>(1) / ( static_cast<double>( 2*i - 1 ) );

We would do something like:

Code:

val += 1.0 / (2.0*i - 1.0);

When the integer variable 'i' is multiplied by a double the result is a double. It was derived from the membership of the operators, a topic in set theory. N < I < R < C or natural are a subset of integers a subset of real numbers a subset of complex numbers. Of course, I've included rational and irrational numbers in the collection of reals -- it is sufficient for this example.

Shtern mentioned that these typecast operators, static_cast, reinterpret_cast, const_cast, dynamic_cast and the typeid operators are relatively new to C++, add to possible type conversions and are intentionally verbose (read-ability).

As far as the logic in the code segments given is concerned, I would draw a flow chart and do a correctness proof. But I'm not the beginner here. Have you examined the material here, and the material resulting from your internet search, Fyoung? What sort of tools are you using to evaluate these code segments? Just throwing it at the compiler is a great way to learn the compiler's warning messages and language syntax, but the semantics (meaning) of a collection of statements takes some finesse sometimes.

Best Regards,

New Ink -- Henry

Originally Posted by new_ink2001

So to take advantage of such a promotion, rather than intentionally circumventing strong typing, using the most recent piece of code:

Err... the most recent relevant piece of code in this thread is the one from my post #15, which has:

Code:

result += 1.0 / (2 * i + 1);

Absolutely Laserlight, it is a beautiful line of code that precisely and elegantly performs the desired operation -- using intrinsic properties of the datatypes. I had made it only through the first page of the thread, before the audience was in tears, and I happened to quote the code on that page. I didn't mean to neglect your contribution. The manner in which the threads are arranged is still something that I'm learning about.

I did read the complete discussion to this point (page 3). I'm still trying to stay sharp with what Shtern called "new" features in C++ (in 2000) -- so I thought it would be a nice corollary to the discussion. Besides, if I had been inaccurate (as does sometimes happen), I was rather confident someone would correct me.... I'm still impressed with the professionalism around here too.

Using series of rational numbers to approximate values is used a lot in applied mathematics. Has the OP received a satisfactory answer? Or did we run him/her off during the discussion about a posts' credibility?

Best Regards,

New Ink -- Henry

Originally Posted by johnggold

It's interesting that imalc keeps referring to my team of 6 - ignoring the rest of the world - so when I suggest googling the rest of the world, it's back to the same old tune.

Did imalc actually try googling, or simply quoting one book. K & R originally designed a style of writing C that used the minimum no of lines - because their early work was on teletype machines. Doesn't mean that everyone followed, which is why C beautifiers were developed. The same applies to C++, evidenced by simply googling.

We already know that most tutorials out there unfortunately use postincrement rather than preincrement. However one should acknowledge that the reason for this is largely historical. People will tend to teach others what they were taught, or what they think that person might already be familiar with. Frequency of use does not equal better.
I don't expect you to be convinced otherwise, but you do need to acknowledge that frequency of use is not in itself strong evidence of superiority. Anything from Microsoft is a good testament to that.

I had always expected the compiler optimization settings to account for that performance improvement.... Something else I'll be reading about soon.

{edited}
Opps, that was supposed to be on the thread where the pre/post increment was being discussed.... Thank you all.
{/edited}

Best Regards,

New Ink -- Henry