Carey Brown wrote:Comparing the length doesn't tell you anything. What if you have "12.3456" and "1.23456"?
You could use indexOf() to find the period and then substring to get only the characters to the right of the period.
There are three kinds of actuaries: those who can count, and those who can't.
As I said earlier in this thread, there isn't a simple answer. Except for an infinitesimal proportion of doubles where the decimal value can be expressed exactly, there is no answer at all because the fraction recurs infinitely. I hope no teacher would give beginners such an impossible task. If you scroll down through this FAQ, you will find whatprints. Even thoughseems better behaved.Phoebe Wise wrote:I'm making an assumption that this is an exercise for a beginner's coding class, so we are looking for a simple answer. . . .
Look in the old Sun style guide (§10.5.2) and you will find you should write return (x == y); unless you also want to break out of the control structure. Remember that the imprecision inherent in floating‑point arithmetic means the == test can fail when the arithmetic should have made the two numbers equal.if (parameter1 == parameter2)
return true;
I am afraid that may not work; if the numbers overflow such that -|x| < 0x8000_0000 (or -|x| < 0x8000_0000_0000_0000L), you will obtain ±∞ from your cast. This method and its brother) may avoid some of those problems, but will run out of range if |x| > 2⁵². Try something like this instead:-. . . multiply your parameters by 1000, then cast them into integers . . .
I think I have got the exponent wrong and it should readA few minutes ago, I wrote:. . . will run out of range if |x| > 2⁵². . . .
. . . will run out of range if |x| > 2⁵³. . . .
No, the cast rounds towards 0, so you get 5678.Brian Cole wrote:. . . (int)(x*1000) will turn 5.6789 to 5679, not 5678. . . .
Try it with −5.6789 instead.My JShell wrote:jshell> double x =5.6789; System.out.println( (int)(x*1000) );
x ==> 5.6789
5678
Campbell Ritchie wrote:No, the cast rounds towards 0, so you get 5678.
I still think the orignal intent was at best expressed badly.Chris Janicki wrote:I think Phoebe was right on target regarding the intent of the exercise . . .
Please explain more. I was taught that IEE754 stores a mantissa and an exponent, and there is no such thing as an integer part and a fractional part to the IEEE754 representation of a floating‑point number.. . . 1) A floating point number is stores the integer part separately from the fractional part . . .
Couldn't disagree more. The cast does something different from the floor() or ceil() calls, so you can't substitute one for another. Also a well‑tested method is usually better than working out your own solution with low‑level code. I don't know whether there is anything native about a cast. I would not try to code primarily for performance; that way lie errors!2) any function call is going to run slower in comparison, so it's always(?) best to avoid functions/methods when you have native alternatives. . . .
Often the most important part of the news is what they didn't tell.
Chris Janicki wrote:Ritchie, thanks for the critical eye! I edited my post to remove the controversial parts. Apparently I was wrong about the floating point representation... I had just looked it up on a generic (non-Java) site, and/or maybe I misunderstood something too. Casting to int may still be trivial for the JVM (masking/shifting some number of bits in the mantissa?), but I don't know that yet. And regarding the cast being "native" I should review/quote the Java Specification for clarity on that. My thought/assumption was that cast is(?) implemented by the JVM--not hardware or the operating system--and therefore you could rely on its consistent operation to "chop off" fractional parts, like Math.floor().
I still prefer to avoid functions calls whenever possible. My "mission-critical" (24x7x365) commercial app runs sometimes 10x faster than competitors that dive deep into frameworks and functions, and I don't think I've ever had a "gotcha" bug due to using low(er)-level code. And even it there was an occasional bug to squash, it would be worth it, to me. But that doesn't pertain to the original question, so I removed that part too, and we can quietly disagree on the pros/cons. ;-)
Often the most important part of the news is what they didn't tell.
Sorry for being critical, but thank you for taking it well.Chris Janicki wrote:Ritchie, thanks for the critical eye!
Plkease don't edit posts that have been replied to; it makes the reply very confusing. I have pulled rank, and reverted thed edit.I edited my post to remove the controversial parts. . . .
Harold Tee wrote:Methinks the string approach is simpler.
Mind you, you still have that age old problem with math operations which amplify the storage precision,
e.g isEqual ( (2.3 / 10.0) , 0.23) will not be equal.
Agree; it occurs pretty quickly and whether it is done by the JVM o rnatively is something we can ignore.Tim Holloway wrote:. . . Depending on the hardware, casting a float/double/long double to an integer type may be a single machine-language instruction. That's the JVM's problem . . .
I know you think I read the JLS as bedtime reading, but I don't. i can however remember that such large numbers are rounded to the largest (or most negative) values for the integer type. JLS link. I also got that bit wrong somewhere this weekcan potentially fail because 10E243 can't possibly fit in a 64-bit integer.
Agree. I hope there isn't some lecturer giving their students that sort of question.Tim Holloway wrote:The whole question is bogus. . . . .
Brian Cole wrote:Math.floor() is your friend.
[edit: Many edits. Replaced the original naive implementation with an ugly-ish one. Fought with the syntax highlighter.]
This does detect, to 3 places, that:
3.1756 is the same as 3.175 -3.1756 is the same as -3.175 0.0 is not the same as Double.NaN 2.3e304 is not the same as 2.4e304
Campbell Ritchie wrote:
Agree. I hope there isn't some lecturer giving their students that sort of question.Tim Holloway wrote:The whole question is bogus. . . . .
If your solution is correct, and i had a rather similar solution myself, then the question is valid but badly phrased. If somebody is really trying to extract places after the decimal point from a recurring number, then it is still a bogus question.Brian Cole wrote:. . .
Campbell Ritchie wrote:. . . I hope there isn't some lecturer giving their students that sort of question.
Not sure I completely agree, but the question should have been phrased with care.
Campbell Ritchie wrote:
Agree; it occurs pretty quickly and whether it is done by the JVM o rnatively is something we can ignore.Tim Holloway wrote:. . . Depending on the hardware, casting a float/double/long double to an integer type may be a single machine-language instruction. That's the JVM's problem . . .
I know you think I read the JLS as bedtime reading, but I don't. i can however remember that such large numbers are rounded to the largest (or most negative) values for the integer type. JLS link. I also got that bit wrong somewhere this weekcan potentially fail because 10E243 can't possibly fit in a 64-bit integer.
![]()
jls wrote:
Despite the fact that overflow, underflow, or other loss of information may occur, a narrowing primitive conversion never results in a run-time exception (ยง11.1.1).
Often the most important part of the news is what they didn't tell.
Brian Cole wrote:
This code is sort of doing it twice. Once you've assigned truncated values to a and b, you could simply compare them and be done with it. Or, if you're going to do the String.format("%.3f", a) conversion to String anyway, you needn't have truncated them to three digits first. Or am I missing something?
Really? You don't use compareTo() to test whether two Strings have the same content; you use equals().Harold Tee wrote:. . .
There are three kinds of actuaries: those who can count, and those who can't.
Phoebe Wise wrote:I'm making an assumption that this is an exercise for a beginner's coding class, so we are looking for a simple answer. There is no need to convert the numbers into strings.
I'd say your first question can be very straightforward:
if (parameter1 == parameter2)
return true;
Second question deals with numbers that differ after the third decimal place, so multiply your parameters by 1000, then cast them into integers to remove the excess decimal places.
Then compare them with the same method as the first question.
As a marketer, I find it immensely helpful. The detailed analysis of each agency's strengths and specialties is a valuable resource for making informed decisions by software for seo agencies. Great job capturing the essence of the SEO landscape!
Out on HF and heard nobody, but didn't call CQ? Nobody heard you either. 73 de N7GH
Creativity is allowing yourself to make mistakes; art is knowing which ones to keep. Keep this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|