www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 692] New: rules for assigning to complex types are too strict

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=692

           Summary: rules for assigning to complex types are too strict
           Product: D
           Version: 0.177
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: wbaxter gmail.com


//You can assign ints and floats and doubles to a double with no
//problem.  Even arrays work.
void test1() {
    // All ok
    double a = 0;
    double b = 0.0;
    double c = 0.0f;
    double[] d = [0];
    double[] e = [0.0];
    double[] f = [0.0f];
}

//But there's very little that can be assigned to a cdouble:
void test2()
{
    // All errors
    cdouble a = 0;
    cdouble b = 0i;
    cdouble c = 0.0;
    cdouble d = 0.0f;
    cdouble e = 0.0fi;
    cdouble[] f = [0];
}

//Yet, it is ok to add many things to a cdouble.
void test3()
{
    // All ok:
    cdouble a = 0+0i;
    cdouble b = a + 0;
    cdouble c = a + 0i;
    cdouble d = a + 0.0;
    cdouble e = a + 0.0f;
    cdouble f = a + 0.0fi;
}


I don't see any good reason for this strictness.  I suspsect nobody's
complained simply because few current users actually touch complex types.

Real world impact:
In writing a generic BLAS/LAPACK-backed nd-array class I find that many of my
generic test cases have to contain sillyness like:
        T z = cast(T)0;
        A = [[z+ 5, z+ 1, z+ 2],
             [z+ 3, z+ 4, z+ 5],
             [z+ 6, z+ 7, z+ 8]];
        x =  [z+ 1, z+ 2, z+ 3];
        b = mult(A,x);

just to handle complex types without generating compiler errors.


--
Dec 16 2006
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=692


wbaxter gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement





Whoops, meant this to be an enhancement request, since I don't think the spec
actually says anywhere what should happen when an int or float is assigned to a
complex type.  At least I couldn't find it.


--
Dec 16 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=692






The rules might seem too strict for the casual user, if you however implement a 
lot of complex math they make debugging a lot easier.

The current rules for implicit assignment:
1) another complex or 2) and operation involving "real" and "imaginary".


--
Dec 29 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=692


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |andrei metalanguage.com
            Version|0.177                       |D1
         AssignedTo|nobody puremagic.com        |bugzilla digitalmars.com



13:31:34 PST ---
Marking this as D1 only as D2 will only use library complex types. I think this
is a wontfix as D1 is frozen, but will leave the decision to Walter.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=692


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



This is not the right place to discuss this, but I remember a discussion about
removing the implementation of complex numbers (and move it into Phobos) and
part of their syntax (ireal, ifloat, etc), but to keep complex literals in D2
(like a + 0.0fi).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=692


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au




 I don't see any good reason for this strictness.


There is a good reason. It was a deliberate decision.
I do not know how the rules could be weakened, without major changes to the
lookup rules.

Originally, the test cases did compile. But the problem is, with the broken
implicit conversion rules we've inherited from C, it interferes with function
overloading in a horrible way.

Consider:
void foo(real x);

Then you add
void foo(creal x);

And suddenly foo(7.0); doesn't compile any more.

The implicit conversions real -> creal were removed for this reason. It's the
lesser of two evils.

Now, I've been planning a proposal for changing the implicit conversion rules
for numeric literals, and possibly that make this possible as well. But it's a
big change, even for D2.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 26 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=692




*** Issue 6006 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 15 2011