>>>> "TB" == Ted Byers <r.ted.by...@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
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
