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

List:       koffice-devel
Subject:    Re: KNumber-Library
From:       Ariya Hidayat <ariya () kde ! org>
Date:       2005-08-22 11:51:30
Message-ID: 63316242 () web ! de
[Download RAW message or body]




> Ok, this is now hard. Of course, first this is an ego-problem.  After
> having almost finished my own library, it is difficult to judge something
> objectively, and then decide to throw my own stuff away.

Perhaps my mistake also because I did not spread the words after SpeedCrunch 
was released. I bet Michael was aware only becase we have 
competing^H^H^H^H^H^H^H^H^Hsimilar calculator :-)

> Soon there will be the kde-3.5 release. Exchanging now my whole
> Knumber-library with yours would be too much work in too little time.
> So for now, things have to continue like they are.

Personally I do not think you need to dump KNumber. As long as it does the job, 
then keep it that way.

> After the release one should definitely join the two projects. It does not
> make any sense to develop more or less the same thing completely
> independently. The question is of course, how this "unification" can
> happen: from completely throwing away one of the two to taking bits of
> both and combining.
> 
> I only had a brief look at your library, and I will tell you what I think
> about it:

Basically, HNumber was developed based on few rationales:

- Users typically do not need an extremely high-precision for simple desktop
calculator. If they do, then they should go after a specialized tool for that
(it's plain wrong to compute your home-made satellite's orbital speed using 
simple calculator). So, "high enough" will (hopefully) satisfy 99% of the 
demand of normal use.

- For such "high-precision-enough" routines, it would be overkilled to 
include/depend on GNU MP and MPFR.

- Precision problem can be solved by storing a more precise representation 
number than displayed. Of course this does not get rid of the problem 
(e.g. errors still propagate), but again if the users need that kind of 
computation, then this class/program is not the right tool.

- To prevent stupid bugs which cause severe calculation mistakes, simple 
automatic test framework is included. 

The disadvantages are:
- it is slow, just like GNU bc
- does not support very large number

Hopefully by using MPAM instead of GNU bc routines, I may get rid of these 
two.


As for joining forces after 3.5, of course I will support this (I'm sure 
Michael will, too). However, we must then define the goal of this 
high-precision library. Like I write above, if it is only for a desktop 
calculator and it needs to depend on few external libraries (GNU MP plus 
MPFR), IMHO that would be too much. On the other side, if it is intended 
to be used by other application as a wrapper for GNU MP, then that's fine. 
Some people perhaps may ask: what does GNU MP (dependency) have something to 
do with a desktop environment? But that's another story...


> > Klaus: did you get my e-mail about this before?
> 
> No... which one?

Well, about this stuff. Nevermind, since we discuss it now anyway.


--
Ariya Hidayat


PS: No need to cc me, I'm on koffice-devel.


______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

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