bug with numeral conversion function
It seems that there is a bug in converters.alphabetic function, converters.alphabetic(0,"arabic") returns the western 0 (no matter what is the selected language) while converters.alphabetic(1,"arabic") gives the Arabic 0 not 1 and so one i.e. it looks like as if it starts counting from zero. This has been reported few weeks ago, but I think it got missed. Regards, Khaled -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
On Sat, Aug 23, 2008 at 12:46:47AM +0300, Khaled Hosny wrote:
It seems that there is a bug in converters.alphabetic function, converters.alphabetic(0,"arabic") returns the western 0 (no matter what is the selected language) while converters.alphabetic(1,"arabic") gives the Arabic 0 not 1 and so one i.e. it looks like as if it starts counting from zero.
I finally got myself to understand some lua code. I think the problem is that lua tables start counting from 1 not 0, getting the value of key 0 from code table will give nil while 1 will give the value of 0 (first key), so the solution would be incrementing n by 1 in: local function do_alphabetic(n,max,chr) n = n + 1 -- to get the correct key if n > max then do_alphabetic(floor((n-1)/max),max,chr) n = (n-1)%max+1 end characters.flush(chr(n)) end This does work for the case of Arabic, but I don't know about others (especially greek and slovenian which look different) Now, I think I discovered another bug (or feature?), the function will ignore any zeros at the left which isn't what one expects. -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
On Mon, Sep 01, 2008 at 07:26:43PM +0200, Khaled Hosny wrote:
Now, I think I discovered another bug (or feature?), the function will ignore any zeros at the left which isn't what one expects.
This happen to be some thing in Lua itself: s = 000123 print(s) will give 123, so it have to be a string to keep the to the left zeros. I rewrote the converters.alphabetic() and converters.Alphabetic() so that it will not expect a number and will just iterate through the given string, and now \arabicnumerals and its brothers will pass strings to it. Also I found that \abjadnumerals were referring to converters.arabicnumerals witch doesn't exist, I changed it to converters.abjadnumerals but there is no converters.abjadnaivenumerals and I've no idea what it is supposed to do. See the attached patch and tell me what you think. -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
Khaled Hosny wrote:
On Sat, Aug 23, 2008 at 12:46:47AM +0300, Khaled Hosny wrote:
It seems that there is a bug in converters.alphabetic function, converters.alphabetic(0,"arabic") returns the western 0 (no matter what is the selected language) while converters.alphabetic(1,"arabic") gives the Arabic 0 not 1 and so one i.e. it looks like as if it starts counting from zero.
I finally got myself to understand some lua code.
I think the problem is that lua tables start counting from 1 not 0, getting the value of key 0 from code table will give nil while 1 will give the value of 0 (first key), so the solution would be incrementing n by 1 in:
local function do_alphabetic(n,max,chr) n = n + 1 -- to get the correct key if n > max then do_alphabetic(floor((n-1)/max),max,chr) n = (n-1)%max+1 end characters.flush(chr(n)) end
This does work for the case of Arabic, but I don't know about others (especially greek and slovenian which look different)
we cannot change that function without breaking other things there are several ways to convert, one is using the languages.counters table and i don't know if the arabic entries in it are right (i just found out that the greek vector is uppercase while it should be lowercase but i'll make a fix for that)
rgrep arabicn *.tex
core-con.tex 671: \defineconversion [arabicnumerals] [\arabicnumerals] core-con.tex 672: \defineconversion [persiannumerals] [\arabicnumerals]
rgrep arabicn *.mkiv
core-con.mkiv 20: \def\abjadnumerals #1{\ctxlua{converters.arabicnumerals(\number#1)}} core-con.mkiv 21: \def\abjadnodotnumerals #1{\ctxlua{converters.arabicnodotnumerals(\number#1)}} core-con.mkiv 22: \def\abjadnaivenumerals #1{\ctxlua{converters.arabicnaivenumerals(\number#1)}} core-con.mkiv 87: \def\arabicnumerals #1{\ctxlua{converters.alphabetic(\number#1,"arabic")}} core-con.mkiv 99: \defineconversion [arabicnumerals] [\arabicnumerals]
the abjad number converters are definied differently (based on specs by idris) so, if the 0/1 offset is a problem then we need to fix the tables, not the function (unless arabic follows a different logic, as chinese does) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Tue, Sep 02, 2008 at 08:25:38PM +0200, Hans Hagen wrote:
Khaled Hosny wrote: core-con.mkiv 20: \def\abjadnumerals #1{\ctxlua{converters.arabicnumerals(\number#1)}} core-con.mkiv 21: \def\abjadnodotnumerals #1{\ctxlua{converters.arabicnodotnumerals(\number#1)}} core-con.mkiv 22: \def\abjadnaivenumerals #1{\ctxlua{converters.arabicnaivenumerals(\number#1)}} core-con.mkiv 87: \def\arabicnumerals #1{\ctxlua{converters.alphabetic(\number#1,"arabic")}} core-con.mkiv 99: \defineconversion [arabicnumerals] [\arabicnumerals]
the abjad number converters are definied differently (based on specs by idris)
True, but in: \def\abjadnumerals#1{\ctxlua{converters.arabicnumerals(\number#1)}} There is actually no converters.arabicnumerals, only converters.abjadnumerals, so I think this is a typo.
so, if the 0/1 offset is a problem then we need to fix the tables, not the function (unless arabic follows a different logic, as chinese does)
That is OK as far as it works :) I was thrilled with how easy is lua and thought I'd try to write some code (like a kid playing with this new toy :p), and I don't think we have any special logic, it is essentially the same system with different numerals. Regards, Khaled -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
participants (2)
-
Hans Hagen -
Khaled Hosny