From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: Re: [bug?] Copy content from one to another table changes the content Date: Tue, 16 Jul 2013 12:24:20 +0200 Message-ID: References: <874nbxizti.fsf@gmail.com> <877ggseyik.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c367d649774104e19e611b Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz2Qi-0003bH-E1 for emacs-orgmode@gnu.org; Tue, 16 Jul 2013 06:24:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uz2Qg-0001cZ-62 for emacs-orgmode@gnu.org; Tue, 16 Jul 2013 06:24:24 -0400 Received: from mail-ea0-x230.google.com ([2a00:1450:4013:c01::230]:64026) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uz2Qf-0001cE-RL for emacs-orgmode@gnu.org; Tue, 16 Jul 2013 06:24:22 -0400 Received: by mail-ea0-f176.google.com with SMTP id z15so264551ead.21 for ; Tue, 16 Jul 2013 03:24:20 -0700 (PDT) In-Reply-To: <877ggseyik.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nick Dokos Cc: Org Mode Mailing List --001a11c367d649774104e19e611b Content-Type: text/plain; charset=ISO-8859-1 Hi again, I think I got a bit more of an idea what is going wrong thanks to Nick. I use $1 = remote(prf94120_orig, @@#$6) which reads copy from table prf94120_orig row (@) of the current to be processed field (@#) column ($) 6 into column ($) 1. The org-mode manual refers to @# as operator for formulas and hence I believe the result will be parsed by calc to get a meaningful output. That is ok for simple strings without space or comma separators, since they remain strings. However, a string like "text,text" will be send to calc as ("text","text") which is the calc notation for imaginary numbers. Either, I should use a different way to copy the column or this could be considered as a bug?! Actually, I still do not understand the need to let calc parse that a field-content. If I want to do math, I am not suppose to express this explicit by my formula? Instead of having a single field content of "1 + 2" evaluated to be "3" by remote copy, I would expect to do something like remote(NAME, REF) + remote(NAME, REF) for calculating the sum of two remote fields or in case I really have a complete expression in a single field, I would expect to do something like (calc remote(NAME, REF)) explicit to get it parsed by calc and placing the result in the new table?! Somehow, I miss something. Would be glad if someone could explain to me the reason for the original behaviour. Thanks Torsten On 15 July 2013 15:36, Nick Dokos wrote: > Torsten Wagner writes: > > > > > I can confirm that behaviour for org-mode < 8.0 (tested on 7.9.3f) if > that matter. > > Furtermore, I tested a lot of alternatives. > > "lastname, firstname" > > lastname, firstname > > lastname; firstname > > etc. > > It seems, they all get somehow evaluated by calc, which ends up in funny > different results. > > I do not understand what was the intention of letting the code be parsed > by calc but it seems to cause trouble. > > > > As I said, I don't know much about the implementation of tables, but I > think passing every entry in the table through calc is by design. And it > does not need to cause trouble either: > > (calc-eval "abc, def") ---> "abc, def" > > So trying to selectively *not* pass a cell through calc seems to be the > wrong way to go. > > > Will test to comment how to get around it > > > > Thanks > > Torsten > > > > On 15 July 2013 11:43, Torsten Wagner wrote: > > > > Hi Nick, > > > > very good observation. Just wonder are we the first who observe this > problem?! > > It seems org-table-make-reference and calc-eval have some sort of an > different idea of the data content. > > Yes calc use that notation to deal with imaginary numbers. Funny > coincidence, the students in that list just struggle with exactly those > imaginary numbers and now there names > > became a imaginary number itself... ;) > > > > Thanks for the tip, I will see if some search and replace helps me > to create a intermediate solution. > > > > Thanks > > > > Torsten > > > > On 14 July 2013 05:29, Nick Dokos wrote: > > > > Torsten Wagner writes: > > > > > I just notice a strange behaviour within tables. I want to > copy a > > > column of one table into another... using > $1=remote(prf94120_orig, > > > @@#$6). The original content consist of names in the form > > > "lastname,firstnames". However, executing the above formular I > receive > > > "lastname + firstnames i" > > > > > > I have totally no clue what is the reason for that.... a bug?! > > > Happens within Org-mode version 8.0.3 > > > > > > > I tried it (on a single table too - no remote) and I get the same > > behavior. I can't pretend to understand how anything in > org-table.el > > works, but I think this is a clue: on line 2678, > > org-table-make-reference is called. If I call it by hand like > this > > > > (org-table-make-reference "a, b" nil nil nil) --> "(a, b)" > > > > Then on line 2706, calc-eval is called. If I call it by hand on > the > > value above > > > > (calc-eval "(a, b)") --> "a + b i" > > > > I think it's trying to do arithmetic on complex numbers... > > -- > > Nick > > > > -- > Nick > > > --001a11c367d649774104e19e611b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi again,
I think I got a bit more of an idea what is going wrong thanks t= o Nick.

I use $1 =3D remote(prf94120_orig, @@#$6)

which= reads copy from table prf94120_orig=A0 row (@)=A0 of the current to be pro= cessed field (@#)=A0 column ($) 6 into column ($) 1.
The org-mode manual refers to @# as operator for formulas and hence I= believe the result will be parsed by calc to get a meaningful output. That= is ok for simple strings without space or comma separators, since they rem= ain strings.

However, a string like "text,text" will be send to calc as (&= quot;text","text") which is the calc notation for imaginary = numbers.

Either, I should use a different way to copy the colu= mn or this could be considered as a bug?!

Actually, I still do not understand the need to let calc parse th= at a field-content.
If I want to do math, I am not suppose to exp= ress this explicit by my formula?
Instead of having a single field= content of "1 + 2" evaluated to be "3" by remote copy,= I would expect
to do something like remote(NAME, REF) + remote(NAME, REF) for calculating = the sum of two remote fields or in case I really have a complete expression= in a single field, I would expect to do something like (calc remote(NAME, = REF)) explicit to get it parsed by calc and placing the result in the new t= able?!

Somehow, I miss something. Would be glad if someone could explain= to me the reason for the original behaviour.

Thanks

T= orsten







On 15 July 2013 15:36, = Nick Dokos <ndokos@gmail.com> wrote:
Torsten Wagner <torsten.wagner@gmail.com> write= s:

>
> I can confirm that behaviour for org-mode < 8.0 (tested on 7.9.3f) = if that matter.
> Furtermore, I tested a lot of alternatives.
> "lastname, firstname"
> lastname, firstname
> lastname; firstname
> etc.
> It seems, they all get somehow evaluated by calc, which ends up in fun= ny different results.
> I do not understand what was the intention of letting the code be pars= ed by calc but it seems to cause trouble.
>

As I said, I don't know much about the implementation of tables, = but I
think passing every entry in the table through calc is by design. And it does not need to cause trouble either:

(calc-eval "abc, def") ---> "abc, def"

So trying to selectively *not* pass a cell through calc seems to be the
wrong way to go.

> Will test to comment how to get around it
>
> Thanks
> Torsten
>
> On 15 July 2013 11:43, Torsten Wagner <torsten.wagner@gmail.com> wrote:
>
> =A0 =A0 Hi Nick,
>
> =A0 =A0 very good observation. Just wonder are we the first who observ= e this problem?!
> =A0 =A0 It seems org-table-make-reference and calc-eval have some sort= of an different idea of the data content.
> =A0 =A0 Yes calc use that notation to deal with imaginary numbers. Fun= ny coincidence, the students in that list just struggle with exactly those = imaginary numbers and now there names
> =A0 =A0 became a imaginary number itself... ;)
>
> =A0 =A0 Thanks for the tip, I will see if some search and replace help= s me to create a intermediate solution.
>
> =A0 =A0 Thanks
>
> =A0 =A0 Torsten
>
> =A0 =A0 On 14 July 2013 05:29, Nick Dokos <ndokos@gmail.com> wrote:
>
> =A0 =A0 =A0 =A0 Torsten Wagner <torsten.wagner@gmail.com> writes:
>
> =A0 =A0 =A0 =A0 > I just notice a strange behaviour within tables. = I want to copy a
> =A0 =A0 =A0 =A0 > column of one table into another... using $1=3Dre= mote(prf94120_orig,
> =A0 =A0 =A0 =A0 > @@#$6). The original content consist of names in = the form
> =A0 =A0 =A0 =A0 > "lastname,firstnames". However, executi= ng the above formular I receive
> =A0 =A0 =A0 =A0 > "lastname + firstnames i"
> =A0 =A0 =A0 =A0 >
> =A0 =A0 =A0 =A0 > I have totally no clue what is the reason for tha= t.... a bug?!
> =A0 =A0 =A0 =A0 > Happens within Org-mode version 8.0.3
> =A0 =A0 =A0 =A0 >
>
> =A0 =A0 =A0 =A0 I tried it (on a single table too - no remote) and I g= et the same
> =A0 =A0 =A0 =A0 behavior. I can't pretend to understand how anythi= ng in org-table.el
> =A0 =A0 =A0 =A0 works, but I think this is a clue: on line 2678,
> =A0 =A0 =A0 =A0 org-table-make-reference is called. If I call it by ha= nd like this
>
> =A0 =A0 =A0 =A0 =A0 (org-table-make-reference "a, b" nil nil= nil) --> "(a, b)"
>
> =A0 =A0 =A0 =A0 Then on line 2706, calc-eval is called. If I call it b= y hand on the
> =A0 =A0 =A0 =A0 value above
>
> =A0 =A0 =A0 =A0 =A0 (calc-eval "(a, b)") --> "a + b = i"
>
> =A0 =A0 =A0 =A0 I think it's trying to do arithmetic on complex nu= mbers...
> =A0 =A0 =A0 =A0 --
> =A0 =A0 =A0 =A0 Nick
>

--
Nick



--001a11c367d649774104e19e611b--