On Monday, October 24, 2011, Joachim Durchholz wrote:
> Am 24.10.2011 08:37, schrieb Aaron Meurer:
>
>> On Sun, Oct 23, 2011 at 11:33 PM, Aaron Meurer<asmeu...@gmail.com>
>> wrote:
>>
>>> On Sat, Oct 22, 2011 at 3:57 AM, Joachim Durchholz<j...@durchholz.org>
>>> wrote:
>>>
>>>> I'm seeing parameters that select primes by index, and parameters that
>>>> select primes by magnitude. I'm assuming they should all be protected,
>>>> not
>>>> just those two that are mentioned in the issue report.
>>>> Correct?
>>>>
>>>
>>> Yes, anything that is a public function should do some kind of type
>>> check to prevent against this problem.
>>>
>>
> Okay.
>
> Those that select by index should be limited to integers.
>>>> Those that select by defining a minimum and/or maximum range should be
>>>> limited to floats.
>>>> Correct?
>>>>
>>>
>>> I think since the range is over the integers, you can also just cast
>>> these to int(), and if that fails then it is incorrect.
>>>
>>
> The docstring of primepi(n) says:
> "Return the value of the prime counting function pi(n) = the number of
> prime numbers less than or equal to n. The number n need not necessarily be
> an integer."
>
> The reasoning behind the definition of the pi function could (and, IMVHO,
> should) be extended to the likes of prevprime(n) ("Return the largest prime
> smaller than n.") and primerange(a, b) ("Generate a list of all prime
> numbers in the range [a, b).")
>
> The issue report suggests testing for non-"intness" via
>>>> int(N) != N
>>>> What's the best way to test for "floatness" in Python?
>>>>
>>>
>>> This is not what the issue suggests.
>>>
>>
> Why is this important?
> More specifically, I do not fully understand why extending the issue to
> cover more functions is okay, but extending the domain of parameter values
> is not.
> Might be some ramifications that I don't know yet - in which case I'd like
> to know :-)
>
I'm afraid I don't understand what you're asking here. If you're asking why
you can't use floats, you can. Calling int() on a float will truncate it,
but it doesn't matter, because it's just a range over the integers.
Actually, I guess you would really need to call ceil() in that case.
Did I understand your question correctly?
Aaron Meurer
> >> It says that you should just
>
>> cast it to int, and if it works, then it is correct, and if not, then
>>> it will raise a TypeError, which is what it should do in that case.
>>>
>>
>> More specifically, just add
>>
>> n = int(n)
>>
>> to the top of the function.
>>
>
> Sounds good to me.
>
> If anybody comes up with a passage in the style guide that disallows
> assigning to parameters, I still think it's okay to assign to a parameter.
> Once, at the top of the function, for normalization purposes.
>
> Regards,
> Jo
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To post to this group, send email to sympy@googlegroups.com.
> To unsubscribe from this group, send email to
> sympy+unsubscr...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/**
> group/sympy?hl=en <http://groups.google.com/group/sympy?hl=en>.
>
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
