(In reply to Christopher M. Penalver from comment #14) > Unfortunately, NEW is not an available Status
NEW makes sense if it's possible/likely to get fixed. My guess is that most Calc devs are going to punt on it, at best. > UNCONFIRMED doesn't apply I don't like to see bugs sitting in UNCONFIRMED permanently, but I haven't seen the case made for this bug yet. It's unclear to me that (aside from docs) there is some code to write here. > as it's more than confirmed up and downstream, so it's REOPENED. REOPENED is a very specific state that covers bugs that have been patched/marked as FIXED by a dev, and then have been reopened because the fix didn't work or was incomplete. That's not the case here. > I'm fine with this remaining open as a lowest priority enhancement request, > given the scope of this report is narrow and well defined, in that it's not > increase precision on everything, but an Excel calcuation parity request in > a well defined case as noted in the Description, and downstream. As Markus noted, this is a pretty small component of compatibility. We're not talking about the difference between, say, 10k and 500k rows, we're talking about some nuances of floating-point math when operating on HUGE (or incredibly *small*) numbers. > As well, this not being a high priority issue is both expected and > understandable. However, being able to seemlessly exchange documents between > colleagues using Excel, without the hassle of having to WORKAROUND > compatibility issues would be fair here. Especially in light of how > compatibility is a focus of the project -> > http://www.libreoffice.org/discover/libreoffice/ : > "LibreOffice is compatible with many document formats such as Microsoft® > Word, Excel..." LibreOffice and MS-Office will never be 100% perfectly compatible. Things like 'seamless' compatibility will be difficult when there are fonts that ship with MS-Office that we aren't legally allowed to distribute, let alone nuances in the implementation of floating-point arithmetic ;-) If you're looking for precision regarding big or small number arithmetic like this, I think that something like Sage or Octave would be an appropriate software package to use. > Despite this, I've placed myself as the QA contact if you would have further > questions on the scope of this report. Making yourself the QA Contact is great, but I remain skeptical that any dev will pick this up. In fact, Markus explained the problem pretty well: ---- The only solution would be to use exact numbers instad of floating point numbers, but this will have even bigger performance impact. ---- It's pretty clear to me that Markus doesn't think that we should trade performance for increased decimal place precision, and I'm inclined to trust his judgment. I still think this bug should be marked as a dupe and become a documented limitation of LO. Question: What's you goal here? Do you want to match the behavior of Excel, or just increase the precision of these calculations? The former seems more doable than the latter. (please change status back to 'UNCONFIRMED' after you leave a comment) Status -> NEEDINFO -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/340051 Title: [upstream] Calc precision error subtracting 3 integers Status in LibreOffice Productivity Suite: Confirmed Status in The OpenOffice.org Suite: In Progress Status in “libreoffice” package in Ubuntu: Triaged Status in “openoffice.org” package in Ubuntu: Won't Fix Bug description: Binary package hint: openoffice.org 1) lsb_release -rd Description: Ubuntu 11.04 Release: 11.04 2) apt-cache policy libreoffice-calc libreoffice-calc: Installed: 1:3.3.2-1ubuntu5 Candidate: 1:3.3.2-1ubuntu5 Version table: *** 1:3.3.2-1ubuntu5 0 500 http://us.archive.ubuntu.com/ubuntu/ natty-updates/main i386 Packages 100 /var/lib/dpkg/status 1:3.3.2-1ubuntu4 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages 3) What is expected to happen in LibreOffice Calc via the Terminal: cd ~/Desktop && wget https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/340051/+attachment/486207/+files/openoffice.summation.bug.ods && localc openoffice.summation.bug.ods is that cell A1=806515533049393 cell B1=1 cell C1=806515533049393 and cell D1=A1-B1-C1=-1. 4) What happens instead is cell D1 is 0. WORKAROUND: Use Gnumeric. apt-cache policy gnumeric gnumeric: Installed: 1.10.13-1ubuntu1 Candidate: 1.10.13-1ubuntu1 Version table: *** 1.10.13-1ubuntu1 0 500 http://us.archive.ubuntu.com/ubuntu/ natty/universe i386 Packages 100 /var/lib/dpkg/status WORKAROUND: If the contents of B1 and C1 are swapped, the correct answer of -1 is given. Original Reporter comments: OpenOffice 2.4.1 on x86 Ubuntu 8.10 Intrepid Ibex. This error did not occur when performing the same numerical calculation in the bash shell: echo $((a-1-a)). ProblemType: Bug Architecture: i386 DistroRelease: Ubuntu 8.10 NonfreeKernelModules: nvidia Package: openoffice.org-core 1:2.4.1-11ubuntu2.1 ProcEnviron: PATH=/usr/lib/openoffice/program:/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/real/RealPlayer LANG=en_CA.UTF-8 SHELL=/bin/bash SourcePackage: openoffice.org Uname: Linux 2.6.27-11-generic i686 To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/340051/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
