COIN-OR::LEMON - Graph Library

About

Downloads

Documentation

Development

Issue Tracker

Browse Tickets

Custom Query

Roadmap

Browse Source

Local Info

Mailing Lists

Search

Changes between Initial Version and Version 6 of Ticket #74


Ignore:
Timestamp:
04/14/08 15:35:45 (17 years ago)
Author:
Balazs Dezso
Comment:

Replying to alpar:

Replying to deba:

New patch based on the ported time_measure.h.

Thanks. In fact, it seems to be more than just a mingw compatibility fix, a lot of internals has also (positively) changed.

I have to minor issued.

  1. In the old version, TimeStamp stored the number of kernel ticks instead of seconds because I was worried whether rounding error could cause some problem. (The time of a kernel tick cannot be represented precisely on a double). Right now, I cannot see any real-life example where it would really cause problem, so I'm not against this change at all, just ask you to reconsider this change once more.
  2. In the stamp() function, please move the #ifdef into the execution block. (Otherwise it may happen that the documentation will not be generated to this function on Windows.)

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #74

    • Property Owner changed from Alpar Juttner to Balazs Dezso

  • Ticket #74 – Description

    initial v6  
    1 Currently the the problematic files in SVN are
    2  - {{{lemon/time_measure.h}}}
    3  - {{{lemon/graph_to_eps.h}}}
    4 
    5 Both require some linux specific time query functions ({{{times()}}}, {{{gettimeofday()}}} and {{{ctime()}}}). In the SVN repo, there is an implementation of these in {{{lemon/bits/mingw32_time.*}}} (thanks to Dann Corbit), but the code isn't clean enough.
     12) I uploaded the new patch based on your issue.
     21) In my opinion, the rounding error is just a slightly dependent on this change. If t1 and t2 values are the retrieved timestamps and c is the clock time, then the (t2-t1)/c and the t2/c-t1/c should give back nearly the same value, because the division could not cause big relative error. But I think, the conversion from clock_t to double, which is already in the original version, could cause big relative error, when we subtract t1 from t2. However, on a regular linux desktop it does not cause problem, because the sensitivity of timer is at most 1/1000 second, and the double value has 52 binary digits, so more than 140 thousand years can measured with TimeStamp.