Why not FP for Money?

[Carlos Ribeiro]

On Sat, 25 Sep 2004 18:30:36 GMT, Andrew Dalke <adalke at mindspring.com> wrote:
> Carlos Ribeiro wrote:
> > Why not? It may be a good idea for Py3k -- instead of raw strings, why
> > not regular expressions strings?
> [......]
> Interestingly enough I happen to have a regexp engine
> I wrote which allows addition on evaluated patterns.
> It works by merging the parse trees.

I don't have enough knowledge of RE's theory, and I don't know if it
can be generalized, but it's a great solution. Was it ever discussed
here at c.l.py?

> It's very useful for building large patterns because
> 
> (?P<AC_block>(?P<AC>AC
> (?P<bioformat:dbid?type=accession&dbname=sp>(?P<ac_number>[\dA-Z_a-z]+))\;(
> (?P<bioformat:dbid?type=accession>(?P<ac_number>[\dA-Z_a-z]+))\;)*(\n|\r\n?))+)
> 
> is harder to write by hand than
> 
> AC = Group("AC",
>             Str("AC   ") +
>             Std.dbid(Martel.Word("ac_number"),
>                     {"type": "accession",
>                      "dbname": "sp"}) + \
>             Str(";") +
>             Rep(Martel.Str(" ") +
>                 Std.dbid(Martel.Word("ac_number"),
>                          {"type": "accession"}) +
>                 Str(";")) +
>             Martel.AnyEol())
> 
> AC_block = Group("AC_block", Martel.Rep1(AC))
> 
> (Even with MULTILINE, re.compile doesn't tell you the
> character position of the syntax error as well as
> Python does, nor does my editor help me out.)

Although I said that I found it neat, I really think both forms above
are hard enough to write by hand to make me flee in despair :-) But I
see your point.

> > Because the call-style syntax requires the use of a string as an
> > argument to avoid practical and phylosophical problems involving the
> > conversion of binary floats to decimal floats, and the string looks
> > out of place in numeric expressions.
> 
> That argument makes much more sense to me than saying
> that using 'd' is a compromise to having no way to write
> it as a literal.

Well, I hadn't really expressed myself well with regards to the
'compromise'. Sorry about that. A compromise is not an argument per se
-- it must be backed by facts, and the compromise must only be sought
if there's need to acommodate contraditory needs. It's not the case
here.

> Complex is rarely used, I agree.  I just read through
> the original discussion on adding complex to Python.
> The thread was titled "Should I add complex numbers to
> the Python code?" starting Dec. 10, 1995.
>
> [ LOTS OF REALLY RELEVANT INFORMATION!]

Well, that's was the greatest part of your post. That you've got
yourself into the hassle of checking a discussion nearly ten years old
was fantastic, and the quality of the information you've recovered is
nothing short of magnificent. Really. So much of superlatives :-)

Looking back at that discussion, I think that we're on the right road.
We already have a library working, and the proposed changes to the
syntax follow the same precedent of the i(maginary) suffix. It's too
early to tell, but the precendents looks good for the 'd'-suffix
proposal.

> An interesting point, made by Paul Dubois, is that
>  > Expressions like those shown never occur in real
>  > life. In fact, complex literals are RARE. Usually
>  > complex numbers occur as the output of a function,
>  > and usually in arrays (often, BIG arrays).  So in
>  > fact this issue is not very important.
> 
> Is the same true for decimal?

There is an important difference in favor of complex numbers. I think
that the support for the notation of complex numbers is more important
for OUTPUT than for INPUT. It's much easier to read a complex as
(1+2i) than to read it as complex(1,2). In large array printouts,
that's something that makes a lot of difference.

As far as decimals are concerned, their 'repr' would probably keep the
'd' suffix, to allow for reverse evaluation. But the string
representation would certainly miss the 'd' suffix. In this case, the
notation is clearly more useful for INPUT than for OUTPUT.
 
> BTW, at this time I was a ready of c.l.py but not
> an active user.  I didn't post to the thread.  I
> wanted complex because, well, I am a "retread
> physicist."  But I've never actually used complex
> for any of my Python work and suspect that I
> wouldn't have a problem using (say)
>    cmath.complex(1.12, 2.9)
> instead if I did.

But you sure find it more convenient to type (1.12+2.9i), don't you?

Best regards,

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com