Displaying 9 results from an estimated 9 matches for "arbitraryprecision".
2020 Jan 19
2
rpois(9, 1e10)
...ult = "numeric" and "NA" as a second option.? Or NA is the
default, so no code that relied that feature of the current code would
be broken by the change.? If someone wanted to use arbitrary precision
arithmetic, they could write their own version of this function with
"arbitraryPrecision" as an optional value for the "bigOutput" argument.
????? Comments?
????? Thanks,
????? Spencer Graves
On 2020-01-19 10:28, Avraham Adler wrote:
> Technically, lambda can always be numeric. It is the observations
> which must be integral.
>
> Would hitting everyth...
2020 Jan 19
2
rpois(9, 1e10)
...uot;NA" as a second
> option.? Or NA is the default, so no code that relied that feature
> of the current code would be broken by the change.? If someone
> wanted to use arbitrary precision arithmetic, they could write
> their own version of this function with "arbitraryPrecision" as an
> optional value for the "bigOutput" argument.
>
>
> ????? Comments?
> ????? Thanks,
> ????? Spencer Graves
>
>
>
> On 2020-01-19 10:28, Avraham Adler wrote:
>> Technically, lambda can always be numeric. It is the obs...
2020 Jan 19
2
rpois(9, 1e10)
...? Or NA is the default, so no code
>> that relied that feature of the current code would be broken
>> by the change.? If someone wanted to use arbitrary precision
>> arithmetic, they could write their own version of this
>> function with "arbitraryPrecision" as an optional value for
>> the "bigOutput" argument.
>>
>>
>> ????? Comments?
>> ????? Thanks,
>> ????? Spencer Graves
>>
>>
>>
>> On 2020-01-19 10:28, Avraham Adler wrote:
>>&...
2020 Jan 19
0
rpois(9, 1e10)
...;numeric" and "NA" as a second option. Or NA is the default, so
> no code that relied that feature of the current code would be broken by the
> change. If someone wanted to use arbitrary precision arithmetic, they
> could write their own version of this function with "arbitraryPrecision" as
> an optional value for the "bigOutput" argument.
>
>
> Comments?
> Thanks,
> Spencer Graves
>
>
>
> On 2020-01-19 10:28, Avraham Adler wrote:
>
> Technically, lambda can always be numeric. It is the observations which
> mu...
2020 Jan 19
0
rpois(9, 1e10)
...uot;NA" as a second option. Or NA is the
>> default, so no code that relied that feature of the current code would be
>> broken by the change. If someone wanted to use arbitrary precision
>> arithmetic, they could write their own version of this function with
>> "arbitraryPrecision" as an optional value for the "bigOutput" argument.
>>
>>
>> Comments?
>> Thanks,
>> Spencer Graves
>>
>>
>>
>> On 2020-01-19 10:28, Avraham Adler wrote:
>>
>> Technically, lambda can always be numeri...
2020 Jan 20
2
[External] Re: rpois(9, 1e10)
...gt;>>> that relied that feature of the current code would be broken
>>>> by the change.? If someone wanted to use arbitrary precision
>>>> arithmetic, they could write their own version of this
>>>> function with "arbitraryPrecision" as an optional value for
>>>> the "bigOutput" argument.
>>>>
>>>>
>>>> ????? Comments?
>>>> ????? Thanks,
>>>> ????? Spencer Graves
>>>>
>>>>
>>&...
2020 Jan 19
2
rpois(9, 1e10)
So imagine rpois is changed, such that the storage mode of its return
value is sometimes integer and sometimes numeric. Then imagine the case
where lambda is itself a realization of a random variable. Do we really
want the storage mode to inherit that randomness?
On 1/19/20 10:47 AM, Avraham Adler wrote:
> Maybe there should be code for 64 bit R to use long long or the like?
>
> On
2020 Jan 20
0
[External] Re: rpois(9, 1e10)
...efault, so no code
>>> that relied that feature of the current code would be broken
>>> by the change.? If someone wanted to use arbitrary precision
>>> arithmetic, they could write their own version of this
>>> function with "arbitraryPrecision" as an optional value for
>>> the "bigOutput" argument.
>>>
>>>
>>> ????? Comments?
>>> ????? Thanks,
>>> ????? Spencer Graves
>>>
>>>
>>>
>>> On 2020-01-...
2020 Jan 20
0
[External] Re: rpois(9, 1e10)
...de
>>>>> that relied that feature of the current code would be broken
>>>>> by the change.? If someone wanted to use arbitrary precision
>>>>> arithmetic, they could write their own version of this
>>>>> function with "arbitraryPrecision" as an optional value for
>>>>> the "bigOutput" argument.
>>>>>
>>>>>
>>>>> ????? Comments?
>>>>> ????? Thanks,
>>>>> ????? Spencer Graves
>>>>>...