Re: [O] comma as decimal point: bug?
Hi Bastien, hi Nicolas, 2012/8/26 Bastien b...@altern.org: But I guess it's confusing to align numbers as if they were numbers, and to then tell the users well, they are not really numbers. I myself indeed was confused, but now that I know it only concerns aligning of numbers I have no problem living with it. I had be surprised by the supposed change, anyway, because Bastien (I think) in earlier versions of the manual had most definitely excluded to allow commas to be used as decimal points. I am not a programmer and are probably unaware of the problems coming up when allowing both dots and commas to be used as decimal points. As a user, I can say it would be an advantage when exporting org-files to LaTeX or ODT etc. Many thanks again and best wishes Rainer -- Prof. Dr. Rainer Thiel Institut für Altertumswissenschaften 07737 Jena, Germany (EU) r.th...@uni-jena.de
Re: [O] comma as decimal point: bug?
Am Montag, 27. August 2012, 11:08:59 schrieb Rainer Thiel: ... As a user, I can say it would be an advantage when exporting org-files to LaTeX or ODT etc. Many thanks again and best wishes Rainer Exporting tables to LaTeX usually is not the last step, obviously you will compile the exported *.tex file into a *.pdf. Right? So stick to a dot as the decimal point in *.org and in *.tex, but use the numprint package to get a table in your *.pdf with commas as decimal points. We had that discussion here and William Henney gave an example in an email dated 22 April 2012. Regards, Alexander
Re: [O] comma as decimal point: bug?
* Nicolas Goaziou n.goaz...@gmail.com wrote: Rainer Thiel r.th...@uni-jena.de writes: I have seen that as of v. 7.9, org tables are supposed to accept commas as decimal points which is useful if you set up tables to be used in in files where continental conventions are expected to be followed. Actually, this more subtle. Tables recognize numbers with a comma as the decimal mark. But it only means such numbers will be properly aligned to the right. Internally, calculations still require dot separator. When I read the change-list of Org, I bet that there *will* be problems because of this cosmetic change :-) From user experience perspective, it is quite clear that «Org recognizes numbers with commas» will be mixed up with «Org can calculate with numbers containing commas». You can not make this clear - even with renaming the settings variable. Although I totally understand that numbers with commas should be made possible (I am a German speaking guy) I guess there will be even more issues in the future as long as cosmetics and functionality is not aligned. Just my 2 cents ... -- Karl Voit
Re: [O] comma as decimal point: bug?
Karl Voit devn...@karl-voit.at wrote: * Nicolas Goaziou n.goaz...@gmail.com wrote: Rainer Thiel r.th...@uni-jena.de writes: I have seen that as of v. 7.9, org tables are supposed to accept commas as decimal points which is useful if you set up tables to be used in in files where continental conventions are expected to be followed. Actually, this more subtle. Tables recognize numbers with a comma as the decimal mark. But it only means such numbers will be properly aligned to the right. Internally, calculations still require dot separator. When I read the change-list of Org, I bet that there *will* be problems because of this cosmetic change :-) From user experience perspective, it is quite clear that «Org recognizes numbers with commas» will be mixed up with «Org can calculate with numbers containing commas». You can not make this clear - even with renaming the settings variable. Although I totally understand that numbers with commas should be made possible (I am a German speaking guy) I guess there will be even more issues in the future as long as cosmetics and functionality is not aligned. Agreed, but IIUC the main problem is that org depends on calc for the calculations and calc is firmly in the decimal point MUST be a period camp. So the cosmetics/functionality alignment would involve surgery on calc, something that nobody should undertake lightly - if at all :-). I believe the above statement is correct but if anybody has better information, please correct me. Nick
Re: [O] comma as decimal point: bug?
* Nick Dokos nicholas.do...@hp.com wrote: Karl Voit devn...@karl-voit.at wrote: Although I totally understand that numbers with commas should be made possible (I am a German speaking guy) I guess there will be even more issues in the future as long as cosmetics and functionality is not aligned. Agreed, but IIUC the main problem is that org depends on calc for the calculations and calc is firmly in the decimal point MUST be a period camp. Although I do not have much clue about «calc» I already assumed this is the case. So the cosmetics/functionality alignment would involve surgery on calc, something that nobody should undertake lightly - if at all :-). Totally agree. The point is: new users and users that does not start reading documentation before usage will not know this. And all I want to mention is that although I myself (now) understand the reasons, I also understand that (new) users will keep on misunderstand this issue until the cosmetics is aligned with the functionality of »calc«. This results in lot of traffic on this list with bug-reports on this. To avoid this, normal users should not get the alignment per default without having to read the explanation of the whole story. This is a trade-off. -- Karl Voit
Re: [O] comma as decimal point: bug?
Hi all, instead of having the comma as a decimal mark in all the regexps offered by the customization interface of `org-table-number-regexp', I added the comma for a new choice, which has the most liberal definition for what is a number. Using this regexp as the default will confuse the users: if they see 4,3 is aligned as a number, they will expect it to be treated as a number. This is not the case for 3.5: even when such string is aligned as a number, the user can clearly see by herself that this cannot be part of an arithmetic operation. I think the new option offered solves this issue. Best, -- Bastien
Re: [O] comma as decimal point: bug?
Hi Rainer, Rainer Thiel r.th...@uni-jena.de writes: I have seen that as of v. 7.9, org tables are supposed to accept commas as decimal points which is useful if you set up tables to be used in in files where continental conventions are expected to be followed. But I cannot see this really works. Well, the change was purely cosmetic, accepting commas by default will just change the way the table is aligned. See this email by Nicolas: http://article.gmane.org/gmane.emacs.orgmode/59134 But I guess it's confusing to align numbers as if they were numbers, and to then tell the users well, they are not really numbers. I'm in favor of reverting this change and let the user change the variable if he wants. What do you - and Nicolas - think? -- Bastien
Re: [O] comma as decimal point: bug?
Hello, Rainer Thiel r.th...@uni-jena.de writes: I have seen that as of v. 7.9, org tables are supposed to accept commas as decimal points which is useful if you set up tables to be used in in files where continental conventions are expected to be followed. Actually, this more subtle. Tables recognize numbers with a comma as the decimal mark. But it only means such numbers will be properly aligned to the right. Internally, calculations still require dot separator. Hope it is clearer now. Regards, -- Nicolas Goaziou
Re: [O] comma as decimal point: bug?
Nicolas Goaziou n.goaz...@gmail.com writes: But it only means such numbers will be properly aligned to the right. Internally, calculations still require dot separator. Mhh.. but many users might expect the calculation to happen just because those strings are aligned as numbers. The name of the variable is somewhat confusing here. The default is a bit more rigid, but at least, it is not confusing, and the variable (possibly renamed) can still be edited. -- Bastien
Re: [O] comma as decimal point: bug?
Hello, Bastien b...@altern.org writes: Mhh.. but many users might expect the calculation to happen just because those strings are aligned as numbers. 3.5 will also be recognized and aligned as a number, but you can't expect calculations to happen on it either. Regards, -- Nicolas Goaziou
