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

[David LeBlanc]

In article <mailman.988235501.26237.python-list at python.org>, 
mal at lemburg.com says...
> "Delaney, Timothy" wrote:
> > 
> > > > > The normal way to create a Rational is to write Rational(2, 3).
> > > > > The next release will also have a string parser for rational
> > > > > numbers (in the format "2/3" and probably "12 2/3" too).
> > > >                                              ^^^^^^
> > > >                                              ^^^^^^
> > > > Just a note:
> > > > This one is cultural and could generate lots of confusion.
> > > > The only way I can parse it is 12*2/3 (I'm French).
> > > > No French book (I know of) uses this notation: 38/3 or 12+2/3
> > > > is used instead. It's as if you wrote the complex number
> > > > 3+4j as "3 4j" (look: "3 4j + 4 5j * 1 7j", hmmm...).
> > >
> > > The notation is quite common in financial business and
> > > mathematics. I agree that it can be confusing, but since the
> > > parser will only accept a single rational in the string, I
> > > believe that at least when using Rational() this behaviour
> > > can be accepted. The situation is different for literals,
> > > of course...
> > 
> > Of course, we should probably aim for a notation which is consistent *now*.
> > 
> > 12 2/3 - ambguous across cultures.
> > 
> > 38/3   - not ambiguous, but falls into the problem of integer truncation.
> > Nevertheless, I would prefer this notation, and deprecate integer division
> > notation in favour of 'div' (since this would be a major incompatible
> > language change anyway, might as well make a new keyword at the same time
> > ;).
> 
> If rationals make it into the core some day, 38/3 might come out
> as rational, so there would not be any integer truncation. The truncation
> would happen when converting the rational to an integer.
>  
> > 12+2/3 - not ambiguous and valid if the above is valid (integer + rational),
> > I would probably want the compiler to start rolling literals together at
> > this point... otherwise there would be 2 runtime calculations going on
> > (division to form rational, then addition of integer).
> 
> As Alex already mentioned, complex numbers work this way already
> and so would rationals (this works today). What I was talking about
> is conversion of strings to rationals -- this is a somewhat different
> task than recognizing literals.
> 
> 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 ;-)
> 
> 
Looking at this from a broader perspective, in light of the move towards 
Unicode, isn't internationalization (i18n) and localization (l8n - L18n) 
going to become a more pervasive issue? From radix specifiers ("." US, 
"," European) to date formats and beyond, global acceptance of Python is 
going to be somewhat dependent on idioms familiar to a particular group 
IMHO.

fWIW, I've always seen complex numbers written as:
[0-9]+\.[0-9]*(e|E|f|F)?(i|j)[0-9]+.[0-9]*

examples of which are:

3.14j6 or 4i6.3 or 3.2e3j14 etc.

Dave LeBlanc