Re: [sc-dev] Extending row/column selection in calc, easier with shift-arrow keys - issue 21869
Cor Nouws пишет: Kirill Palagin wrote (1-10-2008 19:16) at the moment we are missing convinient behavior - ability to extend row/column selection with the keyboard. Competing spreadsheet allows just that with Shift-arrows, Writer also has this feature. We have http://www.openoffice.org/issues/show_bug.cgi?id=21869 filed just for that. Please consider taking ownership of this RFE and implementing it in not-too-distant future. IMO there is a pretty good alternative available. pls see my comment in the issue, Yep, Ctrl-Space/Shift-Space works both in Calc and competing spreadsheet, but this is a lot less intuitive way of selecting column/row and it does not provide way to extend selection once it is made. It also is not consistent with Writer. Thus implementing 21869 would improve usability. WBR, KP. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Extending row/column selection in calc, easier with shift-arrow keys - issue 21869
Kirill Palagin wrote (1-10-2008 19:16) at the moment we are missing convinient behavior - ability to extend row/column selection with the keyboard. Competing spreadsheet allows just that with Shift-arrows, Writer also has this feature. We have http://www.openoffice.org/issues/show_bug.cgi?id=21869 filed just for that. Please consider taking ownership of this RFE and implementing it in not-too-distant future. IMO there is a pretty good alternative available. pls see my comment in the issue, Regards, Cor -- "The Year of 3" -2008- "Het jaar van 3" Cor Nouws - Arnhem - Netherlands > marketing contact - http://nl.OpenOffice.org > Zeker van OpenOffice.org - www.nouenoff.nl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Which category for GAMMA and GAMMALN?
Hi Eike, thanks for your answer. Next step to finish :) kind regards Regina Eike Rathke schrieb: Hi Regina, replying after vacation gap.. On Sunday, 2008-09-21 19:26:04 +0200, Regina Henschel wrote: GAMMALN is currently in Category 'Statistical'. But in OpenFormula-v1.2-draft9.odt (which is the most current) it is in chapter '6.15 Mathematical Functions'. GAMMA is an expansion of factorials to real numbers. Shall I (1) Put GAMMA into 'Statistical' too or (2) Put GAMMA into 'Mathematical' and leave GAMMALN unchanged or (3) PUT GAMMA and GAMMALN both into 'Mathematical'? (3) wouldn't be an option as long as we don't decide to reorganize the categorization, which David also mentioned. The current categorization lists functions for Excel compatibility, so people find the functions where they are used to. I think (1) would be best as all 4 GAMMA* functions would be grouped together, pointing the user to the existence of the new GAMMA function. Even if that would add to the "improper" categorization. Putting only GAMMA into Mathematical and leaving GAMMALN in Statistical could be somewhat confusing, I guess. Does the GAMMA function need a name in Resource RID_SC_FUNCTION_NAMES_ENGLISH? Yes, as those names are used to store in ODF <1.2 format. Also the XFunctionAccess API still uses them for compatibility. If yes, which name should be used? In general, where can I find which names are the correct ones for ODF v1? For new functions simply use the name as defined in ODFF. Older OOo versions not knowing a function wouldn't be able to compile and interpret the formula anyway. Eike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Regular Expressions in FIND()?
Hello David, Indeed, that did the trick. Thank you very much. There is NO mention in the Help that comes with OOo-m29 that FIND() does not search for regular expressions, and I was fairly convinced that it actually works. Moreover, I had the firm impression that the error lies within the negation ( [^something] ) and did not even check a simple regexp. The only trouble I have with the new formula is that the already ugly formula got another 4 chars wider (making at 20 formulas another 80 chars). I desperately hope that the #VALUE! error gets fixed. ;-) Sincerely, Leonard David King wrote: does Calc permit regular expressions in the FIND() function? I think FIND doesn't, SEARCH does http://wiki.services.openoffice.org/wiki/Documentation/How_Tos/Re gular_Expressions_in_Calc#Regular_expressions_in_Calc_functions David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[sc-dev] Extending row/column selection in calc, easier with shift-arrow keys - issue 21869
Dear developers, at the moment we are missing convinient behavior - ability to extend row/column selection with the keyboard. Competing spreadsheet allows just that with Shift-arrows, Writer also has this feature. We have http://www.openoffice.org/issues/show_bug.cgi?id=21869 filed just for that. Please consider taking ownership of this RFE and implementing it in not-too-distant future. Thanks a lot for your attention. With best regards, K. Palagin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] Which category for GAMMA and GAMMALN?
Hi Regina, replying after vacation gap.. On Sunday, 2008-09-21 19:26:04 +0200, Regina Henschel wrote: > GAMMALN is currently in Category 'Statistical'. But in > OpenFormula-v1.2-draft9.odt (which is the most current) it is in chapter > '6.15 Mathematical Functions'. GAMMA is an expansion of factorials to > real numbers. > > Shall I > (1) Put GAMMA into 'Statistical' too > or > (2) Put GAMMA into 'Mathematical' and leave GAMMALN unchanged > or > (3) PUT GAMMA and GAMMALN both into 'Mathematical'? (3) wouldn't be an option as long as we don't decide to reorganize the categorization, which David also mentioned. The current categorization lists functions for Excel compatibility, so people find the functions where they are used to. I think (1) would be best as all 4 GAMMA* functions would be grouped together, pointing the user to the existence of the new GAMMA function. Even if that would add to the "improper" categorization. Putting only GAMMA into Mathematical and leaving GAMMALN in Statistical could be somewhat confusing, I guess. > Does the GAMMA function need a name in Resource > RID_SC_FUNCTION_NAMES_ENGLISH? Yes, as those names are used to store in ODF <1.2 format. Also the XFunctionAccess API still uses them for compatibility. > If yes, which name should be used? In > general, where can I find which names are the correct ones for ODF v1? For new functions simply use the name as defined in ODFF. Older OOo versions not knowing a function wouldn't be able to compile and interpret the formula anyway. 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 [EMAIL PROTECTED] account, which I use for mailing lists only and don't read from outside Sun. Use [EMAIL PROTECTED] Thanks. pgpiFh6qB4mxT.pgp Description: PGP signature
Re: [sc-dev] How to handle ODFF constrain "number must be integer"?
Hi Niklas, Niklas Nebel schrieb: On 09/27/08 20:06, Regina Henschel wrote: In the ODFF draft spec of CHISQDIST is a constraint for the parameter 'degrees of freedom' to be integer. Shouldn't the argument type be "integer" instead? It seems to be an open ToDo, see remark at the end of part 6.2.5. Should I implement it: (1) break with an "illegal argument" error, if the value is not an integer or (2) round the value to an integer. The current implementation of the complement function CHIDIST rounds the incoming value, but the spec has the same constraint for LEGACY.CHIDIST. I would prefer version (2) to make it consistent with existing CHIDIST. And changing CHIDIST too, I consider to dangerous, because existing documents might no longer work. Yes, for the implementation, let's stay consistent with the other functions, that is, truncate (not round) the value. Current implementation of CHIDIST has ::rtl::math::approxFloor(GetDouble()); I'll copy it in that way in CHISQDIST in CHISQINV. The current implementations of CHIDIST and CHIINV have a constraint 'degrees of freedom < 1.0E5'. The spec don't have such restriction nor mention that they might be necessary. The code has no comment, why this constraint has been introduced. Can you tell me? Huge values might overflow oder underflow somewhere, but is that reason enough to reject them from the beginning? The old implementation (before issue 90703) looks like it couldn't handle large values. If you're confident that the current implementation is better, I think that constraint can be removed. When degrees of freedom is large and x-values is a little bit smaller than degrees of freedom, you get a "no convergence" error. When x-value is a little bit greater you get a value, but that is less accurate than for small values of degrees of freedom (but more accurate than the old implementation for largest possible values). That would be something to be mentioned in the Wiki. If x-value is not so near to degrees of freedom, you will get 0 or 1, which are correct values in that cases. So I see now reason, not to remove the constraint. kind regards Regina - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sc-dev] How to handle ODFF constrain "number must be integer"?
On 09/27/08 20:06, Regina Henschel wrote: In the ODFF draft spec of CHISQDIST is a constraint for the parameter 'degrees of freedom' to be integer. Shouldn't the argument type be "integer" instead? Should I implement it: (1) break with an "illegal argument" error, if the value is not an integer or (2) round the value to an integer. The current implementation of the complement function CHIDIST rounds the incoming value, but the spec has the same constraint for LEGACY.CHIDIST. I would prefer version (2) to make it consistent with existing CHIDIST. And changing CHIDIST too, I consider to dangerous, because existing documents might no longer work. Yes, for the implementation, let's stay consistent with the other functions, that is, truncate (not round) the value. The current implementations of CHIDIST and CHIINV have a constraint 'degrees of freedom < 1.0E5'. The spec don't have such restriction nor mention that they might be necessary. The code has no comment, why this constraint has been introduced. Can you tell me? Huge values might overflow oder underflow somewhere, but is that reason enough to reject them from the beginning? The old implementation (before issue 90703) looks like it couldn't handle large values. If you're confident that the current implementation is better, I think that constraint can be removed. Niklas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
