www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4965] New: Lacking int, uint etc. versions of most std.math functions

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

           Summary: Lacking int, uint etc. versions of most std.math
                    functions
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: nobody puremagic.com
        ReportedBy: peter.alexander.au gmail.com



01:01:23 PDT ---
I noticed that sqrt(int), sqrt(uint) etc. were added to std.math in DMD 2.049
so that you don't have to cast to float or real to calculate simple things like
sqrt(2).

Is there any reason why integer versions haven't been added for other math
functions, like all the trig functions, the exp/log family etc.? These would be
useful for the very same reason, and inconsistency isn't very good for library
usability.

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


Peter Alexander <peter.alexander.au gmail.com> changed:

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


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


Don <clugdbug yahoo.com.au> changed:

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




 I noticed that sqrt(int), sqrt(uint) etc. were added to std.math in DMD 2.049
 so that you don't have to cast to float or real to calculate simple things like
 sqrt(2).
 
 Is there any reason why integer versions haven't been added for other math
 functions, like all the trig functions, the exp/log family etc.? These would be
 useful for the very same reason, and inconsistency isn't very good for library
 usability.
Yes, there is a very good reason. It's a dreadful hack. This is the reason why I was extremely strongly opposed to those overloads being added to std.math. They will have to be removed eventually. Essentially, they are hack for the fact that integer literals don't implicitly convert to double. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4965




05:17:33 PDT ---

 Essentially, they are hack for the fact that integer literals don't implicitly
 convert to double.
Aside from labelling it as a "hack" (which is personal opinion), what is your problem with it i.e. does it actually cause any problems, or have any negative side effects? Normally, a hack is something that is done for short-term convenience but introduces long-term problems (or problems that only occur in rare situations). I fail to see any problems introduced by allowing integer arguments to these functions, yet there is obviously a benefit to doing so (convenience). If people want to call these functions with integers then I see no reason to force them to tediously cast to real or float all the time. D is supposed to be a highly expressive language, and needless casts hurt expressiveness. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 01 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4965






 Essentially, they are hack for the fact that integer literals don't implicitly
 convert to double.
Aside from labelling it as a "hack" (which is personal opinion), what is your problem with it i.e. does it actually cause any problems, or have any negative side effects?
 Normally, a hack is something that is done for short-term convenience but
 introduces long-term problems (or problems that only occur in rare situations).
 I fail to see any problems introduced by allowing integer arguments to these
 functions
Have you seen the code in std.math? It is a really foul hack. If you have a function with 3 arguments, you need to write more than 1000 function overloads. I'm not kidding. Worst code bloat I've seen in my life. The reason why this problem with sqrt arose, is that originally, we only had real sqrt(real), and everything was fine. Then, for reasons I don't understand, overloads for float sqrt(float) and double sqrt(double) were added. Once those were added, integer arguments failed to work. The correct solution at this stage of the language would have been to remove those essentially useless overloads until the language can support them properly. The only place they make any difference is when there is type inference involved. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 01 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4965




09:30:26 PDT ---

 Have you seen the code in std.math? It is a really foul hack.
 If you have a function with 3 arguments, you need to write more than 1000
 function overloads. I'm not kidding. Worst code bloat I've seen in my life.
Surely constrained templates can help here? I agree that the way they were added was a mess, but that's not an argument for not having them at all (unless it was the only way). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 01 2010