sqrt function in cmath library

[pauldepstein]

I am writing a program which will use the ceiling and floor of square
roots.

If a positive integer is an exact square (and is not overly huge), does
sqrt return an integer-valued real?

Or might the sqrt function tell me that, for example, sqrt(1024) =
31.99999999999999999999999

You might say "try it". The problem is that I can't try infinitely
many cases. I'm asking about square numbers in general.

I can easily write a program using an epsilon variable that will round
numbers to integers only if they are within epsilon of an integer.
However, this may be unnecessary -- it may already be built into the
sqrt function.

Paul Epstein

 

[Victor Bazarov]

I am writing a program which will use the ceiling and floor of square
roots.

If a positive integer is an exact square (and is not overly huge), does
sqrt return an integer-valued real?

Or might the sqrt function tell me that, for example, sqrt(1024) =
31.99999999999999999999999

You might say "try it". The problem is that I can't try infinitely
many cases. I'm asking about square numbers in general.

I can easily write a program using an epsilon variable that will round
numbers to integers only if they are within epsilon of an integer.
However, this may be unnecessary -- it may already be built into the
sqrt function.

You don't need to run infinitely many number variations. 'double' has
more digits than 'unsigned int' to store the mantissa, most likely. If
you take the square root of UINT_MAX+1, you get a value. You only need
to run sqrt(UINT_MAX + 1) tests, which is probably 65536:

int r = -1;
for (int i = 0; i < 65536; i++) {
double d = i; // exact
r = sqrt(d*d);
if (r != i) // bust!
break;
}

// examine 'r' here

V

 

[Kristo]

I am writing a program which will use the ceiling and floor of square
roots.

If a positive integer is an exact square (and is not overly huge), does
sqrt return an integer-valued real?

Or might the sqrt function tell me that, for example, sqrt(1024) =
31.99999999999999999999999

It just might do that. The problem, though, isn't with the sqrt
function but with the internal representation of decimal numbers. We
actually discussed this just yesterday - searching the archives might
help.

You might say "try it". The problem is that I can't try infinitely
many cases. I'm asking about square numbers in general.

You might try it, but you'd only find out how it works on your system.

I can easily write a program using an epsilon variable that will round
numbers to integers only if they are within epsilon of an integer.
However, this may be unnecessary -- it may already be built into the
sqrt function.

That's probably the most consistent and portable solution.

Kristo

 

[Kai-Uwe Bux]

I am writing a program which will use the ceiling and floor of square
roots.

If a positive integer is an exact square (and is not overly huge), does
sqrt return an integer-valued real?

Or might the sqrt function tell me that, for example, sqrt(1024) =
31.99999999999999999999999

You might say "try it". The problem is that I can't try infinitely
many cases. I'm asking about square numbers in general.

I can easily write a program using an epsilon variable that will round
numbers to integers only if they are within epsilon of an integer.
However, this may be unnecessary -- it may already be built into the
sqrt function.

Well, as far as I can tell the C++ standard just incorporates the semantics
of these functions from the C standard. I checked the draft version that I
have, and I did not find *any* guarantees as to precision. The wording of
the C standard for sqrt is:

The sqrt functions return the value of the square root.

This, clearly is a lie since in general the square root of a double is not
representable by a double. Thus, for all, I know

double sqrt ( double x ) {
return 0.0;
}

is a standard compliant implementation. It is a "quality of implementation"
thing. So, maybe you are better off asking the vendor of your library.



Best

Kai-Uwe Bux

 

[Marcus Kwok]

That's probably the most consistent and portable solution.

Another way that should be consistent and portable (though it does
introduce some additional overhead, and has ugly casts in it):


double d1 = /* something */;
double d2 = std::sqrt(d1);

int lower = static_cast<int>(std::floor(d2));
int upper = static_cast<int>(std::ceil(d2));

if (lower == upper) {
// sqrt was exact
}

 

[pauldepstein]

Thank you for this code (and thanks to others who tried to help me.)

I could easily have written this program myself. The reason I didn't
test it in this way, is that I had no idea that 65536 trials were
sufficient. Thanks for the interesting suggestion of where such bounds
lie.

As an aside, it might be worth pointing out that my compiler gives a
warning to the above code when sqrt is applied to an integer type. It
runs perfectly but gives a warning.

I'm still not sure I have a 100% grasp of what is on-topic and what
isn't. I just mentioned the word "compiler" which seems to be a severe
criminal offence in this newsgroup.

I am very inexperienced in this area. From my standpoint, the whole
philosophy of "Let's narrow it down to the language. Let's never ever
mention other programming issues such as compilers and platforms." is a
philosophy that makes absolutely no sense whatsoever to me. I assume
that it makes no sense _to me_ because I'm so inexperienced, and that a
veteran of newsgroups and computing would find such a narrow definition
very sensible.

Paul Epstein

 

[deane_gavin]

<top posting rearranged - if you put your reply after the message to
which you are replying everyone can follow the discussion more easily>

I'm still not sure I have a 100% grasp of what is on-topic and what
isn't. I just mentioned the word "compiler" which seems to be a severe
criminal offence in this newsgroup.

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9

The rest of the FAQ is well worth reading too.

I am very inexperienced in this area. From my standpoint, the whole
philosophy of "Let's narrow it down to the language. Let's never ever
mention other programming issues such as compilers and platforms." is a
philosophy that makes absolutely no sense whatsoever to me. I assume
that it makes no sense _to me_ because I'm so inexperienced, and that a
veteran of newsgroups and computing would find such a narrow definition
very sensible.

It's very sensible *in the context of this newsgroup*. When you ask a
question, you want as many people to read it as possible. That way, you
are more likely to get the right answer, and, very importantly, if
someone gives you the wrong answer, you are more likely to see someone
else correct it.

Now, imagine you are a C++ language expert who is prepared to give some
time to helping other people with C++ language questions. If you have
to sift through compiler and platform specific questions all the time
to find the occasional language question, you are likely to soon get
bored and give up reading and contributing.

In no way does any of that suggest that it is unacceptable to have
questions about your compiler or platform. Of course you will have
questions. But, in the same way that restricted topicality raises the
quality of C++ language help available here, restricted topicality in a
compiler-specific newsgroup (see the FAQ link I posted) has the same
effect there.

You will get high quality, peer-reviewed answers from the right experts
by posting to the right group. Don't be surprised to sometimes see the
same people helping you in more than one newsgroup either.

Gavin Deane

 

[pauldepstein]

Thanks a lot.

I don't understand static_cast<int> -- I could probably google this
though, if you don't have the time to give extra details.

By the way, I _do_ understand the basic class notation, std::floor etc.
(using the standard namespace from the maths library -- floor is a
function from that class etc.)

[To receive help, I find it's sometimes a good practice to say what I
do understand (hopefully), as well as what I don't understand.]


Paul Epstein

 

[Marcus Kwok]

I don't understand static_cast<int> -- I could probably google this
though, if you don't have the time to give extra details.

std::floor() and std::ceil() both return doubles. the static_cast<int>
tells it to convert the value from a double to an int, so you can store
it in an int variable exactly (assuming the value won't overflow).

[To receive help, I find it's sometimes a good practice to say what I
do understand (hopefully), as well as what I don't understand.]

Yes, also, you should not top-post.

 

[pauldepstein]

<top posting rearranged - if you put your reply after the message to
which you are replying everyone can follow the discussion more easily>




http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9

The rest of the FAQ is well worth reading too.


It's very sensible *in the context of this newsgroup*. When you ask a
question, you want as many people to read it as possible. That way, you
are more likely to get the right answer, and, very importantly, if
someone gives you the wrong answer, you are more likely to see someone
else correct it.

Now, imagine you are a C++ language expert who is prepared to give some
time to helping other people with C++ language questions. If you have
to sift through compiler and platform specific questions all the time
to find the occasional language question, you are likely to soon get
bored and give up reading and contributing.

In no way does any of that suggest that it is unacceptable to have
questions about your compiler or platform. Of course you will have
questions. But, in the same way that restricted topicality raises the
quality of C++ language help available here, restricted topicality in a
compiler-specific newsgroup (see the FAQ link I posted) has the same
effect there.

You will get high quality, peer-reviewed answers from the right experts
by posting to the right group. Don't be surprised to sometimes see the
same people helping you in more than one newsgroup either.

Gavin Deane

Gavin,

I like this reply, which is encouraging, respectful and helpful.

However, I nevertheless remain completely unconvinced of your argument
that it is healthy for this newsgroup to avoid discussion of compilers
and platforms

Surely, decisions about c++ code are influenced by judgments about how
the code will be treated on various platforms or compilers. (Accepting
that portability is a vital issue, I assume programmers consider all
commonly used platforms and compilers.)

However, how can there be discussion of these coding/language issues if
people are fined $5000 by the newsgroup police whenever they say
something like " I wrote .... and my dev c++ compiler said ... What
does ... compiler message mean?" ? The draconian enforcement of these
heavy financial penalties is preventing valuable discussion on pure
language issues concerning c++ programming. The c++ coding works
together with the platforms and the compilers in a symbiotic fashion.

I know a famous writer, Marcus Dontbe Gullible, who submitted what he
thought was a great idea to his publisher. He wanted to write a book
about high-school teaching which scrupulously avoided any mention of
high-school students. Unsurprisingly, the publisher laughed at
Marcus's idea, and thought it ridiculous. The raison d'etre of this
newsgroup -- discussing c++ without discussing compilers or platforms
-- seems analogous to Marcus's unworkable concept.

I also find it absurdly ironic that, in marked contrast to the attitude
towards compiler/platform discussions, the following posting, which was
_wildly irrelevant_, induced a long and sober thread of replies, and
did not seem to be condemned as OT by anybody.

Yesterday's irrelevant (but apparently not judged OT) thread began as
follows:

" I would like to share my distress at the way I have been treated in
my new entry-level job as a java programmer. (I have 3 months
programming experience). My salary is less than 2 million dollars a
year, and my boss has never offered to provide me with a chauffeur to
drive me into work, even though I live in a neighboring town.
Furthermore, last week he treated me to dinner at a Chinese restaurant,
and I was shocked and appalled to notice a small stain on one of the
tablecloths.

Are such experiences typical of everyone, or am I just unlucky?"

Nevertheless, despite all I've said, I enjoy this newsgroup so far and
my questions have been very well answered -- it has been a happy
discovery.

Paul Epstein

 

[Victor Bazarov]

[...]
However, I nevertheless remain completely unconvinced of your argument
that it is healthy for this newsgroup to avoid discussion of compilers
and platforms
[...]

While discussing cutting instruments in a cutting instruments newsgroup,
one should be careful not to veer away and begin asking how to cut hair
with those instruments or how to plow garden soil. It is undoubtedly
topical to discuss suitability of some materials for making cutting
instruments, but techniques of holding those instruments while operating
on a tumor or chopping salad belong to surgical and cooking newsgroups,
respectively.