[R] Mystery Error in midnightStandard

[Yohan Chalabi]

>>>> "TB" == Ted Byers <r.ted.byers at gmail.com>
>>>> on Wed, 28 Jan 2009 11:25:55 -0500

   TB> That the two behave the same doesn't change the assessment
   TB> that the design
   TB> is flawed.  That doesn't mean that the function is wrong.
   TB> It means only
   TB> that the behaviour can be made more useful.  For example,
   TB> in SQL, if a given
   TB> calculation returns NULL, and the result is subsequently used
   TB> in another
   TB> calculation, the result that returns is also NULL.  That is
   TB> quite useful,
   TB> and admits algorithms that can react appropriately to NULLs
   TB> when necessary.
   TB> That is arguably better than forcing the code to fail the
   TB> moment a NULL is
   TB> used in a secondary calculation.  In C++, OTOH, one can catch
   TB> the problem
   TB> earlier using, e.g., exceptions, again allowing the program
   TB> to complete even
   TB> when problems arise for certain values or combinations thereof.
   TB>
   TB> As a software engineer, I understand the issues involved
   TB> in creating
   TB> libraries.  If I want to incorporate the functionality of a
   TB> given standard
   TB> suite of functions (e.g. ANSI C standard library functions,
   TB> or posix
   TB> functions), my first step would be to ensure I can duplicate
   TB> how they
   TB> behave.  But I would not stop there.  There are, for example,
   TB> serious design
   TB> flaws in many ANSI C functions that, ignored, introduce
   TB> serious security
   TB> defects in applications that use them.  I would therefore
   TB> refactor them to
   TB> eliminate the security defects.  If they can not be eliminated,
   TB> I would
   TB> replace the function in question by a similar function that
   TB> does not have
   TB> that security defect.
   TB>
   TB> Posix is a useful, but old, standard, and I am merely suggesting
   TB> that once
   TB> you have duplicated it, look beyond it to ways it can be
   TB> improved upon.
   TB> There is more to the design of a function than whether or not
   TB> it gives the
   TB> right result with good input.  There is how it behaves when
   TB> there is a
   TB> problem with the inputs and whether or not you force the
   TB> calling code to die
   TB> when a problem arises or you give the calling code a way to
   TB> react to such
   TB> problems.  When I add functions to my own C++ or Java libraries,
   TB> I normally
   TB> include more bad input data in the unit tests than good data
   TB> (though the
   TB> latter is sufficient to ensure correct results are invariably
   TB> obtained),
   TB> precisely so I can document how it behaves when there is a
   TB> problem and give
   TB> coders who use it a variety of options to use to deal with them.
   TB>
   TB>
   TB> >
   TB> > strptime(datestr, format = %Y-%U-%w)
   TB> >
   TB> > Instead of claiming that there is a flaw in the function
   TB> you could have
   TB> > suggested an 'is.na' method for 'timeDate'.
   TB> >
   TB>
   TB> At the time, I did not know about is.na.  I have spent the
   TB> past hour trying
   TB> is.na, but to no avail.  I guess that is no surprise to you,
   TB> but that it
   TB> would fail is not reflected in the R documentation of is.na.
   TB> That mentions
   TB> S3, but not S4.  As I just recently started using R, I have
   TB> not yet looked
   TB> at what S3 and S4 are, so that is a few more hours of study
   TB> before I get
   TB> this problem solved.
   TB>
   TB>
   TB> >
   TB> > I will add an 'is.na' method in the dev version of 'timeDate'.
   TB> >
   TB> >
   TB> Thanks.  I'll benefit from that once it makes it into the
   TB> production
   TB> release.  In the mean time, I need to find a way to make
   TB> something similar
   TB> now, in my script.

setMethod("is.na", "timeDate", function(x) is.na(as.POSIXct(x)))

   TB>
   TB> Thanks




-- 
PhD student
Swiss Federal Institute of Technology
Zurich

www.ethz.ch