From macrakis at alum.mit.edu  Tue Mar 17 15:04:39 2009
From: macrakis at alum.mit.edu (Stavros Macrakis)
Date: Tue, 17 Mar 2009 10:04:39 -0400
Subject: [Rd] Match .3 in a sequence
In-Reply-To: <20090317060749.GA24730@cs.cas.cz>
References: <48f8cced0903160636k112500f6k4b8d46c1ac775d89@mail.gmail.com>
	<8b356f880903160824q4fb9068br1f22601064a8042d@mail.gmail.com>
	<48f8cced0903161553u7969905ck69e7ebd7831f1f3a@mail.gmail.com>
	<8b356f880903161639q29e8bf4eh29624516bf8aa783@mail.gmail.com>
	<20090317060749.GA24730@cs.cas.cz>
Message-ID: <8b356f880903170704x5816183of63b0220edef4a62@mail.gmail.com>

Petr,

Thank you for the detailed diagnosis of the bizarre behavior I
reported, which seems to indicate several distinct problems in the
underlying code:

1) Factor allows repeated levels, e.g. factor(c(1),c(1,1,1)), with no
warning or error.

2) Even from distinct inputs, factor of a numeric vector may generate
repeated levels, because it only uses 15 digits.

3) The algorithm to determine the shortest format is inconsistent with
the algorithm to actually print, giving pathological cases like 0.3
vs. 0.300000000000000.

About:

> In order to avoid using 15 digits in as.character(), we can use round(,digits),
> with digits argument appropriate for the current situation.
>
> ?> fact <- as.factor(round(nums,digits=1)); fact
> ?[1] 0.3 0.3 0.3 0.3
> ?Levels: 0.3

The original problem was testing whether a floating-point number was a
member of a vector.  rounding and then converting to a factor seem
like a very poor way of doing that, even if the above problems were
resolved.  Comparing with a tolerance seems much more robust, clean,
and efficient.

           -s



[Rd] Match .3 in a sequence
Stavros Macrakis