in reply to Re: Can I access and use UV types from perl?
in thread Can I access and use UV types from perl?

dave_the_m I see the lowercase f there making me think floats, yikes. oh, its a flag :smile.

The automagic of Perl values is a great thing, which I value immensely. Please see Re^2: Can I access and use UV types from perl? for a substantial waffle regarding my deeper motives for this expiditionary embarkation.

On one level I want to be able to say I am adding natural numbers together and be speaking truthfully, rather than saying that, but actually what is happening is that I am adding a subset of integers together.

Looking at the output. There does seem to be some kind of interplay between the size of the storage unit and the kind of number that Perl assumes the user is wanting to use. That is interesting.

Replies are listed 'Best First'.
Re^3: Can I access and use UV types from perl?
by haukex (Archbishop) on Nov 17, 2019 at 19:53 UTC
    On one level I want to be able to say I am adding natural numbers together and be speaking truthfully, rather than saying that, but actually what is happening is that I am adding a subset of integers together.

    Then maybe use bignum or bigrat, at a significant performance cost.

[reply]
[d/l]
[select]

      The main sense I am getting from this, is that Perl is all about the storage.

      bignum still appears to store the value as an IV though. and converting a number into a rat is the same problem only stepped up to a relationship between Rationals and Naturals, the Natural numbers now being a subset of Rationals rather than a subset of Integers.

      #use bignum;
=head1 output
 
    SV = PVAV(0x6fb404) at 0x6fa59c
        REFCNT = 1
        FLAGS = ()
        ARRAY = 0x2ce1c64
        FILL = 1
        MAX = 3
        ARYLEN = 0x0
        FLAGS = (REAL)
        Elt No. 0
        SV = IV(0x25bfd30) at 0x25bfd34
          REFCNT = 1
          FLAGS = (IOK,pIOK)
          IV = 4967296
        Elt No. 1
        SV = IV(0x6fa578) at 0x6fa57c
          REFCNT = 1
          FLAGS = (IOK,pIOK)
          IV = 429
=cut

      [download]

      Interestingly when I was hacking MvT attempting to use hashkeys to represent natural numbers i kept getting (FAKE) flags, maybe there's something in that. Also storing bitfields as hashkeys has unexpected results.

      It would seem that some kind of overloading solution may be the way to go, let Perl handle the storage, but overload the operations with XSUBS that do type checking/coercion. Or even straight up Inlining C.

[reply]
[d/l]
[select]
        bignum still appears to store the value as an IV though.

        No, they're objects*. See the output of perl -Mbignum -MDevel::Peek -e 'my $x=1; Dump($x)' or perl -Mbignum -MData::Dump -e 'my $x=1; dd($x)'.

        It would seem that some kind of overloading solution may be the way to go, let Perl handle the storage, but overload the operations with XSUBS that do type checking/coercion. Or even straight up Inlining C.

        Well, again, if you don't tell us what for, we can't really comment.

        * Update: I guess you maybe mean internally? The point is, how they're stored internally is abstracted and encapsulated in an object, and you shouldn't worry about it. bignum will allow you to work with numbers of any size and any precision without any loss due to the usual floating-point imprecisions, overflows, etc.

[reply]
[d/l]
[select]
        The main sense I am getting from this, is that Perl is all about the storage.

        My sense is that Perl is all about the DWIM. What I haven't seen so far (and apologies if I've missed it) is where your problem lies. Here's a simple example:

        #!/usr/bin/env perl 
use strict;
use warnings;

use Test::More tests => 1;

my $x = 3;
my $y = 2;
is $x + $y, 5, 'Yes, your integers behave exactly as expected';

        [download]

        What else do you expect to happen?

[reply]
[d/l]

In Section Seekers of Perl Wisdom