[16:37:23] i'm not subscribed to the mailing list but maybe
someone who is could chime in to this thread
https://www.nntp.perl.org/group/perl.perl6.users/2021/04/msg9878.html and
mention that i believe the problem is in libtommath's mp_get_double and the gmp
branch fixes it?
> On 14 Apr
Hi,
I see in the include file that mpz_t is defined as follow:
typedef __mpz_struct mpz_t[1];
and in turn __mpz_struct is:
typedef struct
{
int _mp_alloc;
int _mp_size;
mp_limb_t *_mp_d;
} __mpz_struct;
with mp_lib_t defined in three different ways, according to the value of a
macro,
On Wed, Apr 28, 2021 at 5:38 PM Fernando Santagata <
nando.santag...@gmail.com> wrote:
> ,
> If you've found the Perl XS interface easy to work with, give Raku's
> NativeCall a try, you will find it amazing. Since you already know the C
> libraries, I guess you can cook an interface in no time.
>
Hi,
If you've found the Perl XS interface easy to work with, give Raku's
NativeCall a try, you will find it amazing. Since you already know the C
libraries, I guess you can cook an interface in no time.
On Wed, Apr 28, 2021 at 7:09 AM sisyphus wrote:
>
>
> On Tue, Apr 27, 2021 at 12:23 AM
On Tue, Apr 27, 2021 at 12:23 AM sisyphus wrote:
> (I guess I could just use Inline::Perl5 ... not exactly my preferred
> option ... but a viable alternative, I would think.)
>
>
The following sort of works, but not in a very meaningful way.
All it really does is show that perl is seeing the 3
On Sun, Apr 25, 2021 at 3:57 AM Ralph Mellor
wrote:
> On Fri, Apr 16, 2021 at 7:22 AM sisyphus wrote:
> >>
> > The conversion from int to num looks sane.
>
> Sounds good. :)
>
> So presumably our early tentative conclusion of what we hope
> will pan out is that if one wants precise IEEE float
On Fri, Apr 16, 2021 at 7:22 AM sisyphus wrote:
>>
> The conversion from int to num looks sane.
Sounds good. :)
So presumably our early tentative conclusion of what we hope
will pan out is that if one wants precise IEEE float behaviour,
one uses `num` instead of `Num`. Right?
> However, the
On Fri, Apr 16, 2021 at 10:21 AM Ralph Mellor
wrote:
[snip]
>
> my int $i = ...;
> my num $n = $i;
>
>
The conversion from int to num looks sane.
Of course, we can't assign 64 bit values to an int, so I switched to the
63-bit values 9223372036854775296 and 9223372036854775295.
The first of
On Wed, Apr 14, 2021 at 3:10 AM sisyphus wrote:
>
> Is this a bug that I ought to report ?
I'm not yet convinced the issues you showed are classifiable as bugs.
Part of my reasoning for my conservatism is per the guidance Larry
provided in the design docs. In particular, per design doc S02:
>
What do these enormous numbers represent?
On 4/13/21, sisyphus wrote:
> Hi,
>
> C:\>raku -e "say 1.8446744073709552e+19 == 18446744073709551615"
> True
>
> I think I understand why raku deems this to be true.
> The LHS is 0x1p+64, which is identical to the double that the RHS rounds
> to.
>
10 matches
Mail list logo
