Re: sqrt(2) must go

Okay so we're thinking of allowing implicit casting now ONLY if it can be guaranteed that the cast is lossless? I don't see how this addresses the original question though, which was how to resolve an ambiguous function selection? It selects the smallest one it will fit into? Does that mean it wil

Re: sqrt(2) must go

On 21.10.2011 09:53, Manu wrote: On 21 October 2011 09:00, Don mailto:nos...@nospam.com>> wrote: On 21.10.2011 05:24, Robert Jacques wrote: On Thu, 20 Oct 2011 09:11:27 -0400, Don mailto:nos...@nospam.com>> wrote: [snip] I'd like to get to the situation where th

Re: sqrt(2) must go

On Sat, 22 Oct 2011 05:42:10 -0400, Manu wrote: Sure, and hijacking is bound to happen under your proposal, no? How would it be detected? On 22 October 2011 06:51, Robert Jacques wrote: On Fri, 21 Oct 2011 19:04:43 -0400, Manu wrote: It would still allow function hijacking. void func(doub

Re: sqrt(2) must go

Sure, and hijacking is bound to happen under your proposal, no? How would it be detected? On 22 October 2011 06:51, Robert Jacques wrote: > On Fri, 21 Oct 2011 19:04:43 -0400, Manu wrote: > >> It would still allow function hijacking. >> void func(double v); exists... >> func(2); >> then someone

Re: sqrt(2) must go

On Fri, 21 Oct 2011 19:04:43 -0400, Manu wrote: It would still allow function hijacking. void func(double v); exists... func(2); then someone comes along and adds func(float v); .. It will now hijack the call. That's what you mean right? Hijacking is what happends when someone adds func(float

Re: sqrt(2) must go

It would still allow function hijacking. void func(double v); exists... func(2); then someone comes along and adds func(float v); .. It will now hijack the call. That's what you mean right? On Oct 22, 2011 1:45 AM, "Robert Jacques" wrote: > > On Fri, 21 Oct 2011 09:00:48 -0400, Manu wrote: >> >>

Re: sqrt(2) must go

On Fri, 21 Oct 2011 09:00:48 -0400, Manu wrote: On 21 October 2011 10:53, Manu wrote: On 21 October 2011 09:00, Don wrote: [snip] 1: Seems reasonable for literals; "Integer literals and expressions should use range propagation to use the thinnest loss-less conversion"... but can you clarify

Re: sqrt(2) must go

On 21 October 2011 10:53, Manu wrote: > On 21 October 2011 09:00, Don wrote: > >> On 21.10.2011 05:24, Robert Jacques wrote: >> >>> On Thu, 20 Oct 2011 09:11:27 -0400, Don wrote: >>> [snip] >>> I'd like to get to the situation where those overloads can be added without breaking people

Re: sqrt(2) must go

On 21 October 2011 09:00, Don wrote: > On 21.10.2011 05:24, Robert Jacques wrote: > >> On Thu, 20 Oct 2011 09:11:27 -0400, Don wrote: >> [snip] >> >>> I'd like to get to the situation where those overloads can be added >>> without breaking peoples code. The draconian possibility is to disallow >

Re: sqrt(2) must go

On 20-10-2011 14:13, Don wrote: On 20.10.2011 13:12, Manu wrote: On 20 October 2011 11:02, Don mailto:nos...@nospam.com>> wrote: On 20.10.2011 09:47, Manu wrote: Many architectures do not support real, and therefore it should never be used implicitly by the language. Precision problems aside,

Re: sqrt(2) must go

On 21.10.2011 05:24, Robert Jacques wrote: On Thu, 20 Oct 2011 09:11:27 -0400, Don wrote: [snip] I'd like to get to the situation where those overloads can be added without breaking peoples code. The draconian possibility is to disallow them in all cases: integer types never match floating poin

Re: sqrt(2) must go

On Thu, 20 Oct 2011 09:11:27 -0400, Don wrote: [snip] I'd like to get to the situation where those overloads can be added without breaking peoples code. The draconian possibility is to disallow them in all cases: integer types never match floating point function parameters. The second possibilit

Re: sqrt(2) must go

Am 20.10.2011, 22:09 Uhr, schrieb Manu : I think you just brushed over my entire concern with respect to libraries, and very likely the standard library its self. I've also made what I consider to be reasonable counter arguments to those points in earlier posts, so I won't repeat myself. I

Re: sqrt(2) must go

Am 20.10.2011, 22:37 Uhr, schrieb Marco Leise : Am 20.10.2011, 08:02 Uhr, schrieb Russel Winder : On Wed, 2011-10-19 at 23:36 -0400, dsimcha wrote: On 10/19/2011 11:27 PM, Marco Leise wrote: > And real can be used without protability problems on PowerPC or ARM? Yes, it's just that they may o

Re: sqrt(2) must go

Am 20.10.2011, 08:02 Uhr, schrieb Russel Winder : On Wed, 2011-10-19 at 23:36 -0400, dsimcha wrote: On 10/19/2011 11:27 PM, Marco Leise wrote: > And real can be used without protability problems on PowerPC or ARM? Yes, it's just that they may only give 64 bits of precision. Floating point is

Re: sqrt(2) must go

I think you just brushed over my entire concern with respect to libraries, and very likely the standard library its self. I've also made what I consider to be reasonable counter arguments to those points in earlier posts, so I won't repeat myself. I think it's fairly safe to say though, with respe

Re: sqrt(2) must go

On Thursday, October 20, 2011 21:44:05 Don wrote: > On 20.10.2011 19:28, Jonathan M Davis wrote: > > On Thursday, October 20, 2011 05:13 Don wrote: > >> Personally, I'd rather completely eliminate implicit conversions > >> between > >> integers and floating point types. But that's just me. > > > >

Re: sqrt(2) must go

On 20.10.2011 19:28, Jonathan M Davis wrote: On Thursday, October 20, 2011 05:13 Don wrote: Personally, I'd rather completely eliminate implicit conversions between integers and floating point types. But that's just me. If it's a narrowing conversion, it should require a cast. If it's not, and

Re: sqrt(2) must go

On Thursday, October 20, 2011 21:52:32 Manu wrote: > On 20 October 2011 17:28, Simen Kjaeraas wrote: > > On Thu, 20 Oct 2011 15:54:48 +0200, Manu wrote: > > I could only support 2 if it chooses 'float', the highest performance > > > >> version on all architectures AND actually available on all

Re: sqrt(2) must go

On Thu, 20 Oct 2011 15:52:35 +0200, Steven Schveighoffer wrote: On Thu, 20 Oct 2011 09:11:27 -0400, Don wrote: Actually there is a problem there, I think. If someone later on adds NotOverload(double x), that call will suddenly stop compiling. That isn't just a theoretical problem. Curre

Re: sqrt(2) must go

On 20 October 2011 17:28, Simen Kjaeraas wrote: > On Thu, 20 Oct 2011 15:54:48 +0200, Manu wrote: > > I could only support 2 if it chooses 'float', the highest performance >> version on all architectures AND actually available on all architectures; >> given this is meant to be a systems program

Re: sqrt(2) must go

On 10/20/2011 1:37 PM, dsimcha wrote: == Quote from Eric Poggel (JoeCoder) (dnewsgro...@yage3d.net)'s article On 10/20/2011 8:13 AM, Don wrote: Personally, I'd rather completely eliminate implicit conversions between integers and floating point types. But that's just me. vote++ I would fork

Re: sqrt(2) must go

== Quote from Eric Poggel (JoeCoder) (dnewsgro...@yage3d.net)'s article > On 10/20/2011 8:13 AM, Don wrote: > > Personally, I'd rather completely eliminate implicit conversions between > > integers and floating point types. But that's just me. > vote++ I would fork the language over this because i

Re: sqrt(2) must go

On Thursday, October 20, 2011 05:13 Don wrote: > Personally, I'd rather completely eliminate implicit conversions between > integers and floating point types. But that's just me. If it's a narrowing conversion, it should require a cast. If it's not, and there's no ambguity in the conversion, then

Re: sqrt(2) must go

On 10/20/2011 8:13 AM, Don wrote: Personally, I'd rather completely eliminate implicit conversions between integers and floating point types. But that's just me. vote++

Re: sqrt(2) must go

On Thu, 20 Oct 2011 15:54:48 +0200, Manu wrote: I could only support 2 if it chooses 'float', the highest performance version on all architectures AND actually available on all architectures; given this is meant to be a systems programming language, and supporting as many architectures as po

Re: sqrt(2) must go

On 20 October 2011 16:11, Don wrote: > On 20.10.2011 14:48, Manu wrote: > >> On 20 October 2011 15:13, Don > >> > wrote: >> >>On 20.10.2011 13:12, Manu wrote: >> >>On 20 October 2011 11:02, Don > >>

Re: sqrt(2) must go

On Thu, 20 Oct 2011 09:11:27 -0400, Don wrote: Actually there is a problem there, I think. If someone later on adds NotOverload(double x), that call will suddenly stop compiling. That isn't just a theoretical problem. Currently log(2) will compile, but only because in std.math there is log

Re: sqrt(2) must go

On 20.10.2011 14:48, Manu wrote: On 20 October 2011 15:13, Don mailto:nos...@nospam.com>> wrote: On 20.10.2011 13:12, Manu wrote: On 20 October 2011 11:02, Don mailto:nos...@nospam.com> >> wrote: On 20.10.2011

Re: sqrt(2) must go

I vote for "Error: Ambiguous call to overloaded function". NOT implicit conversion to arbitrary type 'double' :) On 20 October 2011 15:49, dsimcha wrote: > On 10/20/2011 8:13 AM, Don wrote: > >> There's no problem with assignment, it's never ambiguous. >> >> There seems to be some confusion abo

Re: sqrt(2) must go

On 10/20/2011 8:13 AM, Don wrote: There's no problem with assignment, it's never ambiguous. There seems to be some confusion about what the issue is. To reiterate: void foo(float x) {} void foo(double x) {} void bar(float x) {} void baz(double x) {} void main() { bar(2); // OK -- 2 becomes 2

Re: sqrt(2) must go

On 20 October 2011 15:13, Don wrote: > On 20.10.2011 13:12, Manu wrote: > >> On 20 October 2011 11:02, Don > > wrote: >> >>On 20.10.2011 09:47, Manu wrote: >> >>Many architectures do not support real, and therefore it should >>never be >>used

Re: sqrt(2) must go

On 20.10.2011 13:12, Manu wrote: On 20 October 2011 11:02, Don mailto:nos...@nospam.com>> wrote: On 20.10.2011 09:47, Manu wrote: Many architectures do not support real, and therefore it should never be used implicitly by the language. Precision problems asi

Re: sqrt(2) must go

On 20 October 2011 10:55, Don wrote: > On 20.10.2011 05:01, Steven Schveighoffer wrote: > >> On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques >> wrote: >> >> On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise >>> wrote: >>> Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/20

Re: sqrt(2) must go

On 20 October 2011 11:02, Don wrote: > On 20.10.2011 09:47, Manu wrote: > >> Many architectures do not support real, and therefore it should never be >> used implicitly by the language. >> >> Precision problems aside, I would personally insist that implicit >> conversation from any sized int alwa

Re: sqrt(2) must go

On Thu, 20 Oct 2011 09:55:51 +0200, Don wrote: On 20.10.2011 05:01, Steven Schveighoffer wrote: On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques wrote: On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise wrote: Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/2011 6:25 PM, Alvaro wrot

Re: sqrt(2) must go

On Thu, 20 Oct 2011 03:55:51 -0400, Don wrote: On 20.10.2011 05:01, Steven Schveighoffer wrote: On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques wrote: On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise wrote: Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/2011 6:25 PM, Alvaro wrot

Re: sqrt(2) must go

On 10/20/2011 05:34 AM, dsimcha wrote: On 10/19/2011 10:57 PM, Robert Jacques wrote: Also, 5_000_000_000 does not fit, exactly inside a double. Yes it does. Doubles can hold integers exactly up to 2 ^^ 53. http://en.wikipedia.org/wiki/Double_precision_floating-point_format 5_000_000_000 eve

Re: sqrt(2) must go

On 20.10.2011 09:47, Manu wrote: Many architectures do not support real, and therefore it should never be used implicitly by the language. Precision problems aside, I would personally insist that implicit conversation from any sized int always be to float, not double, for performance reasons (th

Re: sqrt(2) must go

On 20.10.2011 05:01, Steven Schveighoffer wrote: On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques wrote: On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise wrote: Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/2011 6:25 PM, Alvaro wrote: El 19/10/2011 20:12, dsimcha escribió: == Quo

Re: sqrt(2) must go

Many architectures do not support real, and therefore it should never be used implicitly by the language. Precision problems aside, I would personally insist that implicit conversation from any sized int always be to float, not double, for performance reasons (the whole point of a compiled languag

Re: sqrt(2) must go

On Wed, 2011-10-19 at 23:36 -0400, dsimcha wrote: > On 10/19/2011 11:27 PM, Marco Leise wrote: > > And real can be used without protability problems on PowerPC or ARM? > > Yes, it's just that they may only give 64 bits of precision. Floating > point is inexact anyhow, though. IMHO the fact that

Re: sqrt(2) must go

On 20.10.2011 05:25, bearophile wrote: Robert Jacques: Simple, is a 5_000_000_000 long, and longs convert to reals. Also, 5_000_000_000 does not fit, exactly inside a double. There is nothing "simple" here... Bye, bearophile Yeah, but the problem isn't with ints, it's with integer literal

Re: sqrt(2) must go

On 19.10.2011 20:12, dsimcha wrote: == Quote from Don (nos...@nospam.com)'s article In D2 prior to 2.048, sqrt(2) does not compile. The reason is that it's ambiguous whether it is sqrt(2.0), sqrt(2.0L), or sqrt(2.0f). This also applies to _any_ function which has overloads for more than one floa

Re: sqrt(2) must go

On Wed, 19 Oct 2011 23:01:34 -0400, Steven Schveighoffer wrote: On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques wrote: On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise wrote: Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/2011 6:25 PM, Alvaro wrote: El 19/10/2011 20:12, dsimcha

Re: sqrt(2) must go

On 10/19/2011 11:27 PM, Marco Leise wrote: And real can be used without protability problems on PowerPC or ARM? Yes, it's just that they may only give 64 bits of precision. Floating point is inexact anyhow, though. IMHO the fact that you may lose a little precision with very large longs is

Re: sqrt(2) must go

On 10/19/2011 10:57 PM, Robert Jacques wrote: Also, 5_000_000_000 does not fit, exactly inside a double. Yes it does. Doubles can hold integers exactly up to 2 ^^ 53. http://en.wikipedia.org/wiki/Double_precision_floating-point_format

Re: sqrt(2) must go

Am 20.10.2011, 05:01 Uhr, schrieb Steven Schveighoffer : On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques wrote: On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise wrote: Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/2011 6:25 PM, Alvaro wrote: El 19/10/2011 20:12, dsimcha esc

Re: sqrt(2) must go

Robert Jacques: > Simple, is a 5_000_000_000 long, and longs convert to reals. Also, > 5_000_000_000 does not fit, exactly inside a double. There is nothing "simple" here... Bye, bearophile

Re: sqrt(2) must go

On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques wrote: On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise wrote: Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/2011 6:25 PM, Alvaro wrote: El 19/10/2011 20:12, dsimcha escribió: == Quote from Don (nos...@nospam.com)'s article The hac

Re: sqrt(2) must go

On Wed, 19 Oct 2011 22:57:48 -0400, Robert Jacques wrote: On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise wrote: Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/2011 6:25 PM, Alvaro wrote: El 19/10/2011 20:12, dsimcha escribió: == Quote from Don (nos...@nospam.com)'s article The

Re: sqrt(2) must go

On Wed, 19 Oct 2011 22:52:14 -0400, Marco Leise wrote: Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/2011 6:25 PM, Alvaro wrote: El 19/10/2011 20:12, dsimcha escribió: == Quote from Don (nos...@nospam.com)'s article The hack must go. No. Something as simple as sqrt(2) must work at

Re: sqrt(2) must go

Am 20.10.2011, 02:46 Uhr, schrieb dsimcha : On 10/19/2011 6:25 PM, Alvaro wrote: El 19/10/2011 20:12, dsimcha escribió: == Quote from Don (nos...@nospam.com)'s article The hack must go. No. Something as simple as sqrt(2) must work at all costs, period. A language that adds a bunch of silly

Re: sqrt(2) must go

On 10/19/2011 6:25 PM, Alvaro wrote: El 19/10/2011 20:12, dsimcha escribió: == Quote from Don (nos...@nospam.com)'s article The hack must go. No. Something as simple as sqrt(2) must work at all costs, period. A language that adds a bunch of silly complications to something this simple is fund

Re: sqrt(2) must go

Alvaro: > I call that uncluttered programming. No excessive explicitness should be > necessary when what you mean is obvious (under some simple conventions). > Leads to clearer code. Explicitness usually means adding more annotations in the code, and this usually increases the visual noise in

Re: sqrt(2) must go

El 19/10/2011 20:12, dsimcha escribió: == Quote from Don (nos...@nospam.com)'s article The hack must go. No. Something as simple as sqrt(2) must work at all costs, period. A language that adds a bunch of silly complications to something this simple is fundamentally broken. I don't remember

Re: sqrt(2) must go

On Wed, 2011-10-19 at 19:12 +, dsimcha wrote: [ . . . ] > LOL and Pascal was my example of a bondage-and-discipline language. All the > more > reason why we need to allow it in D come Hell or high water. Bondage. Discipline. Does this mean Lady Heather will take control? -- Russel.

Re: sqrt(2) must go

== Quote from Marco Leise (marco.le...@gmx.de)'s article > Am 19.10.2011, 20:12 Uhr, schrieb dsimcha : > > No. Something as simple as sqrt(2) must work at all costs, period. A > > language > > that adds a bunch of silly complications to something this simple is > > fundamentally > > broken. I do

Re: sqrt(2) must go

Am 19.10.2011, 20:12 Uhr, schrieb dsimcha : No. Something as simple as sqrt(2) must work at all costs, period. A language that adds a bunch of silly complications to something this simple is fundamentally broken. I don't remember your post on implicit preferred conversions, but IMHO impl

Re: sqrt(2) must go

http://www.digitalmars.com/d/archives/digitalmars/D/PROPOSAL_Implicit_conversions_of_integer_literals_to_floating_point_125539.html#N125539

Re: sqrt(2) must go

== Quote from Don (nos...@nospam.com)'s article > In D2 prior to 2.048, sqrt(2) does not compile. The reason is that it's > ambiguous whether it is sqrt(2.0), sqrt(2.0L), or sqrt(2.0f). This also > applies to _any_ function which has overloads for more than one floating > point type. > In D2 betwee

Re: sqrt(2) must go

Don: > However, when I proposed the fix on the newsgroup (integer literals > should have a preferred conversion to double), it was *unanimously* > rejected. I don't remember the rationale of those refusals. Do you have a link to the discussion? Bye, bearophile

Re: sqrt(2) must go

Am 19.10.2011, 18:25 Uhr, schrieb Alex Rønne Petersen : On 19-10-2011 18:22, Alex Rønne Petersen wrote: On 19-10-2011 18:18, Don wrote: In D2 prior to 2.048, sqrt(2) does not compile. The reason is that it's ambiguous whether it is sqrt(2.0), sqrt(2.0L), or sqrt(2.0f). This also applies to _

Re: sqrt(2) must go

http://codepad.org/4g0hXOse Too much?

Re: sqrt(2) must go

That call "return sqrt(f);" should have been "return sqrt!F(f)" that forwards to sqrt functions that take floats/doubles/reals. Again these would be templates.. it's a shame templates still can't overload against functions.

Re: sqrt(2) must go

You could maybe ease transition for people that rely on this behavior via: import std.traits; auto sqrt(F, T)(T x) { return sqrt(cast(F)x); } auto sqrt(F)(F f) if (!isIntegral!F) { return sqrt(f); } void main() { int x = 1; sqrt(4); // ng sqrt!float(x); // ok s

Re: sqrt(2) must go

Don Wrote: > However, when I proposed the fix on the newsgroup (integer literals > should have a preferred conversion to double), it was *unanimously* > rejected. Those who had argued for the hack were conspicuously absent. > > The hack must go. > I agree. If we should have a proper fix, or n

Re: sqrt(2) must go

On 19-10-2011 18:22, Alex Rønne Petersen wrote: On 19-10-2011 18:18, Don wrote: In D2 prior to 2.048, sqrt(2) does not compile. The reason is that it's ambiguous whether it is sqrt(2.0), sqrt(2.0L), or sqrt(2.0f). This also applies to _any_ function which has overloads for more than one floating

Re: sqrt(2) must go

On 19-10-2011 18:18, Don wrote: In D2 prior to 2.048, sqrt(2) does not compile. The reason is that it's ambiguous whether it is sqrt(2.0), sqrt(2.0L), or sqrt(2.0f). This also applies to _any_ function which has overloads for more than one floating point type. In D2 between versions 2.049 and th

sqrt(2) must go

In D2 prior to 2.048, sqrt(2) does not compile. The reason is that it's ambiguous whether it is sqrt(2.0), sqrt(2.0L), or sqrt(2.0f). This also applies to _any_ function which has overloads for more than one floating point type. In D2 between versions 2.049 and the present, sqrt(2) compiles du