On Fri, Jul 12, 2013 at 2:54 PM, Joshua Landau wrote:

On 12 July 2013 13:36, Zaur Shibzukhov wrote:

...

Hello!

Is it good idea to allow float('∞') to be float('inf') in python?

Why?

Because it obviously means infinity -- much more so than "inf" does :) cheers lvh

int ('100%') = 1? float('1%') = 0.01? -1

12.07.13 15:36, Zaur Shibzukhov написав(ла):

...

Is it good idea to allow float('∞') to be float('inf') in python?

float('½') == 0.5? float('3.(142857)') == 22/7? int('Ⅶ') == 7? int('✌') == 2?

AIM - Gesellschaft für angewandte Informatik und Mikroelektronik m.b.H Registered Office: Freiburg District Court of Freiburg HRB 3520 Managing Directors: Hansjörg Frey, Joachim Schuler This E-mail and any attachment(s) to it are for the addressee's use only. It is strictly confidential and may contain legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended addressee, then please delete it from your system and notify the sender immediately. You are hereby notified that any use, disclosure, copying or any action taken in reliance on it is strictly prohibited and may be unlawful. - Thank you.

12.07.13 17:10, Joshua Landau написав(ла):

int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.

Why you think ½ (this is only one symbol!) and 3.(142857) (this is a decimal notation of the 22/7 fraction) are expressions, but ∞ or even -1 are not?

12.07.13 18:50, Joshua Landau написав(ла):

On 12 July 2013 16:26, Serhiy Storchaka wrote:

...

12.07.13 17:10, Joshua Landau написав(ла):

...

int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.

Why you think ½ (this is only one symbol!) and 3.(142857) (this is a decimal notation of the 22/7 fraction) are expressions, but ∞ or even -1 are not?

For the same reason that 0.5 and [0, 1, 2, 3, 4] are literals but 1/2 and range(5) are not.

∞ is not a literal.

12.07.13 20:18, Joshua Landau написав(ла):

On 12 July 2013 18:12, Serhiy Storchaka wrote:

...

12.07.13 18:50, Joshua Landau написав(ла):

...

On 12 July 2013 16:26, Serhiy Storchaka wrote:

...

12.07.13 17:10, Joshua Landau написав(ла):

...

int and float are obviously meant to handle abstract inputs (not expressions) and unicode infinity is an extension of this. Your "analogies" are inapt.

Why you think ½ (this is only one symbol!) and 3.(142857) (this is a decimal notation of the 22/7 fraction) are expressions, but ∞ or even -1 are not?

For the same reason that 0.5 and [0, 1, 2, 3, 4] are literals but 1/2 and range(5) are not.

∞ is not a literal.

So? float("[1, 2, 3, 4]") isn't valid -- I never claimed there was 1:1 mapping between literals and things that float should except. I said that float shouldn't parse expressions.

I agree. But how is it related to ½ and 3.(142857)?

On 07/12/2013 02:27 PM, Joshua Landau wrote:

On 12 July 2013 18:58, Serhiy Storchaka mailto:storchaka@gmail.com> wrote:

...

I agree. But how is it related to ½ and 3.(142857)?

½ === 1/2; thus is an expression

That's ridiculous. ½ is no more an expression than "0.5" is. -- ~Ethan~

13.07.13 00:27, Joshua Landau написав(ла):

On 12 July 2013 18:58, Serhiy Storchaka mailto:storchaka@gmail.com> wrote: I agree. But how is it related to ½ and 3.(142857)? ½ === 1/2; thus is an expression

0.5 === 5/10. Isn't it an expression?

3.(142857) is more ambiguous, because there's not actually any mathematical operator in place. But it is too much parsing for no benefit, AFAICT; you would complicate something simple to solve almost no use-cases, and then when they are used it's harder for people to work out what is meant.

AFAIK children teach 3.(142857) before ∞. I'm sure people use fractions and recurring decimals more often than infinity.

The informal definition for "expression" with regards to int and float I'm using is basically the measure of how much more parsing code would need to be implemented.

½ requires no more parsing code then ∞.

13.07.13 00:52, Masklinn написав(ла):

On 12 juil. 2013, at 21:46, Serhiy Storchaka wrote:

...

13.07.13 00:27, Joshua Landau написав(ла):

...

On 12 July 2013 18:58, Serhiy Storchaka mailto:storchaka@gmail.com> wrote: I agree. But how is it related to ½ and 3.(142857)? ½ === 1/2; thus is an expression

0.5 === 5/10. Isn't it an expression?

In the context of making a difference between literal values and other expressions in python, yes 5/10 is an expression, no 0.5 is not one.

In this context both ∞ and ½ are not literal values and not expressions.

On Fri, Jul 12, 2013 at 5:55 PM, Joshua Landau wrote:

Au contraire, if you accept ½ you are bound by law to accept all of the other fractions -- that's much more code than just allowing ∞.

Let's see: def float(x): if x == '\u221e': return builtins.float('inf') return builtins.float(x) def float(x): if len(x) == 1: return unicodedata.numeric(x) return builtins.float(x) Where is "much more code "? And if you accept '∞', aren't you "bound by law to accept '+∞' and '-∞' as well?

13.07.13 00:55, Joshua Landau написав(ла):

On 12 July 2013 22:46, Serhiy Storchaka mailto:storchaka@gmail.com> wrote:

13.07.13 00:27, Joshua Landau написав(ла):

On 12 July 2013 18:58, Serhiy Storchaka mailto:storchaka@gmail.com mailto:storchaka@gmail.com>> wrote: I agree. But how is it related to ½ and 3.(142857)? ½ === 1/2; thus is an expression

0.5 === 5/10. Isn't it an expression?

No. That's like saying "1 === 2/2". There is a much more obvious equivalence between two ways of writing "1/2" than between two ways of displaying the result of "1/2".

0.5 is 5/10 by definition. The result of 1/2 is a fraction ½.

3.(142857) is more ambiguous, because there's not actually any mathematical operator in place. But it is too much parsing for no benefit, AFAICT; you would complicate something simple to solve almost no use-cases, and then when they are used it's harder for people to work out what is meant.

AFAIK children teach 3.(142857) before ∞. I'm sure people use fractions and recurring decimals more often than infinity.

In my experience (I'll take a good wager I'm younger than you) people learn first about infinity, then are taught recurrence using the floating-dot syntax. The bracket form for recurrence was not taught once during high-school for me, and although "infinity" was hardly covered either it's not niche knowledge.

Well, maybe it's a cultural difference. I learned recurring decimals in primary school (if memory serves me).

Plus, why on earth would you use recurrence for floats? Give me a use case. There's a good reason for float infinity.

This is only a way to spell a general fraction in decimal. On other hand, ∞ is even not a real number.

Note that I'm British.

The informal definition for "expression" with regards to int and float I'm using is basically the measure of how much more parsing code would need to be implemented.

½ requires no more parsing code then ∞.

Au contraire, if you accept ½ you are bound by law to accept all of the other fractions -- that's much more code than just allowing ∞.

If you accept ∞ you are bound by law to accept ½ and all of the other fractions — and that's much more code than just allowing ∞.

14.07.13 11:56, Joshua Landau написав(ла):

On 14 July 2013 09:40, Serhiy Storchaka wrote:

...

13.07.13 00:55, Joshua Landau wrote:

...

On 12 July 2013 22:46, Serhiy Storchaka wrote:

...

13.07.13 00:27, Joshua Landau wrote:

...

½ === 1/2; thus is an expression

0.5 === 5/10. Isn't it an expression?

No. That's like saying "1 === 2/2". There is a much more obvious equivalence between two ways of writing "1/2" than between two ways of displaying the result of "1/2".

0.5 is 5/10 by definition. The result of 1/2 is a fraction ½.

I don't understand. What are you trying to say?

0.5 is a spelling of 5⁄10 which is a result of expression 5/10. ½ is a spelling of 1⁄2 which is a result of expression 1/2. I don't understand why you think 1⁄2 is expression while 5⁄10 is not.

...

...

Plus, why on earth would you use recurrence for floats? Give me a use case. There's a good reason for float infinity.

This is only a way to spell a general fraction in decimal. On other hand, ∞ is even not a real number.

That's not a use-case.

∞ is not a use-case.

...

If you accept ∞ you are bound by law to accept ½ and all of the other fractions — and that's much more code than just allowing ∞.

I was afraid that people would go and take this too literally. But either way, if you accept ½ and reject ¾, you have made a really bad design decision. If you accept ∞ and reject ½, the atrocity of that decision is much less. I would say it's a good choice, you may say it is bad. But if you say those are equivalently bad decisions you're simply wrong and there's not much more I can say.

The difference between this two bad choices is far less than the difference between good and bad. Why should we choose between two bad designs?

On 7/14/2013 7:08 AM, Philipp A. wrote:

2013/7/14 Serhiy Storchaka mailto:storchaka@gmail.com>

∞ is not a use-case.

it is. OP has it in his/her data.

Looking back through the many emails about this so far, I didn't see where the OP explained why he wanted this to work. Zaur Shibzukhov never said he had it in his data, he said, "Is it good idea to allow float('∞') to be float('inf') in python?" and, "Because infinity is special case of numbers. Unicode standard have regular infinity symbol and it's natural to represent inifinity as ∞." As near as I can tell, we don't have an actual use case yet. --Ned.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

14.07.13 16:53, Zaur Shibzukhov написав(ла):

I think that actual use cases are rather belongs to numeric area. For example, one could use infinity symbol when output infinity numerical results of calculations to the text file and another one input them. Usually float numbers in python world are converted from string using float(...). So any code that use float to convert from string could benefit.This is not a real use case though, but rather some scenario...

If one use custom code to output an infinity float as '∞' (or '+∞', or '-', or '\\infty', or 'бесконечность', or '>9000'), then another one should use custom code to input them.

Because infinity is special case of numbers. Unicode standard have regular infinity symbol and it's natural to represent inifinity as ∞. пятница, 12 июля 2013 г., 17:12:09 UTC+4 пользователь Serhiy Storchaka написал:

12.07.13 15:36, Zaur Shibzukhov написав(ла):

...

Is it good idea to allow float('∞') to be float('inf') in python?

float('½') == 0.5? float('3.(142857)') == 22/7? int('Ⅶ') == 7? int('✌') == 2?

_______________________________________________ Python-ideas mailing list Python...@python.org javascript: http://mail.python.org/mailman/listinfo/python-ideas

понедельник, 15 июля 2013 г., 14:26:43 UTC+4 пользователь Oscar Benjamin написал:

On 12 July 2013 13:36, Zaur Shibzukhov javascript:> wrote:

...

Is it good idea to allow float('∞') to be float('inf') in python?

I don't think so as my preference is for Python to stick to IEEE 754 as closely as possible.

Section 5.12.1 of IEEE 754-2008 says ''' Conversion of an infinity in a supported format to an external character sequence shall produce a language defined one of “inf” or “infinity” or a sequence that is equivalent except for case (e.g., “Infinity” or “INF”), with a preceding minus sign if the input is negative. Whether the conversion produces a preceding plus sign if the input is positive is language-defined.

Conversion of external character sequences “inf” and “infinity” (regardless of case) with an optional preceding sign, to a supported floating-point format shall produce an infinity (with the same sign as the input). '''

This does not seem to prohibit accepting other strings for infinity but it does explicitly define a set of textual representations for infinity. I don't think Python's float <-> str conversions should accept (or emit) any other strings for infinity.

Since I was looking at the standard I was also interested to see what is says about non-ascii decimal digits (as accepted by Python 3). Immediately above this in section 5.12 it says ''' Issues of character codes (ASCII, Unicode, etc.) are not defined by this standard. '''

My interpretation of that is that Python's current behaviour is conforming but that it would also be conforming if it didn't accept non-ascii decimal digits.

With this we could agree if python completely drop support for non-ascii input.

As for IEEE-754-2008, it not fully defined presentation of infinity because we now could have several strings that could identified as "infinity" (inf, Inf, INF, infinity, Infinity, INFINITY). So if IEEE committee will decide to designate one single textual view of infinity that could be ok.