ANN: Experimental Number Types (Integer, Rational, Floats)

[M.-A. Lemburg]

Moshe Zadka wrote:
> 
> On Wed, 25 Apr 2001 12:14:01 +0200, "M.-A. Lemburg" <mal at lemburg.com> wrote:
> 
> > Still, you have valid points here and I think Moshe should consider
> > these in his PEP (that's why I put him on CC -- hi Moshe ;-)
> 
> Thanks. I try to read c.l.py, but I sometimes miss out.
> I'll try to put some more words under "Open Issues". Basically,
> I'm not sure if I want to make the string matcher that complicated --
> also recognize "1.0 1/2"? "3/1 5/7"? "4/2 3/4" etc....

Actually, I would prefer if you'd just recognize "3" and "2/3"
(the "1 1/3" being an optinal extension) and "3.141" as short
for "3141/1000". 

Please don't mix rational notation with float notation or 
else people will get way to confused.

BTW, mxNumber 0.2.0 can parse all of the above except "3.141" -- 
that's in for the next release. You may also want to check out
the FareyRational() constructor which does something similar
to you .trim() method.

> And anyway, my PEP is behind the implementation -- this *will* be fixed,
> but anyone who is really interested in the future of my PEP should
> definitely checkout the implementation. Currently, the implementation
> recognizes these types strings --
> 
> 1. "105"
> 2. "105.7"
> 3. "105.7e1"
> 4. "105/7"
> 5. "105.7/8.3"
> 6. "105.7e1/8.3e-2"
> 
> In other words the implementation recognizes either a single "float" literal
> or two "float" literals seperated by a "/".
> Do you want me to put something like that
> 
> def rational(s)
>     if type(s) is type(''):
>         if ' ' in s:
>             nums = s.split(' ')
>             return reduce(operator.add, map(rational, nums))
>         ...
> 
> That's easy enough to implement....
> 
> I can also add:
> 
>         if '+' in s:
>             nums = s.split('+')
>             return reduce(operator.add, map(rational, nums))
> 
> That's also easy to implement....

No, no, no :-)
 
> Something which is sorely missing from my PEP, but I'm not into adding
> right now, is correct handling of Unicode. This is probably trickier
> then I think ;-)

That should be easy enough: there's a decimal encoder 
(PyUnicode_EncodeDecimal()) which converts Unicode numbers to
ASCII decimals. There should be no problem using e.g. circled
digits for number representation then (in case someone cares
for these ;-).

-- 
Marc-Andre Lemburg
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Pages:                           http://www.lemburg.com/python/