OOo2.4.2 takes of:=FDIST(a,b,c) as if it is ooc:=FDIST(a,b,c)

[Regina Henschel]

Hello all,

during my implementation of FDISTL I saw the following problems.

(1)
I generate a file with a formula =FDISTL(a,b,c) and store it in version
ODF1.2. Unzipping the file I find "of:=FDIST(a,b,c)", which is correct.

Now I open the file in OOo2.4.2. I get the version warning to upgrade.
(BTW, you get the warning only for first opening.) Then it opens and the
cell with "of:=FDIST(a,b,c)" is calculated with cell content
=FDIST(a,b,c) instead of showing a #NAME? error. This must not happen,
because =FDIST in OOo2.4.2 means the right tail, which is internally
"of:=LEGACY.FDIST". The user does not know, that the result is wrong.

Similar for the four parameter form. "of:=FDIST(a,b,c,d)" results in
cell content "=FDIST(a,b,c,d)". The user gets an Err:504 here, because
of the forth parameter.

If you now save the file in OOo2.4.2 and reopen it in OOo3.2, then the
original =fdistl() cell contents are not restored. We have data loss.

Is there any place in source of OOo3.2 where I can avoid that error? Or
can it only be solved in OOo2.4.x?

(2)
Another problem is the following scenario. Save in OOo3.2 with version
ODF1.0. Open in OOo3.1.1. In cells with content "=FDISTL()" you get
correctly content "=fdistl()" and #NAME? error, because this function is
unknown to OOo3.1.1. Now save the file in OOo3.1.1 with version ODF1.2.
and open it in OOo3.2. The cell content is shown as "=fdistl()", but the
now known function is not identified and the cells show a #NAME? error.
Unzipping the file you see a "of:=fdistl()", which small instead of
capital letters. Even a hard recalculate does not help.

Any solution for this?


kind regards
Regina


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Leonard Mada-2]

Dear Regina,

this brings me to an older issue:
http://www.openoffice.org/issues/show_bug.cgi?id=85328

It was suggested within that issue, that the cell was
formatted as text, although I would have expected
that anything starting with = is interpreted as
a formula, while strings get marked as: '=

I believe this is a more deeper problem within Calc
that needs to be addressed.

Sincerely,

Leonard Mada
--
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Eike Rathke-2]

Hi Regina,

On Saturday, 2009-07-04 14:53:45 +0200, Regina Henschel wrote:

> I generate a file with a formula =FDISTL(a,b,c) and store it in
> version ODF1.2. Unzipping the file I find "of:=FDIST(a,b,c)", which
> is correct.
>
> Now I open the file in OOo2.4.2. I get the version warning to
> upgrade. (BTW, you get the warning only for first opening.) Then it
> opens and the cell with "of:=FDIST(a,b,c)" is calculated with cell
> content =FDIST(a,b,c) instead of showing a #NAME? error. This must
> not happen, because =FDIST in OOo2.4.2 means the right tail, which
> is internally "of:=LEGACY.FDIST". The user does not know, that the
> result is wrong.

Ouch..

> Similar for the four parameter form. "of:=FDIST(a,b,c,d)" results in
> cell content "=FDIST(a,b,c,d)". The user gets an Err:504 here,
> because of the forth parameter.

Apart from the of:FDIST vs. oooc:FDIST problem this is just normal for
functions that get new parameters added. Features not understood by
older versions can't be correctly handled by them. If that results in an
error it's ok.

> If you now save the file in OOo2.4.2 and reopen it in OOo3.2, then
> the original =fdistl() cell contents are not restored. We have data
> loss.

"Content not restored"? What exactly is imported/displayed, and what is
missing? I assume it is imported as FDIST instead of FDISTL (UI names),
correct?

> Is there any place in source of OOo3.2 where I can avoid that error?
> Or can it only be solved in OOo2.4.x?

The erroneous handling of of:FDIST as oooc:FDIST in 2.4.2 could only be
fixed with a change in 2.x; however, a correct fix could only be to
either make 2.x not load 'of' namespace as formulas at all, or
completely implement handling of both namespaces, which would be quite
tough, partly the same I did for OOo3.0

An intermediate workaround to not make the function calculate wrong
results in 2.4.2 because of of:FDIST vs. oooc:FDIST could be to always
forcedly write the 4th parameter, such that 2.4.2 will return an error,
which is at least better than a wrong result. More nasty than nice, but ...

For the "contents not restored" I'd need more details. If it is the
function being imported as oooc:FDIST instead of of:FDIST, we might
trick the compiler into translating that to of:FDIST if the function has
4 parameters, given that we wrote always 4 parameters as mentioned
above. Again, more nasty than nice, but ...


> (2)
> Another problem is the following scenario. Save in OOo3.2 with
> version ODF1.0. Open in OOo3.1.1. In cells with content "=FDISTL()"
> you get correctly content "=fdistl()" and #NAME? error, because this
> function is unknown to OOo3.1.1. Now save the file in OOo3.1.1 with
> version ODF1.2. and open it in OOo3.2. The cell content is shown as
> "=fdistl()", but the now known function

It is not really known, because of:FDISTL doesn't exist.

> is not identified and the
> cells show a #NAME? error. Unzipping the file you see a
> "of:=fdistl()", which small instead of capital letters. Even a hard
> recalculate does not help.
>
> Any solution for this?

We could introduce an alias handling in the compiler and tie that to the
<meta:generator> element's value and accept the alias only for documents
created by versions OOo3.0 and OOo3.1

However, given all these quirks I'm hesitating to implement FDISTL at
the current stage, especially with regard to the OOo2.4.2 problems.

  Eike

--
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD

[Regina Henschel]

Hi Eike,

Eike Rathke schrieb:

> Hi Regina,
>
> On Saturday, 2009-07-04 14:53:45 +0200, Regina Henschel wrote:
>
>> I generate a file with a formula =FDISTL(a,b,c) and store it in
>> version ODF1.2. Unzipping the file I find "of:=FDIST(a,b,c)", which
>> is correct.
>>
>> Now I open the file in OOo2.4.2. I get the version warning to
>> upgrade. (BTW, you get the warning only for first opening.) Then it
>> opens and the cell with "of:=FDIST(a,b,c)" is calculated with cell
>> content =FDIST(a,b,c) instead of showing a #NAME? error. This must
>> not happen, because =FDIST in OOo2.4.2 means the right tail, which
>> is internally "of:=LEGACY.FDIST". The user does not know, that the
>> result is wrong.
>
> Ouch..

[..]

>
>> If you now save the file in OOo2.4.2 and reopen it in OOo3.2, then
>> the original =fdistl() cell contents are not restored. We have data
>> loss.
>
> "Content not restored"? What exactly is imported/displayed, and what is
> missing? I assume it is imported as FDIST instead of FDISTL (UI names),
> correct?

I know, that it cannot be restored, as the OOo2.4.2 has turned
of:=FDIST([.B3];[.B1];[.B2]) to oooc:=FDIST([.B3];[.B1];[.B2]) when
saving. I mentioned it as contrast to the problem exchanging documents
between OOo3.2 and OOo3.1.

>
>> Is there any place in source of OOo3.2 where I can avoid that error?
>> Or can it only be solved in OOo2.4.x?
>
> The erroneous handling of of:FDIST as oooc:FDIST in 2.4.2 could only be
> fixed with a change in 2.x; however, a correct fix could only be to
> either make 2.x not load 'of' namespace as formulas at all, or
> completely implement handling of both namespaces, which would be quite
> tough, partly the same I did for OOo3.0

I've feared that.

>
> An intermediate workaround to not make the function calculate wrong
> results in 2.4.2 because of of:FDIST vs. oooc:FDIST could be to always
> forcedly write the 4th parameter, such that 2.4.2 will return an error,
> which is at least better than a wrong result. More nasty than nice, but ...
>
> For the "contents not restored" I'd need more details. If it is the
> function being imported as oooc:FDIST instead of of:FDIST, we might
> trick the compiler into translating that to of:FDIST if the function has
> 4 parameters, given that we wrote always 4 parameters as mentioned
> above. Again, more nasty than nice, but ...

And not a really solution. The draft spec allows three parameters and a
OOo2.4.2 version can get a -in this way valid- document from third party.

>
>
>> (2)
>> Another problem is the following scenario. Save in OOo3.2 with
>> version ODF1.0. Open in OOo3.1.1. In cells with content "=FDISTL()"
>> you get correctly content "=fdistl()" and #NAME? error, because this
>> function is unknown to OOo3.1.1. Now save the file in OOo3.1.1 with
>> version ODF1.2. and open it in OOo3.2. The cell content is shown as
>> "=fdistl()", but the now known function
>
> It is not really known, because of:FDISTL doesn't exist.
>
>> is not identified and the
>> cells show a #NAME? error. Unzipping the file you see a
>> "of:=fdistl()", which small instead of capital letters. Even a hard
>> recalculate does not help.
>>
>> Any solution for this?
>
> We could introduce an alias handling in the compiler and tie that to the
> <meta:generator> element's value and accept the alias only for documents
> created by versions OOo3.0 and OOo3.1

The content.xml has the node

<table:table-cell table:style-name="science"
table:formula="of:=fdistl([.B3];[.B1];[.B2];1)"
office:value-type="float" office:value="0">
<text:p>#NAME?</text:p>
</table:table-cell>

So the table formula exists, besides being in lower case. Perhaps a
conversion is not needed in the way, that it is done automatically. As
long as the table:formula attribute is preserved with saving, I can also
image to implement a "repair"-command, that takes the table:formula
attribute and generates a valid formula from that and recalculate the
cell then.

I think, that a solution is necessary, because there will be similar
situations in future, that there are two versions, both working with
ODF1.2, where a newer version knows a function that the older does not know.

>
> However, given all these quirks I'm hesitating to implement FDISTL at
> the current stage, especially with regard to the OOo2.4.2 problems.

I agree, not to implement FDISTL with OOo3.2. I can send you the code
which contains the algorithms, so that you can keep it and the
algorithms get not lost. Do you want a patch or the complete
interpr3.cxx file?

I think, that the FDIST problem has to be solved in OASIS. For CHIDIST
it has been solved by introducing the new function name CHISQDIST. The
left tailed variant of the F-distribution needs a new name too. At least
it should not allow three parameters, so that application can notice the
change by counting the parameters. Do you take the problem to the committee?

kind regards
Regina

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Eike Rathke]

Hi Leonard,

On Saturday, 2009-07-04 19:53:56 +0200, Leonard Mada wrote:

> this brings me to an older issue:
> http://www.openoffice.org/issues/show_bug.cgi?id=85328

Which is completely unrelated to the problem we're talking about, you
hijacked the thread.

Input to a cell that is formatted as text is always treated as text and
never parsed as another data type or formula. This is on purpose, and
Excel does it the same. Usually used to pre-format cells and paste data
from the clipboard or enter text that otherwise would get parsed.

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[Eike Rathke]

Hi Regina,

On Monday, 2009-07-06 11:43:23 +0200, Regina Henschel wrote:

> I agree, not to implement FDISTL with OOo3.2. I can send you the code  
> which contains the algorithms, so that you can keep it and the  
> algorithms get not lost. Do you want a patch or the complete  
> interpr3.cxx file?

Patch please, so chances are that it can be applied in future.

> I think, that the FDIST problem has to be solved in OASIS.

Not necessarily.. it's no OASIS' fault that our implementation is as it
is.

> For CHIDIST it has been solved by introducing the new function name
> CHISQDIST.

Only because CHISQDIST is a more logical name for a function that does
some Chi Square computation.

> The  left tailed variant of the F-distribution needs a new name too.
> At least  it should not allow three parameters, so that application
> can notice the change by counting the parameters.

That wouldn't fit with the other functions that have the
distribution/cumulated boolean parameter all optional.

> Do you take the problem to the committee?

I can try, but no guarantee.

  Eike

--
 OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
 SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
 Please don't send personal mail to the erl@... account, which I use for
 mailing lists only and don't read from outside Sun. Use erack@... Thanks.

[Leonard Mada-2]

Dear Eike,

Clever answers need clever questions.

My concern with Regina's post was:

> (2)
> Another problem is the following scenario.
> Save in OOo3.2 with version  ODF1.0. Open in OOo3.1.1.
> In cells with content "=FDISTL()" you get  correctly content
> "=fdistl()" and #NAME? error, because this function is
> unknown to OOo3.1.1.
> Now save the file in OOo3.1.1 with version ODF1.2.
> and open it in OOo3.2. The cell content is shown as
> "=fdistl()", but the now known function is not identified
> and the cells show a #NAME? error.
> Unzipping the file you see a "of:=fdistl()", with small
> instead of capital letters. Even a hard recalculate does not help.

So, what was this problem?
It did resemble my problem.

Unfortunately, this issue and others bring me to unacceptable
shortcomings in Calc.

I will take exquisitely the time to detail a couple of issues,
time that I am less and less able to devote to OOo.
I will open a new thread to detail some of those issues,
suffice here to ask a question:


How can you quickly know if a number is a number
in a cell that was formatted as text?

And how can you know if a number entered as string
is a string, if a cell is formated as text?

Solving this latter issue is slightly easier to accomplish.
You need only 4 clicks (if you know which ones) to get the
information that answers the question. But question 1 does
not provide any feedback. Ff you do not know how OOo behaves,
the user is lost.

[Even older versions of Excel do answer these questions
 instantly.]

Sincerely,

Leonard



-------- Original-Nachricht --------
> Datum: Wed, 8 Jul 2009 18:46:02 +0200
> Von: Eike Rathke <erl@...>
> An: dev@...
> Betreff: [sc-dev] i85328 (was: [sc-dev] OOo2.4.2 takes of:=FDIST(a,b,c) as if it is ooc:=FDIST(a,b,c))

> Hi Leonard,
>
> On Saturday, 2009-07-04 19:53:56 +0200, Leonard Mada wrote:
>
> > this brings me to an older issue:
> > http://www.openoffice.org/issues/show_bug.cgi?id=85328
>
> Which is completely unrelated to the problem we're talking about, you
> hijacked the thread.
>
> Input to a cell that is formatted as text is always treated as text and
> never parsed as another data type or formula. This is on purpose, and
> Excel does it the same. Usually used to pre-format cells and paste data
> from the clipboard or enter text that otherwise would get parsed.
>
>   Eike
>
> --
>  OOo/SO Calc core developer. Number formatter stricken i18n
> transpositionizer.
>  SunSign   0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
>  OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
>  Please don't send personal mail to the erl@... account, which I use
> for
>  mailing lists only and don't read from outside Sun. Use erack@...
> Thanks.

--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...