From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id uJLTIlb1jl8BTQAA0tVLHw (envelope-from ) for ; Tue, 20 Oct 2020 14:33:58 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id GGOdHlb1jl8XBwAA1q6Kng (envelope-from ) for ; Tue, 20 Oct 2020 14:33:58 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id EE249940223 for ; Tue, 20 Oct 2020 14:33:57 +0000 (UTC) Received: from localhost ([::1]:46300 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUsi4-0004eX-P6 for larch@yhetil.org; Tue, 20 Oct 2020 10:33:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUsgi-0004Zq-W8 for emacs-orgmode@gnu.org; Tue, 20 Oct 2020 10:32:33 -0400 Received: from grinta.net ([109.74.203.128]:45380) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUsga-0000e5-MD for emacs-orgmode@gnu.org; Tue, 20 Oct 2020 10:32:28 -0400 Received: from black.local (unknown [46.165.233.56]) (Authenticated sender: daniele) by grinta.net (Postfix) with ESMTPSA id 1A515E5B3C for ; Tue, 20 Oct 2020 14:32:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=2020; t=1603204341; bh=gPe5RQEELy9xvstGmwnu4iQ6FBl66SCXevsn3Hqm2+I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Mqf91sv3spvG4vz3LsVH5wA+3z9j1XQZekP5VXmYuCypd8IqD/TW/FxfV5gf9XcIe iSnMGPsKZT+SxQ0GZlFu9NbXZTmsj3TaCibu6Yftc8o/J+UFb7e7FxdJcR+SAl4Wto ov1cgTXNNtTLPtehWCXUpXS/hDcjWohWidCqW0hXFpWxA/JuZrPwyAViT9DshHKqYd QcXCKhs9NIrBfI15tTuYuBrDNNt0l0P4VbaY//PJ0nCkAlIkvruSSPg15Q6DuRXnSJ 6QqVtX9C2HNxaKm1B65mcIn0t3UFION9iDwjN3htFod2gm0ntX6MLjsgZuyGZzUlOP GmXaNZ0DwxfkQ== Subject: Re: [PATCH] org-table: Add mode flag to enable Calc units simplification mode To: emacs-orgmode@gnu.org References: <6d8c15c2-d1b0-d913-df39-c60381cff70b@grinta.net> <33143b05-a298-8277-313b-3a1deb69ad27@grinta.net> <87pn5dui49.fsf@ucl.ac.uk> <87lfg1ught.fsf@disroot.org> From: Daniele Nicolodi Message-ID: Date: Tue, 20 Oct 2020 16:32:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <87lfg1ught.fsf@disroot.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=109.74.203.128; envelope-from=daniele@grinta.net; helo=grinta.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/20 09:30:02 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=grinta.net header.s=2020 header.b=Mqf91sv3; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.01 X-TUID: YNnZ7kHM+ryw On 20/10/2020 16:19, Eric S Fraga wrote: > Hello again, > > Following up on myself. I'm seeing some strange behaviour although unit > calculations are working nicely. For instance, this table: > > #+begin_src org > | stream | a | b | c | total | x_a | x_b | x_c | > | | | | | | | | | > |----------+--------------+--------------+--------------+--------------+-------+-------+-------| > | feed | 1.05 mol/s | 1.05 mol/s | | 2.10 mol / s | 0.500 | 0.500 | 0 | > | effluent | 0.74 mol / s | 0.74 mol / s | 0.32 mol / s | 1.80 mol / s | 0.411 | 0.411 | 0.178 | > ,#+TBLFM: $5=vsum($2..$4);uf2::$6=$2/$5;uf3::$7=$3/$5;uf3::$8=$4/$5;uf3::@4$2=(1-0.3)*@-1;uf2::@4$3=(1-0.3)*@-1;uf2::@4$4=@-1+0.3*@-1$-1;uf2 > #+end_src > > does not seem to pay attention to the f3 mode in the last column, first > data row. It is something related to how Calc computes the result. The f2 mode specifies the formatting for floating point values, however it seems that Calc treats the zero (from the missing value in the fourth column) divided by a float (from the value in the fifth column) as an integer and not as a float. This may be because the org substitutes a "0" for the missing value, thus an integer. Still, I am not sure dividing an integer by a float should result in an integer (I guess zero is special cased here). If you change the formula for that field to: #+TBLFM: $8=$4*1.0/$5;uf3 to force the $4 field to be evaluated as a float (there are other ways to get the same effect) you get the expected result (I think). > I've also seen some (difficult to replicate) problem with column widths > where the columns are much wider than the expected. I'll keep playing > to see if I can isolate the column width behaviour. I haven't touched any code dealing with columns width (I believe). Cheers, Dan