fuzzy logic

Anyone up for trying to see if this thing can be adapted for KSpread?

http://www.openfuzzymath.org/
--

-- 
Thomas Zander

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

vision

I read this paper and went from recognizing the thoughts I formulated myself 
as well, to more of a "that would be great!" and back again :)
In many places this blog from Rob tells of features that are impossible with 
most software, but will be possible with KOffice2.

More importantly, I think we'll see a lot of this coming true ;)

Enjoy!

http://www.robweir.com/blog/2006/08/tale-of-two-formats.html
--

-- 
Thomas Zander

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

Re: Extra font scaling? (Re: koffice/kspread)

On Tuesday 16 January 2007 21:01:47 Thomas Zander wrote:
> If I'm correct then the solution is to have all QFont and QFontMetrics
> constructors use a special PaintDevice.
> I'll move it from KoText to flake. It will probably be called
> KoPostscriptPaintDevice
>
> Hope that helps.

You are right. Just for the sake of completion: You have to construct the 
fonts with a paintdevice defining it's own metric and have to use QTextLayout 
to draw the text.
If you just reimplement the widget's metric method, it does not work - neither 
by QPainter::drawText nor by QTextLayout. Simon Hausmann told me, that it's a 
drawback when using the double buffered widget painting (default).
Attached is a small sample program, that shows what I've meant and how to 
achieve, that the font is only scaled once.

Regards,
Stefan

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

Re: fuzzy logic

2007/2/2, Thomas Zander <zander <at> kde.org>:
> Anyone up for trying to see if this thing can be adapted for KSpread?
> http://www.openfuzzymath.org/

Just had a look. It seems to be a combination of Java classes and
OOBasic macros, so the only way of adapting that would be a rewrite
using their ideas and algorithms.

The whole thing, from how I've seen it, is a rather ugly hack though -
OO.org apparently has no way of defining new datatypes for formulas
(we don't have any either, although I'm hoping to change that), so
this thing seems to be working by installing some sort of OOBasic
handler that gets executed whenever a cell changes, and it looks into
the cell formula if it contains a call to some meta-formulas such as
FUZZYFORMULA() - if so, it passes the text to the java module, which
parses everything within and returns some approximation of the fuzzy
number, while keeping the real value in some internal storage or
something ...

If we want something like this to be possible as a KSpread plug-in,
this likely wouldn't be the best way to go - allowing custom datatypes
would be much more flexible. It's one of the things that I have on my
"when I have time" list.

Currently, we have classes like ValueConverter or ValueFormatter,
which do their job perfectly, but aren't extensible for new datatypes.

/ Tomas

Re: fuzzy logic

On Saturday 03 February 2007 14:37, Tomas Mecir wrote:
> 2007/2/2, Thomas Zander <zander <at> kde.org>:
> > Anyone up for trying to see if this thing can be adapted for KSpread?
> > http://www.openfuzzymath.org/
>
> Just had a look. It seems to be a combination of Java classes and
> OOBasic macros, so the only way of adapting that would be a rewrite
> using their ideas and algorithms.

This is one of the reasons why I think that a kross java 'module' is a good 
thing.  Reinventing existing code is not really a nice thing to do :)

--

-- 
Thomas Zander

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

Re: fuzzy logic

I've had a look. It seems to me that their fuzzy numbers are just a 
special kind of measures (as in measure theory in math) on the real 
numbers. IMHO, their framework is too limited to be really useful. It 
doesn't seem to allow gaussian (as in exp(-x^2)) or dirac measures, which 
are the most common measures one'll have to deal with. It will thus force 
replacing them with approximations, which will not only be unreliable but 
also more computational-intensive.

In short, it's either too little (for real scientific work) or too much 
(if one doesn't need good reliability, then one doesn't need to mess with 
that anyway).

If one wants to be serious with that kind of things, it would be better to 
make a framework that includes enough of measure-theory to encompass 
probability theory (recall that measure-theory and probability-theory as 
just the same thing) because that might have many useful applications.

Benoit

On Sat, 3 Feb 2007, Thomas Zander wrote:

> On Saturday 03 February 2007 14:37, Tomas Mecir wrote:
>> 2007/2/2, Thomas Zander <zander <at> kde.org>:
>>> Anyone up for trying to see if this thing can be adapted for KSpread?
>>> http://www.openfuzzymath.org/
>>
>> Just had a look. It seems to be a combination of Java classes and
>> OOBasic macros, so the only way of adapting that would be a rewrite
>> using their ideas and algorithms.

Re: koffice/kword/plugins/scripting

On Saturday 03 February 2007 23:11, Sebastian Sauer wrote:
> SVN commit 629851 by sebsauer:
>
> doc says createVariable can return NULL.

Reading your usage, I see my docs and implementation of the manager can be 
improved :)

Its concepts are highly confusing, I admit.

The variable manager manages 2 things;
the name/value pairs. (which are just QStrings)
and the KoVariable instances that _have_ to be inserted into a text document 
to have any use.
Your code here doesn't use the KoVariable instance, and thus the call 
to 'createVariable' is not the correct one.  Just a manager.setValue() would 
be enough.

>  M  +3 -3      TextDocument.h
>
>
> --- trunk/koffice/kword/plugins/scripting/TextDocument.h #629850:629851
>  <at>  <at>  -118,9 +118,9  <at>  <at> 
>              /** Add a new variable. */
>              bool addVariable(const QString& variablename, const QString&
> value) { KoVariableManager* manager = variableManager();
> -                if( ! manager ) return false;
> -                KoVariable* v = manager->createVariable(variablename);
> -                v->setValue(value);
> +                KoVariable* variable = manager ?

Status on showstopper for 1.6.2

Hey,

I had like to know the status of showstoppers for the release of 1.6.2 
(tagging is currently due for the middle of this week).

--

-- 
Cyrille Berger

Re: Status on showstopper for 1.6.2

On Sunday 04 February 2007, Cyrille Berger wrote:
> Hey,
>
> I had like to know the status of showstoppers for the release of 1.6.2
> (tagging is currently due for the middle of this week).

Did Casper fix the rotate-selections-at-non-straight-angles bug?

--

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi

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

an ODF adoption story

This email came into the ODF-discussion mailinglist from the ODFoundation.

It points out the things that this company needs, but naturally focussus on 
what OOo can't currently supply.
Lets learn from that :)
-- 
Thomas Zander

From: Damon Anderson <damon <at> corigo.com>
Subject: [odf-discuss] ODF vs OXML
Date: 2007-02-06 02:47:30 GMT

At my company we have been making every effort to get out of MS and into  
ODF (which in our case has meant OOo). We have good success replacing MS  
Word, though several of the most basic and common functions we are used to  
using can be extremely complex and time consuming in OOo (due to extremely  
complex or un-intuitive keyboard shortcuts or OOo extreme over dependency  
on opening the entire properties window for a group of characters,  
paragraph, etc.).

Draw is even getting fairly heavy use as we have discovered that we can  
use page or screen captures with links in a Draw document and out put it  
to a PDF and create "3D" documentation where the Draw PDF becomes the  
"Site Map" to the related specification documents. Again there are obvious  
flaws in Draw... (templates are terrible but we would really like to