'complex' function with string argument.

[Mark H Harris]

On 3/17/14 11:52 PM, Steven D'Aprano wrote:
> On Mon, 17 Mar 2014 11:18:56 -0500, Mark H Harris wrote:
>>  Who knows, beats me.

> With respect, that's just because you would make a lousy language
> designer :-)

    Ouch    ;-)

> "How should one spell a complex number?" There is perfectly good syntax
> for complex numbers used by mathematicians and engineers for over a
> century. There is no need to invent something different just for the sake
> of being different:
>      Yes:   2+3i or 2+3j

    Yes.  my Q was rhetorical only. And for the sake of discussion, 
particularly on the part of the OP, to think about what one expects 
based on experience and common sense, as a mathematician. (that doesn't 
mean it will be easy for the lexical parser.

> "Should we use i or j ?" There are good reasons for both i and j. This
> one comes down to personal preference.

    no, not really.  nobody writes,   e^(jPI) + 1 = 0

    Euler wants to see   e^(iPI) + 1 = 0      ;-)

> "Should the imaginary part be set off somehow?" What do you mean "set
> off"? Why do you want to? Since the imaginary part can appear on its own:

    simply, is 2j a literal complex part?  ...yes     2 j  ...no

    In other words, there must NEVER be a space between the 2 and j. 
This is debatable:   3 +2j    although, I want to see    3+2j


>      z = 2 + 3j  # an expression adding 2 to 3j
>      z = 5*3j  # an expression multiplying 5 by 3j

    all good, well until its not

> How flexible should the complex constructor be? Should it bend over
> backwards to accept any mathematical expression that includes a complex j
> suffix, e.g. complex("2**3i")? I think not,

    I think not either.  But, it is possible to have *many* constructors/

    But, really, how often is this a problem?   like almost never!

>>   >>>  complex( 3   +2j  )
>> (3+2j)
>>   >>>
>> I don't know... you tell me.
>
> In both cases, the call to complex is redundant. You've already created a
> complex number, using syntax, then you pass it to the complex function
> which just returns the same number.

    Of course.  I was merely pointing out that the constructor for 
'literals' (whatever you guys mean by that) is 'different' than the 
consistency with the string constructor.  As Chris pointed out these are 
two markedly different animals; one is a valid parse syntax, the other 
is a string constructor.   But here is my point--- to the user the 
difference comes down to semantics, which is not really true.

     cf. below

>>   >>>  complex('3+2j')
>> (3+2j)
>>   >>>  complex('3 +2j')
>> Traceback (most recent call last):
>>     File "<pyshell#17>", line 1, in<module>
>>       complex('3 +2j')
>> ValueError: complex() arg is a malformed string


>> Also, philosophically, C ignores white space;  python does not.

    This was said tongue in cheek...  *both* languages inconsistently 
observer (and ignore) white space!  But, in general, white space is more 
important to python, and less important to C.

I'm still hung up on whether I'm a lousy language designer.  I guess 
we'll know if people use my language (or not)!  I suppose they might use 
it even though its lousy; on the other hand, it might be too simple for 
folks to be able to figure it out.   :)

marcus