Mailing List Archive

On Mon, Jan 22, 2024 at 3:07?PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> Since we now have `true` and `false` builtins, in addition to the
> ever-present `undef`, I wonder if folks would want two more for
> slightly nicer working with floating-point numbers, being ways to get
> inf and NaN.
>
> I could write up a PPC on this but honestly it's barely 5 minutes to
> actually just implement it in a PR - thoughts on whether I should just
> do it?
>

Certainly it would make things nicer in tests, or at least more
self-documenting and robust than 9**9**9.

-Dan

On Mon, 22 Jan 2024 15:54:41 -0500
Dan Book <grinnz@gmail.com> wrote:

> On Mon, Jan 22, 2024 at 3:07?PM Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
>
> > Since we now have `true` and `false` builtins, in addition to the
> > ever-present `undef`, I wonder if folks would want two more for
> > slightly nicer working with floating-point numbers, being ways to
> > get inf and NaN.
> >
> > I could write up a PPC on this but honestly it's barely 5 minutes to
> > actually just implement it in a PR - thoughts on whether I should
> > just do it?
> >
>
> Certainly it would make things nicer in tests, or at least more
> self-documenting and robust than 9**9**9.
>
> -Dan

And thus, a PR:
https://github.com/Perl/perl5/pull/21872

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Mon, Jan 22, 2024 at 08:07:14PM +0000, Paul "LeoNerd" Evans wrote:
> Since we now have `true` and `false` builtins, in addition to the
> ever-present `undef`, I wonder if folks would want two more for
> slightly nicer working with floating-point numbers, being ways to get
> inf and NaN.

Don't we have those already?

perldata has this section:

> Special floating point: infinity (Inf) and not-a-number (NaN)
>
> Floating point values include the special values "Inf" and "NaN",
> for infinity and not-a-number. The infinity can be also negative.

What would be those add?

(Also, possibly spell infinity as "Inf" rather that "inf".)

--
Philippe Bruhat (BooK)

The faster the climb, the swifter the fall.
(Moral from Groo The Wanderer #87 (Epic))

On Tue, 23 Jan 2024 at 08:24, Philippe Bruhat (BooK) <book@cpan.org> wrote:

> On Mon, Jan 22, 2024 at 08:07:14PM +0000, Paul "LeoNerd" Evans wrote:
> > Since we now have `true` and `false` builtins, in addition to the
> > ever-present `undef`, I wonder if folks would want two more for
> > slightly nicer working with floating-point numbers, being ways to get
> > inf and NaN.
>
> Don't we have those already?
>
> perldata has this section:
>
> > Special floating point: infinity (Inf) and not-a-number (NaN)
> >
> > Floating point values include the special values "Inf" and "NaN",
> > for infinity and not-a-number. The infinity can be also negative.
>
>
strings vs symbols - personally I always prefer symbols (though as fewer
symbols available by default as possible)


> What would be those add?
>
> (Also, possibly spell infinity as "Inf" rather that "inf".)
>
> --
> Philippe Bruhat (BooK)
>
> The faster the climb, the swifter the fall.
> (Moral from Groo The Wanderer #87
> (Epic))
>

tir. 23. jan. 2024 kl. 08:24 skrev Philippe Bruhat (BooK) <book@cpan.org>:
>
> (Also, possibly spell infinity as "Inf" rather that "inf".)

Yes, please. POSIX uses "Inf" and "NaN". And while POSIX also
supports "nan", the POSIX standard uses "NaN" consistently in the
documentation of mathematical functions.

MATLAB, Octave, R uses "Inf" and "NaN". IIRC Python uses "inf" and
"nan", but then again, Python has "j" for the imaginary unit ...

Peter

On 1/23/24 03:08, Peter John Acklam wrote:
> tir. 23. jan. 2024 kl. 08:24 skrev Philippe Bruhat (BooK) <book@cpan.org>:
> >
> > (Also, possibly spell infinity as "Inf" rather that "inf".)
>
> Yes, please. POSIX uses "Inf" and "NaN". And while POSIX also
> supports "nan", the POSIX standard uses "NaN" consistently in the
> documentation of mathematical functions.
>
> MATLAB, Octave, R uses "Inf" and "NaN". IIRC Python uses "inf" and
> "nan", but then again, Python has "j" for the imaginary unit ...
>
> Peter

The perl naming convention is to leave capitals for package names, to
avoid ambiguity with functions.  Type::Tiny went against that and then
ended up in many real-world cases where an exported function has the
same fully qualified name as a package.

Now that I look though, it seems "use builtin" is doing lexical imports
instead of modifying the package namespace.  So maybe the naming
convention doesn't matter anymore?

-Mike

On Tue, Jan 23, 2024 at 11:20?AM Michael Conrad <mike@nrdvana.net> wrote:

> On 1/23/24 03:08, Peter John Acklam wrote:
> > tir. 23. jan. 2024 kl. 08:24 skrev Philippe Bruhat (BooK) <book@cpan.org
> >:
> > >
> > > (Also, possibly spell infinity as "Inf" rather that "inf".)
> >
> > Yes, please. POSIX uses "Inf" and "NaN". And while POSIX also
> > supports "nan", the POSIX standard uses "NaN" consistently in the
> > documentation of mathematical functions.
> >
> > MATLAB, Octave, R uses "Inf" and "NaN". IIRC Python uses "inf" and
> > "nan", but then again, Python has "j" for the imaginary unit ...
> >
> > Peter
>
> The perl naming convention is to leave capitals for package names, to
> avoid ambiguity with functions. Type::Tiny went against that and then
> ended up in many real-world cases where an exported function has the
> same fully qualified name as a package.
>
> Now that I look though, it seems "use builtin" is doing lexical imports
> instead of modifying the package namespace. So maybe the naming
> convention doesn't matter anymore?
>

It is documented (though not with examples presently) that builtin
functions are callable by their fully qualified name, but it's quite
unlikely at this time that builtin will get sub-namespaces unless such is
intentionally designed to conflict.

-Dan

On Mon, 22 Jan 2024 at 21:07, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> Since we now have `true` and `false` builtins, in addition to the
> ever-present `undef`, I wonder if folks would want two more for
> slightly nicer working with floating-point numbers, being ways to get
> inf and NaN.

INF and NAN come as INF, NAN, -INF, -NAN.

Also, in IEEE754-2008 it is mandatory to support -0, zero with a minus
sign. That is used for example to see from which direction rounding
was done.

Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd

On Mon, Jan 22, 2024 at 9:07?PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> Since we now have `true` and `false` builtins, in addition to the
> ever-present `undef`, I wonder if folks would want two more for
> slightly nicer working with floating-point numbers, being ways to get
> inf and NaN.
>
> I could write up a PPC on this but honestly it's barely 5 minutes to
> actually just implement it in a PR - thoughts on whether I should just
> do it?


One potential problem here is "how does it interact with
bigint/bignum/bigrat".

Leon

On Tue, Jan 23, 2024 at 2:54?PM Leon Timmermans <fawaka@gmail.com> wrote:

> On Mon, Jan 22, 2024 at 9:07?PM Paul "LeoNerd" Evans <
> leonerd@leonerd.org.uk> wrote:
>
>> Since we now have `true` and `false` builtins, in addition to the
>> ever-present `undef`, I wonder if folks would want two more for
>> slightly nicer working with floating-point numbers, being ways to get
>> inf and NaN.
>>
>> I could write up a PPC on this but honestly it's barely 5 minutes to
>> actually just implement it in a PR - thoughts on whether I should just
>> do it?
>
>
> One potential problem here is "how does it interact with
> bigint/bignum/bigrat".
>

These values already exist so I would imagine the same way as if you ended
up passing one of them to a bigint constructor. (which appears to result in
an object that just stringifies to "inf" or "NaN")

-Dan

tir. 23. jan. 2024 kl. 20:58 skrev Dan Book <grinnz@gmail.com>:
>
> On Tue, Jan 23, 2024 at 2:54?PM Leon Timmermans <fawaka@gmail.com> wrote:
>>
>> One potential problem here is "how does it interact with
>> bigint/bignum/bigrat".
>
> These values already exist so I would imagine the same way as if
> you ended up passing one of them to a bigint constructor.

Not quite. Currently, bigint/bigfloat/bigrat/bignum have no
support for "Inf" and "NaN", since Perl itself has no support for
Inf and NaN as numeric literals. However, adding support for Inf
and NaN in big(int|float|rat|num) is trivial, since
Math::Big(Int|Float|Rat) already support Inf and NaN.

As a side remark; numeric literals can't be passed to the
constructors directly. For example, a numeric literal 0377 should
be converted to a Math::Big* representing the value decimal 255,
but the Math::Big* constructors convert "0377" into decimal 377
under the rule that trailing zeros are ignored.

> (which appears to result in an object that just stringifies to
> "inf" or "NaN")

Yes, unfortunately, "inf" and "NaN" are used rather than "Inf" and
"NaN" (or "inf" and "nan"), but I believe it has always been like
this, and I haven't dared changing it.

Peter

>

On Tue, 23 Jan 2024 at 20:58, Dan Book <grinnz@gmail.com> wrote:
>
> On Tue, Jan 23, 2024 at 2:54?PM Leon Timmermans <fawaka@gmail.com> wrote:
>>
>> On Mon, Jan 22, 2024 at 9:07?PM Paul "LeoNerd" Evans <leonerd@leonerd.org.uk> wrote:
>>>
>>> Since we now have `true` and `false` builtins, in addition to the
>>> ever-present `undef`, I wonder if folks would want two more for
>>> slightly nicer working with floating-point numbers, being ways to get
>>> inf and NaN.
>>>
>>> I could write up a PPC on this but honestly it's barely 5 minutes to
>>> actually just implement it in a PR - thoughts on whether I should just
>>> do it?
>>
>>
>> One potential problem here is "how does it interact with bigint/bignum/bigrat".
>
>
> These values already exist so I would imagine the same way as if you ended up passing one of them to a bigint constructor. (which appears to result in an object that just stringifies to "inf" or "NaN")

It should stringgifie to -inf and -NaN too, if that was the input - as
per IEEE754-2008!!

Dan
--
Dan Shelton - Cluster Specialist Win/Lin/Bsd

ons. 24. jan. 2024 kl. 06:00 skrev Dan Shelton <dan.f.shelton@gmail.com>:
>
> On Mon, 22 Jan 2024 at 21:07, Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
> >
> > Since we now have `true` and `false` builtins, in addition to
> > the ever-present `undef`, I wonder if folks would want two
> > more for slightly nicer working with floating-point numbers,
> > being ways to get inf and NaN.
>
> INF and NAN come as INF, NAN, -INF, -NAN.

The two most common types of NaNs are

- signaling NaN, sometimes written as sNaN
- quiet or non-signaling NaN, sometimes written as qNaN

I don't think I have ever seen a -NaN. In my current environment
(Cygwin) a NaN is actually encoded with a sign bit indicating a
negative value. As you can see, the sign bit is 1, indicating a
negative value:

$ perl -wle '$inf = 1e99**1e99; $nan = $inf - $inf; print unpack "B*",
pack "d>", $nan'
1111111111111000000000000000000000000000000000000000000000000000

> Also, in IEEE754-2008 it is mandatory to support -0, zero with a
> minus sign. That is used for example to see from which direction
> rounding was done.

In my environment (Cygwin), both positive and negative zero are
supported, but both a printed as 0. Anyway, this thread is
primarily about about Inf and NaN.

Peter