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: Mon, 15 Jul 2013 15:27:17 +0200 Message-ID: References: <874nbxizti.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b62432cc8096c04e18cd118 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60640) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyioC-0006Ic-H6 for emacs-orgmode@gnu.org; Mon, 15 Jul 2013 09:27:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UyioB-0001SI-4P for emacs-orgmode@gnu.org; Mon, 15 Jul 2013 09:27:20 -0400 Received: from mail-ee0-x22d.google.com ([2a00:1450:4013:c00::22d]:52284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyioA-0001SB-Qh for emacs-orgmode@gnu.org; Mon, 15 Jul 2013 09:27:19 -0400 Received: by mail-ee0-f45.google.com with SMTP id c1so7588505eek.32 for ; Mon, 15 Jul 2013 06:27:18 -0700 (PDT) In-Reply-To: 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 --047d7b62432cc8096c04e18cd118 Content-Type: text/plain; charset=ISO-8859-1 Hi again, 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. 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 >> >> >> > --047d7b62432cc8096c04e18cd118 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi again= ,

I can confirm that behaviour for org-mode < 8.0 (tested o= n 7.9.3f) if that matter.
Furtermore, I tested a lot of alternativ= es.
"lastname, firstname"
lastname, firstname
lastn= ame; firstname
etc.
It seems, they all get somehow evalua= ted by calc, which ends up in funny different results.
I do not un= derstand what was the intention of letting the code be parsed by calc but i= t seems to cause trouble.

Will test to comment how to get around it

Thanks
Torsten



On 15 July 2013 11:43, Torsten Wagner <torsten.wagner@gmail.com> wrote:
Hi Nick,

very good observa= tion. Just wonder are we the first who observe this problem?!
It s= eems 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 coin= cidence, the students in that list just struggle with exactly those imagina= ry numbers and now there names became a imaginary number itself... ;)

Thanks for the tip, I will see if some search and replace helps m= e to create a intermediate solution.

Thanks

Torsten



On 14 July 2013 05:29, Nick Dokos <ndokos@gmail.com> wrote:
Torsten Wagner <torsten.wagner@gmail.com> writes:

> I just notice a strange behaviour within tables. I want to copy a
> column of one table into another... using $1=3Dremote(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 sa= me
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

=A0 (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

=A0 (calc-eval "(a, b)") --> "a + b i"

I think it's trying to do arithmetic on complex numbers...
--
Nick




--047d7b62432cc8096c04e18cd118--