[Issue 7455] Allow a cast to discard precision from a floating point during constant folding
http://d.puremagic.com/issues/show_bug.cgi?id=7455 --- Comment #9 from Martin Nowak c...@dawg.eu 2013-10-30 11:55:13 PDT --- (In reply to comment #8) Programs that rely on a maximum accuracy need to be rethought. It's more like programs that rely on a defined precision. When I write cast(float)a == cast(float)b then I want to compare two numbers that have been converted to floats. I understand your point that if 32-bit floats were no longer supported by a CPU we'd have troubles to implement this, but D defines a native float type with specified precision. Also C99 added a rule that casts and assignments are not allowed to use higher precision. http://stackoverflow.com/questions/503436/how-to-deal-with-excess-precision-in-floating-point-computations#answer-503523 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7455] Allow a cast to discard precision from a floating point during constant folding
http://d.puremagic.com/issues/show_bug.cgi?id=7455 --- Comment #7 from Stewart Gordon s...@iname.com 2012-02-14 05:09:53 PST --- (In reply to comment #6) Moreover, why allow cast(float) if it isn't supposed to work? To summarize it. The floating point rules are relaxed such that omitting cast(real)cast(float) is a valid transformation. But why? I can't see any use case for someone writing cast(float) unless they want it to convert the operand to a float. I suppose what I meant to say is: What good reason is there for the design whereby cast(float) does nothing? (OK, so it allows it to be called on a library function with a float parameter, but this affects only the specific case where the CastExpression is directly used as an argument.) I think that's generally a better idea than to waste all those cycles. There is currently no mechanism to distinguish explicit casts from implicit casts in the backend. That is in itself a problem to be addressed. It seems to be partly this that has led to issue 2006 as well. My guess is that there are other bugs that have this same root cause. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7455] Allow a cast to discard precision from a floating point during constant folding
http://d.puremagic.com/issues/show_bug.cgi?id=7455
Walter Bright bugzi...@digitalmars.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||bugzi...@digitalmars.com
Resolution||WONTFIX
--- Comment #4 from Walter Bright bugzi...@digitalmars.com 2012-02-13
01:56:55 PST ---
So I've no reliable way to round to a single precision float?
Store it to a float variable that is owned by something the compiler doesn't
know about (and so cannot optimize it).
One way would be to pass it to an extern function:
float foo(float);
and implement foo:
float foo(float f) { return f; }
in some separately compiled module.
I think such a method adequately addresses this, and no language enhancement is
required.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7455] Allow a cast to discard precision from a floating point during constant folding
http://d.puremagic.com/issues/show_bug.cgi?id=7455 --- Comment #5 from Stewart Gordon s...@iname.com 2012-02-13 04:32:27 PST --- Therein lies the point - it's a bit convoluted. And I'm sure somebody will come up with a use case for rounding a number to float precision at compile time. Moreover, why allow cast(float) if it isn't supposed to work? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7455] Allow a cast to discard precision from a floating point during constant folding
http://d.puremagic.com/issues/show_bug.cgi?id=7455 --- Comment #6 from d...@dawgfoto.de 2012-02-13 10:30:16 PST --- Moreover, why allow cast(float) if it isn't supposed to work? To summarize it. The floating point rules are relaxed such that omitting cast(real)cast(float) is a valid transformation. I think that's generally a better idea than to waste all those cycles. There is currently no mechanism to distinguish explicit casts from implicit casts in the backend. Walter's solution solves the problem so this should be fine. Any opinion on whether this would be a candidate for std.math? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7455] Allow a cast to discard precision from a floating point during constant folding
http://d.puremagic.com/issues/show_bug.cgi?id=7455 Stewart Gordon s...@iname.com changed: What|Removed |Added CC||s...@iname.com Summary|narrowing float cast|Allow a cast to discard |skipped for x87 values |precision from a floating ||point during constant ||folding Severity|normal |enhancement --- Comment #1 from Stewart Gordon s...@iname.com 2012-02-12 11:59:48 PST --- http://dlang.org/float.html Regardless of the type of the operands, floating point constant folding is done in real or greater precision. I agree that an explicit cast should override this behaviour, at least to the point of discarding the extra precision from its operand, but it's technically an enhancement request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7455] Allow a cast to discard precision from a floating point during constant folding
http://d.puremagic.com/issues/show_bug.cgi?id=7455 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don clugd...@yahoo.com.au 2012-02-12 18:31:52 PST --- (In reply to comment #1) http://dlang.org/float.html Regardless of the type of the operands, floating point constant folding is done in real or greater precision. I agree that an explicit cast should override this behaviour, at least to the point of discarding the extra precision from its operand, but it's technically an enhancement request. There's no constant folding involved, but: For floating point operations and expression intermediate values, a greater precision can be used than the type of the expression. Only the minimum precision is set by the types of the operands, not the maximum. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7455] Allow a cast to discard precision from a floating point during constant folding
http://d.puremagic.com/issues/show_bug.cgi?id=7455
--- Comment #3 from d...@dawgfoto.de 2012-02-12 18:50:14 PST ---
static import std.conv;
int main()
{
real a = 1.0L + float.epsilon;
if (std.conv.to!float(a + 1.0L) 2.0L)
return 1;
return 0;
}
--
If I try the library version it's result will differ with '-O -inline'.
Yeah I know, results may vary depending on compiler flags.
So I've no reliable way to round to a single precision float?
Does anybody have a good idea how to solve Bug 6531 then?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
