desktop-packages team mailing list archive

[Qubit <340051@xxxxxxxxxxxxxxxxxx>]

(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