TimeSpan / 2

[Michael C]

Really?!? Not in my experience.
But, then again it could just be the areas we are working in that give us
a different outlook.

Don't get me wrong, I don't divide timespans by integers every day but then
again I don't use TimeSpan every day either.

While I could envision reasons for multiplying/dividing a Timestamp by a
number, I would hardly think they were common. What are you doing with
Timespans that makes this an attractive feature?

In my case I wanted to know if the current time was more than half way
between a previous event and the next scheduled event. But any occasion when
you'd need to divide seconds would be valid.

Agreed. Let's rip it out <grin>


Absolutely, if you are too restrictive, you can make hard to use classes.

I was just trying to offer a reason (besides forgetfulness) why
multiplication/division might be left out of the class.

Makes sense.

The existing TimeSpan was designed to go hand in hand with Datetime
arithmetic.
Addition, Subtraction, hours, minutes, seconds all feel natural to this
class.
Multiplication/Division by a constant feels more like an attempt to do
math with units
miles/hour
meters/sec^2

In that case the timespan class is not really a good fit either.

Why? Because it's based on an integer?

Michael

 

[Michael C]

I count four posts by me, none of which include a statement that there is
no reason.

Do you have a reason or not?

Even if they _all_ included such a statement, your "ten" is wildly
inaccurate, and given that the actual number is _zero_ posts containing
the statement, your claim of "ten" is ridiculous.

You really are a genius peter. Ten is not literal. Do I have to tell you a
million times?

Well, it was the only basis you offered. I quote: "I guess seeing no one
came up with a reason that means the reason is MS simply forgot." And it
was that statement that I took issue with, no other.

Even you should see the humour in the fact that you've spent 10 posts
telling me that I shouldn't infer anything when you've done exactly that.

It's unfortunate that you can't just accept that and move on. But I'm not
interested in wasting any more time reiterating the obviously incorrect
nature of the statement to which I replied. Nor do I see any point in
having a discussion with someone who chooses to characterize my statements
as "bickering".

You're the one who introduced the word bickering. I just suggested it was
you bickering. The statement about no-one coming up with a reason was a
throw away statement designed to introduce further discuss by encouraging
someone to post a reason. It was not something meant to be discussed in
depth turning into a 3 week long thread. I'm not sure what your definition
of bickering is but that pretty much looks like it to me.

If you want to have a civil discussion about the whys and why nots of an
operator overload, you let us know. In the meantime, it's pretty obvious
that you're not going to be happy with any reply that is anything less
than a full agreement with your dissatisfaction with the TimeSpan class's
interface. There's really no point in carrying on with someone acting
that way.

I'm interested in having a civil conversation about the TimeSpan but to be
honest I'm not really interested in having it with you. I find your posting
style to be somewhat prickly. Right at the moment I can't see any reason why
it can't have a divide operator but someone might post something that makes
me change my mind. However, I think it's the nature of this particular
problem is that there is no rock solid reason. Hence anything that someone
posts will have an alternate opinion. If such an alternate opinion exists
then I will post it. It appears you don't like that idea which is why you've
gone well out of your way to avoid posting your reasons.

Michael

 

[Chris Shepherd]

To me it made such perfect sense that I went and coded it fully expecting it
to work. I was quite suprised some time later to get a compile error. The
alternative:

TimeSpan ts2 = new TimeSpan(ts1.Ticks / 2)

appears much more complicated and although I presume that is the correct way
to do it I'm still not certain. Should I convert it to Milliseconds and back
or maybe seconds? Should I be using a double variable or an integer or long?

The only thing I can think of is that doing "ts1 / 2" it's not clear how it
will round but I don't think that's much of an issue. Obviously programmers
will expect it to have a certain level of resolution and that dividing by 2
could cause some minor loss of information.

If you divide one int by another, the result is not rounded, it is truncated. If
you divide 99 by 100 the integer result is 0. This is likely why a TimeSpan,
which is purported by others to be just a wrapper for Int64, wouldn't have a
divisor or multiplier implementation.
If you need to ensure rounding occurs, you'll need to store it in a more precise
type and then round it back to an integer.

Chris.

 

[Michael C]

If you divide one int by another, the result is not rounded, it is
truncated.

I was aware of this, I just used the wrong word.

If you divide 99 by 100 the integer result is 0. This is likely why a
TimeSpan, which is purported by others to be just a wrapper for Int64,
wouldn't have a divisor or multiplier implementation.
If you need to ensure rounding occurs, you'll need to store it in a more
precise type and then round it back to an integer.

This was something I suggested a while ago. If you're timing something that
does 1,000,000 iterations then you might find that when you divide the
timespan by 1,000,000 that you get zero. I don't really think this is a
problem as many other timing methods can result in zero also, eg using
GetTickCount.

 

[Israel]

I was just trying to offer a reason (besides forgetfulness) why
multiplication/division might be left out of the class.
The existing TimeSpan was designed to go hand in hand with Datetime
arithmetic.
Addition, Subtraction, hours, minutes, seconds all feel natural to this
class.
Multiplication/Division by a constant feels more like an attempt to do
math with units
    miles/hour
    meters/sec^2

In that case the timespan class is not really a good fit either.

I think if the "TimeSpan" is going to be the universal representation
of a vector in the time then it makes perfect sense to have a multiply
and divide operator on it. If I want to use it for a sampling
interval which may dynamically change based on a multiplier then I'm
forced to write extra code to do what seems like an natural
extension. Why even use a TimeSpan in that case? It's almost cleaner
to just use a tick count since I can add ticks to a DateTime to get a
new DateTime.

 

[Michael C]

I think if the "TimeSpan" is going to be the universal representation
of a vector in the time then it makes perfect sense to have a multiply
and divide operator on it.

At least I'm not going mad. I guess the nature of newsgroups is that
generally those who agree don't reply.

If I want to use it for a sampling
interval which may dynamically change based on a multiplier then I'm
forced to write extra code to do what seems like an natural
extension. Why even use a TimeSpan in that case? It's almost cleaner
to just use a tick count since I can add ticks to a DateTime to get a
new DateTime.

Yes. If you want to divide TimeSpan by 2 to create another TimeSpan then you
need to know how it implements itself internally anyway.

Michael