www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6725] New: core.time.dur should accept floating point

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

           Summary: core.time.dur should accept floating point
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: druntime
        AssignedTo: nobody puremagic.com
        ReportedBy: siegelords_abode yahoo.com



I'd prefer to be able to do this:

dur!("secs")(1.0);
dur!("secs")(1.5);
dur!("secs")(1.5001);

instead of having to do this:

dur!("secs")(1);
dur!("msecs")(1500);
dur!("nsecs")(1500100);

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 24 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6725


Andrej Mitrovic <andrej.mitrovich gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich gmail.com,
                   |                            |jmdavisProg gmx.com



17:48:37 PST ---
CC-ing jmdavis: Is it worth of adding this? This is your area of expertise. :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6725




17:49:08 PST ---

 worth of adding
*worth adding -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6725




PST ---
In general, using floating point values like that is asking for trouble,
because you're going to run into precision problems. It's far better to use
integral values with the more precise units, but I can see why someone would
want to be able to do this. It wouldn't be all that big a deal to add it, and
it's probably worth having. It's just of questionable value if you actually
want to be precise.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6725


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



21:53:30 PST ---
Mixing in floating point into what are properly integer operations is nothing
but trouble.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6725




PST ---
Without dur or convert taking floating point values, you're forced to do
something like

auto d = dur!"hnsecs"(cast(long)(convert!("seconds", "hnsecs")(1) * 1.5001)));

which is arguably overly verbose, but I really don't think that using floating
point values for time should be encouraged at all. So, it could definitely be
more user friendly, but I'm not sure that doing so would be a good idea. Too
many people already seem willing to use floating point values for time (they
did in the code base that I work on at work until I ported SysTime and Duration
to C++ for work). So, I don't know what the right balance of user friendliness
and good practice is in this case.

TickDuration _does_ support some floating point stuff, but only converting _to_
them, not from them, and it's essentially a fraction internally. Though if I
could go back, I probably would have gotten rid of TickDuration rather than
integrating it into std.datetime, since I really don't think that it buys us
much over Duration (hnsecs is already better precision than most system clocks
anyway), and the fact that it's basically a fraction has caused quite a bit of
trouble. It's particularly nasty when it comes to trying to test it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6725




23:04:15 PST ---
1. Using floating point for time is like using floating point for accounting
software ($57.23). It doesn't work for things that come in discrete quanta
(pennies, clock ticks). You will spend FAR more time chasing weird problems
than you will save in "convenience". Yes, I have experience with this, and I
understand floating point (having build FP emulators).

2. Many machines have very poor FP performance compared with integer
performance. Implementing basic operations using unnecessary FP results in
slow, bloated code.

3. Phobos' time functions are already massively complex. I still can't even
compile the datetime unittests on a 512Mb machine. Please, no more.

4. It's trivial for a user to write their own FP wrapper around dur. There is
no reason to integrate this into dur itself. Software should be pieced together
using layers of abstraction, not kitchen sink base types.

5. It would take longer to read the documentation for this enhancement than to
just convert your floating point value to an int.

6. You're not forced to write long complicated expressions to convert fp to
integers. It's just a scale and a cast:

    dur!("secs")(1.5001) => dur!("nsecs")(cast(long)(1.5001 * 1000000));

I.e. I feel pretty strongly this is a bad idea for Phobos.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6725


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 08 2013