Taking Rob Cliffe's statement in good part, changing the subject (belatedly, sorry!)
Andrew Barnert writes: > What does FVO mean? Sorry. "For values of" > At any rate, there’s nothing wrong with simplistic. My usage of simplistic is to simple as complicated is to complex. The distinction relates to the cost of design vs cost to users tradeoff. "Simplistic" and "complicated" impose complexity on users in ways that could (and implicitly should) be avoided by more effort on design. So: > Our usual addition on natural numbers is simplistic, I don't understand why you use "simplistic" here, rather than "simple". > and there are all kinds of other sort-of-addition-like things you > could define on top of successor instead of it that are less > simplistic, but none of them are nearly as useful, natural, or > intuitive. You mean like hardware unsigned modular integer arithmetic, and two's complement addition for signed integers? But they are not "simple" for humans to use, though I would call them "simplistic" in the sense that "these are simple to implement, and people will just have to deal". > And it’s one that preserves all the properties you’d hope—most > importantly, continuation. Yes, I agree. My question is whether users would be better off with a different simplicity. After all, the electrical engineers don't get embedded reals for free, they have to test for .imag == 0 and then use .real: >>> float(1 + 0j) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can't convert complex to float > > My reasoning is the available *mathematical* values we model > > should make sense as expressing the set of possible limits in > > polar coordinates as well as in Cartesian coordinates (and as the > > limits of arbitrary lines). But these are in some sense > > distinct, with a couple of exceptions. > > But the infinite values we’re trying to model aren’t distinct > between the two coordinate systems. But they are. (inf + 1j) and (inf + 2j) cannot be distinguished in polar coordinates, while the infinities with arg = 1/2 and arg = 1/4 cannot be distinguished in Cartesian coordinates. You need a category with a concept of limiting process to make those distinctions with the "wrong" coordinate system; extended arithmetic is not enough. Maybe the "endpoints of lines" representation of infinity in the affine complex plane gets all of the infinities? > So what? Always a good question. :-) "Readability counts". For *my* purposes, complex numbers are just numbers visualized in projective polar coordinates, and nan + 1j *is* just nan, inf + 1j *is* just inf. We *could* have a language where the calculations of complex arithmetic are done with Cartesian pairs of IEEE reals, the strs are 'inf' and 'nan', and there's an API for extracting further information from the object if you care. Instead we have a str that gives me the WTFs when I visualize them, which I do automatically. But then, I am a (wannabe) mathematician, and quite possibly only the other 100 people who read the books I do feel the same way. > If you want to insist that nobody else can ever care Please, sir! I am a faithful Economist, my creed is "De gustibus non est disputandum." I don't have a use case for projective arithmetic, just a matter of taste in float.__str__. I was unaware of the pragmatics of electrical engineering, and am happy to let their calculations "just work". If they are used to seeing "inf + 1j" and it is useful to them, that's more important than my occasional WTF. Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TLBYBJUZGOMCTTIOKDOYPWMZPUWV7APH/ Code of Conduct: http://python.org/psf/codeofconduct/
