Thierry Banel writes:
> Le 07/12/2014 04:25, Eric Abrahamsen a écrit :
>
>
> Now I'd like to do more calculations based on the rows in the sum(Chars)
> and sum(Lines) columns.
>
>
> The new version of Aggregate supports adding new columns in the
> aggregated table. This can be achieved in tw
Le 07/12/2014 04:25, Eric
Abrahamsen a écrit :
Now I'd like to do more calculations based on the rows in the sum(Chars)
and sum(Lines) columns.
The new version of Aggregate supports adding new columns in
the aggregated table. This can be
Hi Thierry
On Fri, Dec 12, 2014 at 10:04 PM, Thierry Banel wrote:
> Le 12/12/2014 18:15, Michael Brand a écrit :
> Seems doable.
> Would tie the spreadsheet and orgaggregate seamlessly.
> Very appealing!
>
> Are you willing to help me implement those steps?
Where necessary I try to help.
I woul
Le 12/12/2014 18:15, Michael Brand a écrit :
> Hi Thierry
>
>
>> Here is how the spreadsheet handles those cases (without modifiers):
>> | | | | sum | mean | prod |
>> |---+---+---+-+---+--|
>> | 1 | 2 | 3 | 6 | 2 |6 |
>> | | 2 | 3 | 5 | 1.66
Hi Thierry
On Wed, Dec 10, 2014 at 11:55 PM, Thierry Banel wrote:
> Le 10/12/2014 22:06, Michael Brand a écrit :
>> If this function would follow its docstring by having "(if (cdr vec)"
>> also for sum, min, max and prod then the user could benefit from
>> adding "E" and/or "N" or not in the mode
Le 10/12/2014 22:06, Michael Brand a écrit :
> Hi Thierry
>
> On Tue, Dec 9, 2014 at 11:35 PM, Thierry Banel wrote:
>
>> On output, empty cells are generated when the aggregation function does
>> not have enough input. For instance, =mean= needs at least one value,
>> otherwise a division by zero
Hi Thierry
On Mon, Dec 8, 2014 at 11:32 PM, Thierry Banel wrote:
> Le 08/12/2014 22:12, Thierry Banel a écrit :
>> Le 07/12/2014 17:48, Michael Brand a écrit :
>>> Cool, thank you. As a hint for the user you could add something like
>>> "@<$4 = string("header") etc. to the TBLFMs in the unittests
Hi Thierry
On Tue, Dec 9, 2014 at 11:35 PM, Thierry Banel wrote:
> A clean design has been implemented for handling empty cells.
Very good.
> On output, empty cells are generated when the aggregation function does
> not have enough input. For instance, =mean= needs at least one value,
> otherwi
Ok, done.
A clean design has been implemented for handling empty cells.
Basically, empty input cells are ignored, and therefore they do not
participate in the aggregation. (However, for aggregation using two
columns (=corr(p,q)= for example), if a pair of cells contains both an
empty and a non-emp
Le 08/12/2014 19:02, Michael Brand a écrit :
> #+TBLNAME: original
> | Item | Value |
> |--+---|
> | a2 | 1 |
> | a2 | 1 |
> | a0 |-1 |
> | a0 | 1 |
> | b2 | 2 |
> | b2 | |
> | b0 | 0 |
> | b0 | |
> | c| |
> | c| |
>
>
Le 09/12/2014 06:54, Michael Brand a écrit :
> Hi Thierry
>
> On Mon, Dec 8, 2014 at 10:57 PM, Thierry Banel wrote:
>> You instantly found the weakness of the current design!
> The reason follows very shortly. ;-)
>
>> Definitely interesting. Someone else has already bumped into the empty
>> cells
Hi Thierry
On Mon, Dec 8, 2014 at 10:57 PM, Thierry Banel wrote:
> You instantly found the weakness of the current design!
The reason follows very shortly. ;-)
> Definitely interesting. Someone else has already bumped into the empty
> cells thing.
It was me:
http://thread.gmane.org/gmane.emacs
Le 08/12/2014 22:12, Thierry Banel a écrit :
> Le 07/12/2014 17:48, Michael Brand a écrit :
>> Hi Thierry
>>
>> On Sun, Dec 7, 2014 at 5:13 PM, Thierry Banel wrote:
>>> The new features (:formula parameter and TBLFM survival) have been
>>> pushed to https://github.com/tbanel/orgaggregate. The unit
Le 08/12/2014 19:02, Michael Brand a écrit :
>
> Good. My opinion is about to replace it with what.
>
> https://github.com/tbanel/orgaggregate#empty-and-malformed-input-cells
> says:
>
> An input cell may be empty. In this case, it is silently replaced
> by zero. In an output cell, if the
Le 07/12/2014 17:48, Michael Brand a écrit :
> Hi Thierry
>
> On Sun, Dec 7, 2014 at 5:13 PM, Thierry Banel wrote:
>> The new features (:formula parameter and TBLFM survival) have been
>> pushed to https://github.com/tbanel/orgaggregate. The unittests.org
>> file has been updated. The http://melpa
Hi Thierry
On Sun, Dec 7, 2014 at 10:57 PM, Thierry Banel wrote:
> Done.
> Probably this can be discussed further.
I hope that there are more opinions than only mine.
> For the time being, there is no longer any "NA".
Good. My opinion is about to replace it with what.
https://github.com/tbane
Thierry Banel writes:
> Le 07/12/2014 10:40, Michael Brand a écrit :
>>
>> I suggest that orgaggregate lets the user specify a TBLFM to be
>> inserted and updated. Missing target columns are added automatically,
>> it would result in
>>
>> #+BEGIN: aggregate :table "work" :cols "Translator sum(Ch
Le 07/12/2014 10:39, Michael Brand a écrit :
> Hi Thierry
>
> I suggest that orgaggregate leaves such fields empty instead of "NA".
> This way the user gets a choice how to deal with them by adding e. g.
> EN or not as TBLFM format specifier:
>
> | Translator | sum(Chars) | sum(Lines) |
> |---
Hi Thierry
On Sun, Dec 7, 2014 at 5:13 PM, Thierry Banel wrote:
> The new features (:formula parameter and TBLFM survival) have been
> pushed to https://github.com/tbanel/orgaggregate. The unittests.org
> file has been updated. The http://melpa.org repository will reflect
> the change shortly.
C
Le 07/12/2014 11:26, Michael Brand a écrit :
> Hi Thierry
>
> On Sun, Dec 7, 2014 at 11:02 AM, Thierry Banel wrote:
>> Maybe the TBLFM should be taken care of for any kind of dynamic blocks,
>> not only aggregate (columnview, clocktable, propview, invoice,
>> transpose, and any future dynamic bloc
Le 07/12/2014 11:26, Michael Brand a écrit :
> Hi Thierry
>
> On Sun, Dec 7, 2014 at 11:02 AM, Thierry Banel wrote:
>> Maybe the TBLFM should be taken care of for any kind of dynamic blocks,
>> not only aggregate (columnview, clocktable, propview, invoice,
>> transpose, and any future dynamic bloc
Hi Thierry
On Sun, Dec 7, 2014 at 11:02 AM, Thierry Banel wrote:
> Maybe the TBLFM should be taken care of for any kind of dynamic blocks,
> not only aggregate (columnview, clocktable, propview, invoice,
> transpose, and any future dynamic block).
Yes, see e. g. ":formula" in
http://orgmode.org/
Le 07/12/2014 10:40, Michael Brand a écrit :
>
> I suggest that orgaggregate lets the user specify a TBLFM to be
> inserted and updated. Missing target columns are added automatically,
> it would result in
>
> #+BEGIN: aggregate :table "work" :cols "Translator sum(Chars) sum(Lines)"
> | Translator
Le 07/12/2014 10:39, Michael Brand a écrit :
> Hi Thierry
>
>
> I suggest that orgaggregate leaves such fields empty instead of "NA".
> This way the user gets a choice how to deal with them by adding e. g.
> EN or not as TBLFM format specifier:
>
> | Translator | sum(Chars) | sum(Lines) |
> |-
Hi Thierry
On Sun, Dec 7, 2014 at 10:20 AM, Thierry Banel wrote:
> Le 07/12/2014 04:25, Eric Abrahamsen a écrit :
>> [...]
>> (sum(prod($2 0.7) prod($3 10))
>>
>> Where $2 and $3 refer to cells in the aggregated table.
>
> It would be great of course. However I don't know how to do that
> cleanly
Hi Thierry
On Sun, Dec 7, 2014 at 4:25 AM, Eric Abrahamsen wrote:
> Thierry Banel writes:
>> [...]
>> #+BEGIN: aggregate :table "work" :cols "Translator sum(Chars) sum(Lines)"
>> | Translator | sum(Chars) | sum(Lines) |
>>
>> |-++|
>> | Austin
Le 07/12/2014 04:25, Eric Abrahamsen a écrit :
>
> Okay, having fun! This seems like exactly what I was after. A couple of
> things:
>
> I've attached a patch replacing some [a-z] regexps with [:word:], so
> that column names can be written in scripts other than ascii (my tables
> above are actuall
Thierry Banel writes:
> To elaborate on Michael's first suggestion,
> we will first give a name ("work") to the table:
>
> #+TBLNAME: work
> | Chars | Lines | Translator |
>
> |---+---+-|
> | |84 | Austin Woerner |
> | 6633 | | Eric Abraham
Thierry Banel writes:
> To elaborate on Michael's first suggestion,
> we will first give a name ("work") to the table:
>
> #+TBLNAME: work
> | Chars | Lines | Translator |
>
> |---+---+-|
> | |84 | Austin Woerner |
> | 6633 | | Eric Abraham
To elaborate on Michael's first suggestion,
we will first give a name ("work") to the table:
#+TBLNAME: work
| Chars | Lines | Translator |
|---+---+-|
| |84 | Austin Woerner |
| 6633 | | Eric Abrahamsen |
| 16984 | | Canaan Morse
Michael Brand writes:
> Hi Eric
>
> On Sat, Dec 6, 2014 at 6:42 AM, Eric Abrahamsen
> wrote:
>> #+NAME: counts
>> | Piece | Chars | Lines | Translator |
>> +++---+--+
>> | 凤凰 ||84 | Austin Woerner |
>> | 王血
Hi Eric
On Sat, Dec 6, 2014 at 6:42 AM, Eric Abrahamsen wrote:
> #+NAME: counts
> | Piece | Chars | Lines | Translator |
> +++---+--+
> | 凤凰 ||84 | Austin Woerner |
> | 王血 | 6633 | | Eric Abraham
Aloha Eric,
One approach would normalize the =counts= table= and use a SQL query to
generate the payments table.
#+name: counts
| id | Piece | N| Unit | Translator |
| 1 | foo | 84 | line | bar|
| 2 | baz | 6633 | char | foobar |
The query would sum over =N= conditional o
I never seem to use the spreadsheet unless it's some horribly
complicated thing I don't know how to calculate... Can someone lend me a
hand?
I'm calculating payment rates for contributors (actually translators) to
a magazine.
I've got two tables: The first is essentially a table of contents,
list
34 matches
Mail list logo
