http://d.puremagic.com/issues/show_bug.cgi?id=6725
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com,
http://d.puremagic.com/issues/show_bug.cgi?id=6725
--- Comment #2 from Andrej Mitrovic 2013-02-08
17:49:08 PST ---
(In reply to comment #1)
> worth of adding
*worth adding
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail becau
http://d.puremagic.com/issues/show_bug.cgi?id=6725
--- Comment #3 from Jonathan M Davis 2013-02-08 18:23:30
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
http://d.puremagic.com/issues/show_bug.cgi?id=6725
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #
http://d.puremagic.com/issues/show_bug.cgi?id=6725
--- Comment #5 from Jonathan M Davis 2013-02-08 22:26:54
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
http://d.puremagic.com/issues/show_bug.cgi?id=6725
--- Comment #6 from Walter Bright 2013-02-08
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 w
http://d.puremagic.com/issues/show_bug.cgi?id=6725
Walter Bright changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://issues.dlang.org/show_bug.cgi?id=6725
Vladimir Panteleev changed:
What|Removed |Added
CC||thecybersha...@gmail.com
Resolut
https://issues.dlang.org/show_bug.cgi?id=6725
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #8 fro
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #9 from Jonathan M Davis ---
(In reply to Steven Schveighoffer from comment #8)
> Note, the indicated mechanism to make a proper duration has improved
> somewhat:
>
> 1.second + 500.msecs + 100.usecs;
>
> I think this still looks awful.
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #10 from Steven Schveighoffer ---
(In reply to Jonathan M Davis from comment #9)
> (In reply to Steven Schveighoffer from comment #8)
> > Note, the indicated mechanism to make a proper duration has improved
> > somewhat:
> >
> > 1.second
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #11 from Jonathan M Davis ---
(In reply to Steven Schveighoffer from comment #10)
> I was just going by the example you gave. You could do it in 2 pieces, but
> then you start getting into much larger numbers:
>
> 1.second + 500100.usecs;
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #12 from Vladimir Panteleev ---
I'd just like to point out that there are more uses to FP time values than
literals, such as user input. A template which accepts a string as a
compile-time parameter solves none of my personal use-cases.
-
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #13 from Jonathan M Davis ---
(In reply to Vladimir Panteleev from comment #12)
> I'd just like to point out that there are more uses to FP time values than
> literals, such as user input. A template which accepts a string as a
> compile-t
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #14 from Vladimir Panteleev ---
> while being a royal pain for anyone who wanted to use floating point values
> for time directly
I think that's objectively false: just add `.text`
--
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #15 from Steven Schveighoffer ---
(In reply to Jonathan M Davis from comment #11)
>
> I'm not opposed to something like durLit!("1.2552", "seconds") which is then
> essentially a Duration literal which can be a floating point value. Howev
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #16 from Jonathan M Davis ---
(In reply to Steven Schveighoffer from comment #15)
> (In reply to Jonathan M Davis from comment #11)
> >
> > I'm not opposed to something like durLit!("1.2552", "seconds") which is then
> > essentially a Dur
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #17 from Vladimir Panteleev ---
(In reply to Jonathan M Davis from comment #16)
> Would you honestly expect folks to be using to!string or text to convert
> floating point values to Durations in their code on a regular basis? Sure,
> someo
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #18 from Jonathan M Davis ---
(In reply to Vladimir Panteleev from comment #17)
> (In reply to Jonathan M Davis from comment #16)
> > Would you honestly expect folks to be using to!string or text to convert
> > floating point values to Dur
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #19 from Vladimir Panteleev ---
> However, it's definitely more palatable than supporting floating point values
> directly, because that would just encourage bad practices.
Honestly, I think this is a poor argument. People who are in the
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #20 from Jonathan M Davis ---
But honestly, is it really all that hard to just write a wrapper function?
auto floatDur(string units)(real value)
if(is(typeof(convert!(units, "hnsecs")(1
{
enum hnsecsPer = convert!(units, "hnse
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #21 from Vladimir Panteleev ---
> But honestly, is it really all that hard to just write a wrapper function?
The argument "can't you just put it in your code?" can be applied to many
things in the standard library. I have needed the funct
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #22 from Steven Schveighoffer ---
I think adding the 'best' way to convert a floating point to core.time may be
better than saying 'roll your own, and deal with floating point issues'.
Really, anyone can say: dur!"hnsecs"(val * (1000 * 10
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #23 from Jonathan M Davis ---
(In reply to Steven Schveighoffer from comment #22)
> (In reply to Jonathan M Davis from comment #16)
> > Durations aren't as bad as timestamps, but it's still asking for
> > trouble.
>
> This begs the questi
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #24 from Steven Schveighoffer ---
I think those concerns really don't apply here as much as you think. We are
allowing the creation of durations via floating point numbers, not storing
durations as floating point numbers, or doing math wit
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #25 from Sobirari Muhomori ---
(In reply to Vladimir Panteleev from comment #7)
> This argument is exaggerated. Not all measurements of time need to be
> precise. For example, if an utility program could accept a timeout value
> from the u
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #26 from Vladimir Panteleev ---
(In reply to Sobirari Muhomori from comment #25)
> That's an overengineered interface and should be done in your code.
> Fractions of timeouts are practically indiscernible, nobody would need to
> specify it
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #27 from Steven Schveighoffer ---
(In reply to Sobirari Muhomori from comment #25)
> (In reply to Steven Schveighoffer from comment #22)
> >
> > I think this is an exaggeration. It works in nearly all cases, since the
> > least significan
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #28 from Jonathan M Davis ---
(In reply to Steven Schveighoffer from comment #24)
> I think this situation would not arise. Code would still (I hope) be
> comparing SysTime's or Durations, not floating point values. One just uses a
> float
https://issues.dlang.org/show_bug.cgi?id=6725
Jonathan M Davis changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #30 from Jonathan M Davis ---
*** Issue 13176 has been marked as a duplicate of this issue. ***
--
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #31 from Jonathan M Davis ---
Okay. I was going to say that allowing stuff like seconds(.033) would encourage
a lack of precision even in cases where precision was required, and I really
didn't lie that idea, but it looks like the lack of
https://issues.dlang.org/show_bug.cgi?id=6725
Sobirari Muhomori changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=6725
yebblies changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #34 from Vladimir Panteleev ---
(In reply to Sobirari Muhomori from comment #32)
> It's meaningful to sleep for 200ms, but not for 0.2s. When you need a better
> precision, you switch to the appropriate unit. How would you specify 1/60
> f
https://issues.dlang.org/show_bug.cgi?id=6725
Walter Bright changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #35 from Walter Bright ---
(In reply to Vladimir Panteleev from comment #34)
> 200ms and 0.2s are the same thing,
> how can it be meaningful to sleep for 200ms but not for 0.2s?
0.2 cannot be represented exactly as a floating point value.
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #36 from Sobirari Muhomori ---
(In reply to Vladimir Panteleev from comment #34)
> (In reply to Sobirari Muhomori from comment #32)
> > It's meaningful to sleep for 200ms, but not for 0.2s. When you need a better
> > precision, you switch
https://issues.dlang.org/show_bug.cgi?id=6725
--- Comment #37 from Steven Schveighoffer ---
(In reply to Jonathan M Davis from comment #31)
> Okay. I was going to say that allowing stuff like seconds(.033) would
> encourage a lack of precision even in cases where precision was required,
> and I r
39 matches
Mail list logo
