From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas S. Dye" Subject: Re: Re: [babel] R questions Date: Tue, 8 Dec 2009 12:40:27 -1000 Message-ID: <526E5F77-3D17-436E-AB7C-EC79F084B559@tsdye.com> Mime-Version: 1.0 (Apple Message framework v936) Content-Type: multipart/mixed; boundary="===============0377126456==" Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NI8jW-0006XM-7R for emacs-orgmode@gnu.org; Tue, 08 Dec 2009 17:40:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NI8jR-0006QF-BZ for emacs-orgmode@gnu.org; Tue, 08 Dec 2009 17:40:37 -0500 Received: from [199.232.76.173] (port=50529 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NI8jR-0006Q0-4J for emacs-orgmode@gnu.org; Tue, 08 Dec 2009 17:40:33 -0500 Received: from outbound-mail-02.bluehost.com ([69.89.21.12]:59078) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1NI8jP-0002ko-3h for emacs-orgmode@gnu.org; Tue, 08 Dec 2009 17:40:32 -0500 Received: from [72.253.144.27] (helo=potofo-ou.westell.com) by box472.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NI8jM-00010J-5v for emacs-orgmode@gnu.org; Tue, 08 Dec 2009 15:40:28 -0700 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode list --===============0377126456== Content-Type: multipart/alternative; boundary=Apple-Mail-9-684469318 --Apple-Mail-9-684469318 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Sebastien, On Dec 8, 2009, at 11:37 AM, S=E9bastien Vauban wrote: > Hi Thomas, > > "Thomas S. Dye" wrote: >> On Dec 7, 2009, at 11:50 PM, S=E9bastien Vauban wrote: >> >>>> [2] I guess one could potentially think about dealing with =20 >>>> missing values >>>> more explicitly in org-babel. E.g. there could be a header arg >>>> specifying what values are to be treatyed as missing. Nothing =20= >>>> like >>>> that exists currently. >>> >>> I guess such a feature would be required on the long term. Of =20 >>> course, even >>> specifying what would be the needed behavior is already difficult, =20= >>> I think. >>> One must have good knowledge of the multiple languages and =20 >>> environments, >>> and try to abstract the best behavior out of these. >>> >>> Side note -- I know, for example, that there is an option in =20 >>> Access to let >>> it consider the empty string ('') as the NULL value, or not. Clear. >>> >>> But what's a "NA" value in general? Is 0 always a meaningful =20 >>> value as >>> numeric? Context-sensitive.. >> >> NA is a logical constant of length 1 which contains a missing value >> indicator. Whether or not 0 is a meaningful value as numeric =20 >> depends on your >> data and the questions you are asking of it. You don't ask this =20 >> question, > > ? I thought I addressed that when asking (to myself) "Is 0 always a > meaningful value as numeric?" and answering [that it certainly is] > "context-sensitive.." > > >> but if I read this thread correctly and you are trying to =20 >> workaround a data >> input problem with R in Org-babel, > > No, you misread, or I mis-wrote ;-) > > I wasn't speaking of R only, saying that "such a feature would be =20 > required on > the long term [... for] the multiple languages". > > Thinking at shell-script (with empty strings), SQL code (with empty =20= > strings > and NULL values), etc. > > >> then replacing missing values with 0 in a numeric context to get =20 >> around the >> Org-babel problem is NOT a good idea. > > Implementing a fixed interpretation is NOT a good idea. I share your =20= > point of > view. > > My comments were: > > - I think we must be able to write a rule for interpreting =20 > "empty" (whatever > it means) values; > > - We should think at what's needed to cover the current and future =20 > needs, not > focusing on one specific language (R), but thinking at all of them =20= > (shell > commands, SQL, etc.). > > Best regards, > Seb > > --=20 > S=E9bastien Vauban I agree with you on the importance of having some way to represent =20 missing values in Org-babel that can be translated cleanly and =20 transparently to the representations used by specific languages. I was responding to one part of your longer message in the context of =20= the message subject, "R questions." I see now that you were asking a =20= more general question. Mea culpa. All the best, Tom Thomas S. Dye, Ph.D. T. S. Dye & Colleagues, Archaeologists, Inc. Phone: (808) 529-0866 Fax: (808) 529-0884 http://www.tsdye.com --Apple-Mail-9-684469318 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi = Sebastien,

On Dec 8, 2009, at 11:37 AM, S=E9bastien = Vauban wrote:

Hi Thomas,

"Thomas S. Dye" = wrote:
On Dec 7, 2009, at 11:50 PM, = S=E9bastien Vauban wrote:

[2] I guess one could = potentially think about dealing with missing = values
   more explicitly in org-babel. E.g. there = could be a header = arg
   specifying what values are to be = treatyed as missing. Nothing = like
   that exists = currently.

I guess such a feature would be = required on the long term. Of course, = even
specifying what would be the needed behavior is already = difficult, I think.
One must have good knowledge of = the multiple languages and = environments,
and try to abstract the best = behavior out of these.

Side note -- I know, for = example, that there is an option in Access to = let
it consider the empty string ('') as the NULL value, or = not. Clear.

But what's a "NA" value in = general?  Is 0 always a meaningful value = as
numeric? =  Context-sensitive..

NA is a logical = constant of length 1 which contains a missing = value
indicator. Whether or = not 0 is a meaningful value as numeric depends on = your
data and the questions = you are asking of it. You don't ask this question,

? =  I thought I addressed that when asking (to myself) "Is 0 always = a
meaningful value as numeric?" and answering [that it certainly = is]
"context-sensitive.."


but if = I read this thread correctly and you are trying to workaround a = data
input problem with R in = Org-babel,

No, you misread, or I = mis-wrote ;-)

I wasn't speaking of R only, saying that "such = a feature would be required on
the long term [... for] the multiple = languages".

Thinking at shell-script (with empty strings), SQL = code (with empty strings
and NULL values), = etc.


then replacing missing values = with 0 in a numeric context to get around = the
Org-babel problem is NOT a = good idea.

Implementing a fixed interpretation is = NOT a good idea. I share your point of
view.

My comments = were:

- I think we must be able to write a rule for interpreting = "empty" (whatever
 it means) values;

- We should think at = what's needed to cover the current and future needs, = not
 focusing on one specific language (R), but thinking at all = of them (shell
 commands, SQL, etc.).

Best = regards,
 Seb

-- 
S=E9bastien = Vauban

I agree with you on = the importance of having some way to represent missing values in = Org-babel that can be translated cleanly and transparently to the = representations used by specific languages.

I = was responding to one part of your longer message in the context of the = message subject, "R questions."  I see now that you were asking a = more general question.  Mea culpa.

All the = best,
Tom