Re: [O] [bug?] Copy content from one to another table changes the content

[Torsten Wagner]

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 <address@hidden> wrote:

Torsten Wagner <address@hidden> 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 <address@hidden> 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 <address@hidden> wrote:
>
>         Torsten Wagner <address@hidden> 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