[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: RFC: Arbitrary precision in KSpread ?
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-01-22 17:01:29
Message-ID: 200501221801.30169.nicolasg () snafu ! de
[Download RAW message or body]

On Saturday 22 January 2005 16:38, Tomas Mecir wrote:
> On Sat, 22 Jan 2005 16:26:07 +0100, Nicolas Goutte <nicolasg@snafu.de> 
wrote:
> > > If not, then how would we decide, whether a particular number should
> > > be GnuMP-ized or not  ? In the parser I mean...
> >
> > Not really sure either. At first I had the idea of something like
> > MP("3.14")
>
> Hm, maybe. Of course, it would be best if the arbitrary precision
> "just worked" But then, some numbers (like PI), just cannot be

Pi was just an example. :-)

> represented, no matter how high precision you have. Hrm. Maybe having
> an option somewhere in settings, that says, compute with precision X.

You will need to set the precision anyway for decimal numbers. Somebody might 
need only 20 or so digits, some might want 100, some might need 1000 digits 
(and would not care too much about computing time).

That is something that I forgot: I had also thought about having the two other 
kinds of numbers supported by GnuMP: integers and fractions, as they have no 
limits. (But perhaps that is really too much, especially the fractions, as it 
seems that they need to be always "normalitzed".)

> Then we could use doubles by default, and switch to MP upon request...

Yes, I suppose even that it should be selectable document by document (of 
course GnuMP would only be supported only if KSpread can find the GnuMP 
runtime library.)

>
> > > Ummm... what? Like, having extra functions for GnuMP-based
> > > computations? Not sure if this is a good idea... How would we tell
> > > KSpread that number A is to be represented using GnuMP, and number B
> > > is not?
> >
> > Well, you have strings, double... so you can have MP too.
>
> Sure, but I was thinking about the end-user's perspective... Maybe
> that option would be the best idea...
>
> > In the meantime, I have had the idea that you can try to use "long
> > double" to help testing your abstract class. You would not need an extra
> > library but you could test a switch between double and something else.
>
> Well, problem here is, that we wouldn't really test much, as the
> compiler can convert stuff double <-> long double ...

Sure may be yo cannot test everything then. But perhaps on the other side, it 
would permit you to better do the conversion step by step, while still be 
able to test. (I do not know if gcc is able to warn for such conversions.)

>
> > (Of course having complex numbers make it again different than OOo Calc,
> > but I suppose that this would be a very long term goal anyway. But
> > perhaps we should not close that door, if possible. (That is also
> > something that I thought about, last night.)
>
> Mmmm... Complex numbers might be interesting too... Heh, we may end up

By the way: if you want to test something in this direction, gcc support 
complex numbers.

> with KSpread being turned into some computer algebra system
> eventually... ;)

Some want this for KFormula. ;-)

>
> > > So, in short, it's all about whether having increased precision would
> > > be worth the slower execution...
> >
> > Perhaps you could make a little test application ,somewhere in one of
> > kdeplayground modules. (That is just an idea...)
>
> What test application ? Like, the parser separated from the rest ? Hmmm ...

Not sure! I thought more of using QTable and make a mini-spreadsheet. But I do 
not know what you need as code or what you would need to test more.

(I thought more of a proof of concept or something like that. But only if you 
need it.)

>

Have a nice day!

> / Tomas
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]