[Issue 4965] Lacking int, uint etc. versions of most std.math functions

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=4965

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||and...@erdani.com
 Resolution|--- |WONTFIX

--- Comment #5 from Andrei Alexandrescu  ---
Guess I'll close this for now. Please reopen if there are new insights.

--

[Issue 4965] Lacking int, uint etc. versions of most std.math functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4965


Peter Alexander peter.alexander...@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: ---

[Issue 4965] Lacking int, uint etc. versions of most std.math functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4965


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au


--- Comment #1 from Don clugd...@yahoo.com.au 2010-10-01 03:11:46 PDT ---
(In reply to comment #0)
 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: ---

[Issue 4965] Lacking int, uint etc. versions of most std.math functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4965



--- Comment #2 from Peter Alexander peter.alexander...@gmail.com 2010-10-01 
05:17:33 PDT ---
(In reply to comment #1)
 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: ---

[Issue 4965] Lacking int, uint etc. versions of most std.math functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4965



--- Comment #3 from Don clugd...@yahoo.com.au 2010-10-01 05:44:29 PDT ---
(In reply to comment #2)
 (In reply to comment #1)
  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: ---

[Issue 4965] Lacking int, uint etc. versions of most std.math functions

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4965



--- Comment #4 from Peter Alexander peter.alexander...@gmail.com 2010-10-01 
09:30:26 PDT ---
(In reply to comment #3)
 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: ---