Element-wise multiplication of duration and double array

Hi, I try to calculate the energy in a time series dataset. I calculate the power for each record i.e. every hour. Now i would like to compute the energy for each row. I used the :diff" to find the duration for each row and then multiply that duration to power value to calculate the energy. however the final product is duration format. could you please help me with that?

Date  Power (W)
'01-Jan-2005 00:00:00'  362374.8161
'01-Jan-2005 01:00:00'  290296.1116
'01-Jan-2005 02:00:00'  96520.39268
'01-Jan-2005 03:00:00'  96491.92618
'01-Jan-2005 04:00:00'  96420.53794

the code I used so far:

A = diff(dispt);
P(1, : ) = [];
E = P.*A;

[Walter Roberson]

It is not clear to me what dispt or P are here, or what data types are involved?

[dpb]

I don't have the datetime object so can't test here, but I presume the internal representation is still just a date number despite the visual representation.

If so, then also on the assumption you used the 24-hr day option rather than years for the duration computation,

E=double(diff(dispt)).*P;

should give units of [power units-days]; multiplying by 24hr/day would be in (say) MWhrs.

As noted, this is all on the assumption of the internals as can't verify here.

[Walter Roberson]

No, datetime uses Objects; each one can have different format, different timezone, and so on.

[dpb]

OK, but is that actually the value or simply the visual representation, Walter? I can't tell from the documentation; it's awfully short of actual implementation and practical use examples of the results such as what OP wants here.

What is the result of double on the duration object if use the .format=s option on the result?

[Walter Roberson]

The precision of datetime is higher than serial date numbers so there must be more data than a double's-worth .

That doesn't mean that diff() is undefined for them, but the result of the diff would itself be a datetime object... or perhaps a duration object.

[dpb]

OK, I hadn't really thought about the added precision, granted, but it still doesn't address OP's question.

Nor does it answer the question raised above about what is the actual numeric value internally of the duration object--is it the (whatever precision) actual number of elapsed time units in the as-requested formatted units or still (as I would presume) the internal date representation analogous to a date number?

All of which raises another question that I don't see actually addressed -- are date numbers and datetime values based on the same origin so that at least they are consistent at the level of matching precision? Or did TMW break that as well?

If it's actually this hard to get a useful numeric value out, then I'd recommend OP use datenum's for his purpose here; they are simply doubles and can be subtracted and the results used in "ordinary" calculations.

[Walter Roberson]

There are conversion routines to go from duration objects to numeric. In particular seconds() applied to a duration object returns the equivalent numeric seconds. I do not know if a duration object has the same precision as a datetime object -- datetime is documented to nanoseconds but duration objects mention only milliseconds.

You should not think of a datetime object has "really" being a double internally. It isn't. A double could represent only about 104 days worth of nanoseconds. A more likely representation would be multiple fields, the last one of which was a double representing seconds. The documentation mentions the proleptic ISO calendar, which is a multi-field structure; see https://docs.oracle.com/javase/8/docs/api/java/time/chrono/IsoChronology.html

Are they consistent at the level of matching precision? They cannot be: datetime objects handle leap seconds but datenum does not.

[dpb]

It appears the doc 'See Also' section is quite lacking in the duration object section -- couldn't find any of those w/o knowing they existed already.

But, does look like that's the manner by which to get there.

I hadn't really developed any being any particular representation; I've not got enough machine to be able to load/run the latter revisions so all I can do is try to guess as best as can from the doc's what/how to get from here to there...as noted, there being no links from either datetime nor duration to the hours|minutes|seconds, etc., conversion routines was just hoping the casting operations would manage...

[Walter Roberson]

The cross reference is definitely lacking.

[dpb]

Indeed...obtw, on the comment regarding datenum resolution; they can get to about 10 usec...

>> eps(now)*86400/1e-6
ans =
 10.0583
>>

Answer 1

[Rob Purser]

The result of the diff on dispt (which I assume is a datetime) is a duration. You will want to convert the duration to a double before doing math on it using a function like hours or seconds.

-Rob