Does Perl formally support exponential notation for octal numbers?

[briandfoy]

Description

perldata does not mention a octal floating point form, but apparently it works:

$ perl5.32.0 -le 'print 01.4441766521041321410646114314242700334p+1'
3.14159265358979
$ perl5.33.8 -le 'print 0o1.4441766521041321410646114314242700334p+1'
3.14159265358979

Is this intended? If so, it should be added to the list of scalar value constructors.

If this is not intended, I guess it should stop doing that.

Perl configuration

Summary of my perl5 (revision 5 version 32 subversion 1) configuration:
   
  Platform:
    osname=darwin
    osvers=19.3.0
    archname=darwin-2level
    uname='darwin otter.local 19.3.0 darwin kernel version 19.3.0: thu jan 9 20:58:23 pst 2020; root:xnu-6153.81.5~1release_x86_64 x86_64 '
    config_args='-des -Dprefix=/usr/local/perls/perl-5.32.1'
    hint=recommended
    useposix=true
    d_sigaction=define
    useithreads=undef
    usemultiplicity=undef
    use64bitint=define
    use64bitall=define
    uselongdouble=undef
    usemymalloc=n
    default_inc_excludes_dot=define
    bincompat5005=undef
  Compiler:
    cc='cc'
    ccflags ='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.15 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -DPERL_USE_SAFE_PUTENV'
    optimize='-O3'
    cppflags='-fno-common -DPERL_DARWIN -mmacosx-version-min=10.15 -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
    ccversion=''
    gccversion='4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.62)'
    gccosandvers=''
    intsize=4
    longsize=8
    ptrsize=8
    doublesize=8
    byteorder=12345678
    doublekind=3
    d_longlong=define
    longlongsize=8
    d_longdbl=define
    longdblsize=16
    longdblkind=3
    ivtype='long'
    ivsize=8
    nvtype='double'
    nvsize=8
    Off_t='off_t'
    lseeksize=8
    alignbytes=8
    prototype=define
  Linker and Libraries:
    ld='cc'
    ldflags =' -mmacosx-version-min=10.15 -fstack-protector-strong -L/usr/local/lib'
    libpth=/usr/local/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.3/lib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib /usr/lib
    libs=-lpthread -ldbm -ldl -lm -lutil -lc
    perllibs=-lpthread -ldl -lm -lutil -lc
    libc=
    so=dylib
    useshrplib=false
    libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs
    dlext=bundle
    d_dlsymun=undef
    ccdlflags=' '
    cccdlflags=' '
    lddlflags=' -mmacosx-version-min=10.15 -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector-strong'


Characteristics of this binary (from libperl): 
  Compile-time options:
    HAS_TIMES
    PERLIO_LAYERS
    PERL_COPY_ON_WRITE
    PERL_DONT_CREATE_GVSV
    PERL_MALLOC_WRAP
    PERL_OP_PARENT
    PERL_PRESERVE_IVUV
    PERL_USE_SAFE_PUTENV
    USE_64_BIT_ALL
    USE_64_BIT_INT
    USE_LARGE_FILES
    USE_LOCALE
    USE_LOCALE_COLLATE
    USE_LOCALE_CTYPE
    USE_LOCALE_NUMERIC
    USE_LOCALE_TIME
    USE_PERLIO
    USE_PERL_ATOF
  Built under darwin
  Compiled at Mar 21 2021 18:45:32
  %ENV:
    PERL="/Users/brian/bin/perls/perl-latest"
    PERL5_PATH="/Users/brian/bin/perls"
    PERL6_PATH="/Users/brian/bin/perl6s:/Applications/Rakudo/bin:/Applications/Rakudo/share/perl6/site/bin"
    PERLDOTCOM_AUTHOR="brian-d-foy"
    PERLSCHOOL_AUTHOR="brian d foy"
  @INC:
    /usr/local/perls/perl-5.32.1/lib/site_perl/5.32.1/darwin-2level
    /usr/local/perls/perl-5.32.1/lib/site_perl/5.32.1
    /usr/local/perls/perl-5.32.1/lib/5.32.1/darwin-2level
    /usr/local/perls/perl-5.32.1/lib/5.32.1

[sisyphus]

Based on some quick, non-extensive testing, it seems that both the octal and hex forms of floating point (bareword) values are no longer a fatal error as of perl-5.22.0.
However, the implementation of both octals and hexadecimals was buggy in that release.
For perl-5.x.0 (x >= 24), octals and hexadecimals seem to be treated correctly, though this requires that the 'p+exponent' part is specified in addition to the '0' or '0x' exponent.

I'd be hopeful that this could be attended to by amending the documentation as needed.

[pjacklam]

For perl-5.x.0 (x >= 24), octals and hexadecimals seem to be treated correctly, though this requires that the 'p+exponent' part is specified in addition to the '0' or '0x' exponent.

On Cygwin built with quadmath, binary and octal floating point literals were silently treated as hexadecimals before 5.28.0. From 5.28.0 and onwards, both binary, octal, and hexadecimals seem to work correctly. (And from 5.33.5 and onwards, the "0o" prefix is supported.)

[t-a-k]

Not surprisingly, perl also accepts binary floating point literals.

$ perl -wle 'print 0b1.1001001000011111101101010100010001000010110100011000p1'
3.14159265358979

In addition, currently perl does not seem to provide a standard way to convert floats to octal/binary form. IMHO it might be better to note in the document that the conversions are one-way.

[pjacklam]

In addition, currently perl does not seem to provide a standard way to convert floats to octal/binary form.

Going the other way is not straight forward because of limitations in the way perl handles floating point literals. For example, here is the number with the smallest magnitude using binary64 (a.k.a. double) floating point numbers:

$ perl -wle 'print 0x0.0000000000001p-1022'
4.94065645841247e-324

The following represents the same number. A warning is given, but the result is correct.

$ perl -wle 'print 0x1p-1074'
Hexadecimal float: exponent underflow at -e line 1.
4.94065645841247e-324

The following also represents the same number. Again a warning is given, but the result is incorrect.

$ perl -wle 'print 0x0.00000000000001p-1018'
Hexadecimal float: mantissa overflow at -e line 1.
0

By the way, all three representations work fine if perl is compiled with quadmath support, but of course in that case the numbers are no longer the smallest possible magnitude.

[tonycoz]

perldata does not mention a octal floating point form, but apparently it works:

$ perl5.32.0 -le 'print 01.4441766521041321410646114314242700334p+1'
3.14159265358979
$ perl5.33.8 -le 'print 0o1.4441766521041321410646114314242700334p+1'
3.14159265358979

Is this intended? If so, it should be added to the list of scalar value constructors.

It's not clear to me whether support for octal/binary floating point literals were intended when the code was originally written, or it just naturally came about from the way the implementation is integrated into the implementation of parsing hex/octal/binary integers.

We have fixed some bugs specific to octal/binary floating point literals, so considering them supported and documenting them is reasonable.

[sisyphus]

For me. on Windows (building perl with mingw-w64 ports of gcc-8.3.0) the "0o" formatting (but not the "0x" or "0") is invalid prior to perl-5.33.5:

C:\>perl -le "print $]"
5.033004

C:\>perl -V:gccversion
gccversion='8.3.0';

C:\>perl -le "print 0o1.4441766521041321410646114314242700334p+1"
Bareword found where operator expected at -e line 1, near "0o1"
        (Missing operator before o1?)
Bareword found where operator expected at -e line 1, near "4441766521041321410646114314242700334p"
        (Missing operator before p?)
syntax error at -e line 1, near "0o1"
Execution of -e aborted due to compilation errors.

C:\>perl -le "print 0o1.4441766521041321410646114314242700334"
Bareword found where operator expected at -e line 1, near "0o1"
        (Missing operator before o1?)
syntax error at -e line 1, near "0o1"
Execution of -e aborted due to compilation errors.

Is it the same on other systems ?

Also, when the 'p+exponent' part is left out, the decimal point is taken to be the dot operator, which seems a little odd:

C:\>perl -wle "print 01.55p+0"
1.703125

C:\>perl -wle "print 01.55"
155

C:\>perl -wle "print 015.5"
135

A similar thing happens wrt to "0x":

C:\>perl -wle "print 0x1.55p+0"
1.33203125

C:\>perl -wle "print 0x1.55"
155

C:\>perl -wle "print 0x15.5"
215

And then for me (perl-5.33.5 and later only):

C:\>perl -le "print 0o1.444p+0"
1.5703125

C:\>perl -le "print 0o1.444"
1444

C:\>perl -le "print 0o14.44"
1244

It's a pity about that. Can it be covered via documentation ? ... or do we need to look at altering the behaviour ?

[pjacklam]

For me. on Windows […]
Is it the same on other systems ?

It is the same on Cygwin (as I mentioned above). It should be the same on all systems, since the support for the "0o" prefix was introduced with the commit b728918 between v5.33.4 and v5.33.5.

Also, when the 'p+exponent' part is left out, the decimal point is taken to be the dot operator, which seems a little odd:

C:\>perl -wle "print 01.55p+0"
1.703125

C:\>perl -wle "print 01.55"
155

C:\>perl -wle "print 015.5"
135

At least this is as documented. The literal is only treated as a floating point number if the exponent is present. As a consequence, if the exponent is not present, the bin/oct/hex number is treated as an integer.

[sisyphus]

On Mon, Mar 29, 2021 at 6:59 PM Peter John Acklam ***@***.***> wrote

At least this is as documented. The literal is only treated as a floating point number if the exponent is present. As a consequence, if the exponent is not present, the bin/oct/hex number is treated as an integer.

Good to know that the behaviour is already documented. (Thanks.) IIUC, when the exponent is absent, the number before the dot is treated as a bin/oct/hex integer, and the number following the dot is treated as a decimal integer (and concatenated onto the end of the first integer). It's hard to see how this could ever be considered as DWIMing. If I wanted that to happen, I would write the expression as: 0x1 . 55 not: 0x1.55. As regards decimal barewords, perl DWIMs for (eg) both: 2.18446744073709551615 and 2 . 18446744073709551615 (see below) so I don't know why it can't DWIM for the bin/oct/hex variant. Actually, I'm sure it *could* DWIM if someone wanted to make the effort to have it do so. C:\>perl -MDevel::Peek -wle "Dump(2.18446744073709551615);" SV = NV(0x3488c0) at 0x3488d8 REFCNT = 1 FLAGS = (NOK,READONLY,PROTECT,pNOK) NV = 2.1844674407371 C:\>perl -MDevel::Peek -wle "Dump(2 . 18446744073709551615);" SV = PV(0x58cf88) at 0x47df70 REFCNT = 1 FLAGS = (PADTMP,POK,READONLY,PROTECT,pPOK) PV = 0x4ed298 "218446744073709551615"\0 CUR = 21 LEN = 32 Obviously, this perl's nvtype is double and ivsize is 8. Anyway ... I'll settle for the fact that at least some productive gains have been achieved here, and not worry too much about what else might be achievable. Cheers, Rob

[briandfoy]

Closing this as inactive so it's not in my list of open issues.

[karenetheridge]

If this is documented, I'm not seeing it...