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

List:       koffice-devel
Subject:    Re: KSpread: Number class - some issues
From:       Stefan Nikolaus <stefan.nikolaus () kdemail ! net>
Date:       2007-05-28 13:32:50
Message-ID: 200705281532.52877.stefan.nikolaus () kdemail ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 28 May 2007 15:14:35 Tomas Mecir wrote:
> 2007/5/28, Stefan Nikolaus <stefan.nikolaus@kdemail.net>:
> > Hmm, the bit operation functions act directly on integers. At least for
> > these we gain some precision (qint64 vs. the 48 bit 'integer precision'
> > of double). There are probably more functions, that do the same, even
> > though I expect most of KSpread's functions to do their calculation using
> > double precision. So, the gain of keeping integer as distinct type is
> > minimal, but it does not hurt anyway (sizeof(qint64) = sizeof(double) =
> > 64 bit).
>
> Ah, these. Do they even work right, though ? I mean, even if you write
> an integer into some cell, it'll most likely (=if I recall correctly)
> get stored as a double anyway, so the bit functions would have
> problems. Guess I'll need to have a closer look at how these things
> work, and perhaps enforce integer usage where applicable.

Well, there's a special handling in ValueParser.cpp:310, but you're right: it 
truncates the 'integer precision' to 48 bit. Should be manageable to fix it, 
though.

> Would still 
> mean that your typedef Number double is going to have problems,
> because the integer that you were about to pass to the bitwise
> functions will be a double now.

No, these functions keeps using Value::asInteger() and everything's fine.

> And keeping integers in Value and abstracting -only- double into
> Number is not the way to go either, because then the whole benefits go
> up in smoke due to having to distinguish between integer and
> Number/double in each and every function, and that would be a bit
> "no-no" from me.

No, the benefits won't vanish. As I said, most functions use double precision 
for their calculations currently, and this behavior will stay. We will lose 
the higher 'integer precision', if we feed these functions with integer 
containing Values, because we simply use Value::asNumber(). But this will be 
the same behaviour as of now with Value::asDouble(), except that the values 
may be arbitrary precision values.

Regards,
Stefan

["signature.asc" (application/pgp-signature)]

_______________________________________________
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]