On Fri, Aug 7, 2009 at 07:15, Nanime Puloski wrote:
> But if it were an unsigned int64, it should be able to hold 2**64 or at
> least 2**64-1.
> Am I correct?
There is no numpy.sin() implementation for uint64s, just the floating
point types.
--
Robert Kern
"I have come to believe that the whole
But if it were an unsigned int64, it should be able to hold 2**64 or at
least 2**64-1.
Am I correct?
On Fri, Aug 7, 2009 at 1:03 AM, David Warde-Farley wrote:
> On 6-Aug-09, at 7:29 PM, Robert Kern wrote:
>
> > For that value, yes, but not for long objects in general. We don't
> > look at the val
On Fri, Aug 7, 2009 at 00:03, David Warde-Farley wrote:
> On 6-Aug-09, at 7:29 PM, Robert Kern wrote:
>
>> For that value, yes, but not for long objects in general. We don't
>> look at the value itself, just the type.
>
> Err, don't look at the value (of a long), except when it's
> representable wi
On 6-Aug-09, at 7:29 PM, Robert Kern wrote:
> For that value, yes, but not for long objects in general. We don't
> look at the value itself, just the type.
Err, don't look at the value (of a long), except when it's
representable with an integer dtype, right? Hence why 2**63 - 1 works.
David
__
On Thu, Aug 6, 2009 at 18:26, Nanime Puloski wrote:
> Thank you for your responses so far.
> What I also do not understand is why sin(2**64) works with
> the standard Python math module, but fails to do so with NumPy?
math.sin() always converts the argument to a float. We do not.
> To Robert Kern
Thank you for your responses so far.
What I also do not understand is why sin(2**64) works with
the standard Python math module, but fails to do so with NumPy?
To Robert Kern:
Can't 2^64 be represented in C as a long double?
It seems to work well on my machine.
