|
Bugzilla – Full Text Bug Listing |
| Summary: | implementation of myceil in pbs.pm | ||
|---|---|---|---|
| Product: | GRAM | Reporter: | Olaf Schneider <Olaf.Schneider@iwr.fzk.de> |
| Component: | wsrf scheduler interface | Assignee: | Joe Bester <bester@mcs.anl.gov> |
| Status: | RESOLVED FIXED | ||
| Severity: | trivial | CC: | bester@mcs.anl.gov, feller@mcs.anl.gov, smartin@mcs.anl.gov |
| Priority: | P3 | ||
| Version: | 4.0.3 | ||
| Target Milestone: | 4.0.6 | ||
| Hardware: | PC | ||
| OS: | All | ||
Is this a problem you've actually encountered? Not using POSIX::ceil was a micro-optimization to avoid disk accesses when running the job script.
(In reply to comment #1) > Is this a problem you've actually encountered? Not using POSIX::ceil was a > micro-optimization to avoid disk accesses when running the job script. The only Problem I had, was to understand, what this strange function myceil actually does. No doubt, a ceil function which sometimes produces a non-int (according to the written code) is strange. I am not sure, if my first suggestion is a really good clarification. Regarding the only call to myceil in pbs.pm it meight be much better to user sprintf. Using POSIX or not: To avoid confusion of code readers like me, there should be a comment with the specific explanation you gave above.
1. myceil should always return an integer: sub myceil ($) { my $x = shift; - ( abs($x-int($x)) < 1E-12 ) ? $x : int($x < 0 ? $x : $x+1.0); + ( abs($x-int($x)) < 1E-12 ) ? int($x) : int($x < 0 ? $x : $x+1.0); } 2. Should we use POSIX::ceil instead?