On Fri, Oct 03, 2008 at 11:57:30PM -0400, Michael G Schwern wrote:

: What's the status of numeric upgrades in Perl 6? Is see the docs say "Perl 6

: intrinsically supports big integers and rationals through its system of type

: declarations. Int automatically supports promotion to arbitrary precision" but

: it looks like it's doing the same thing as Perl 5.

:

: $ ./perl6 -e 'say 2**40'

: 1099511627776

:

: $ ./perl6 -e 'say 2**50'

: 1.12589990684262e+1­5

:

: $ ./perl6 -e 'say 2**1100'

: inf

The status of numeric upgrades in Perl 6 is fine. It's rakudo that

doesn't do so well. ­

As another datapoint:

$ pugs -e 'say 2**40'

1099511627776

$ pugs -e 'say 2**50'

1125899906842624

$ pugs -e 'say 2**1100'

1358298529049385849­27735142835926677860­34938469317445497485­19669727813092754241­84872053920832075605­92298578262953847383­47503872554323492997­11555483428006287218­85763499406390331782­86414416468073076683­71605262231765127984­35772129956553355286­03220308038077575973­23201989850948840040­69116123084147875437­18365846746514894879­0552744165376

I don't think of Int as a type that automatically upgrades. I think

of it as an arbritrarily large integer that the implementation can in

some cases choose to optimize to a smaller or faster representation,

Larry Wall wrote:

That's good [1] to hear, thanks.

Oh don't worry, I do. I just got so flustered when I saw Rakudo do the

same thing that Perl 5 does I was worried this got lost somewhere along

the line.

[1] We need a polite way to say "less bad".

On Fri, Oct 03, 2008 at 11:57:30PM -0400, Michael G Schwern wrote:

: What's the status of numeric upgrades in Perl 6? Is see the

: docs say "Perl 6 intrinsically supports big integers and rationals

: through its system of type declarations. Int automatically

: supports promotion to arbitrary precision" but it looks like it's

: doing the same thing as Perl 5.

The status of numeric upgrades in Perl 6 is fine. It's rakudo that

doesn't do so well. ­

On Fri, Oct 03, 2008 at 11:57:30PM -0400, Michael G Schwern wrote:

: What's the status of numeric upgrades in Perl 6? Is see the

: docs say "Perl 6 intrinsically supports big integers and rationals

: through its system of type declarations. Int automatically

: supports promotion to arbitrary precision" but it looks like it's

: doing the same thing as Perl 5.

The status of numeric upgrades in Perl 6 is fine. It's rakudo that

doesn't do so well. ­

From: "Patrick R. Michaud" <pmichaud@pobox.com­>

Date: Sat, 4 Oct 2008 09:41:22 -0500

On Fri, Oct 03, 2008 at 09:47:38PM -0700, Larry Wall wrote:

Correct. I suspect that eventually the Rakudo developers will have

to develop a custom set of PMCs for Perl 6 behaviors rather than

relying on the Parrot ones.

The Parrot behavior in this case may be closer than you think. After

applying the patch below, I get the expected output from Rakudo:

rogers@rgr> ./perl6 -e 'say 2**40'

1099511627776

rogers@rgr> ./perl6 -e 'say 2**50'

1125899906842624

[...]

It does produces >300 spectest_regression­ failures, though, so I don't

claim the patch is right.

Correct. I suspect that eventually the Rakudo developers will have

to develop a custom set of PMCs for Perl 6 behaviors rather than

relying on the Parrot ones.

Hmm. My instinct would be to rely on MMD:

.sub 'infix­' :multi(Perl6Array,_­)

.param pmc a

.param pmc b

$P0 = new 'Integer'

$P0 = a

.return 'infix­'($P0, b)

.end

.sub 'infix­' :multi(_,Perl6Array­)

.param pmc a

.param pmc b

$P0 = new 'Integer'

$P0 = b

.return 'infix­'(a, $P0)

.end

This exposes an MMD bug (it runs forever), but something like this

should work once it's fixed.

Handling promotion (and demotion) between single and multi-precision

integers is fairly easy. And once you have that doing it for rationals

is basically free. Likewise promoting an Integer up to rational is

trivial and vice versa. But promotion (or demotion) between IEEE floats

and rationals is really hard and I don't know of a language that even

tries. The major problem is that the demotion from rational to IEEE

float is very lossy. In general, there are many possible distinct

rationals that convert into the same IEEE value and converting IEEE

float to the simplest rational out of that set is a very expensive

operation.. Once you're in rationals you probably never want to demote

back to IEEE (except possibly at the very end). Every language that

supports rationals, that I know of, leaves it up to the programmer to

decide whether they will be doing computations in IEEE float or

rationals and do not try to automatically convert back and forth. I

looked at thos and basically gave up when I was writing the perl 5

Bigint and Bigrat packages.

Before you discuss implementations, you should define exactly what rules

you are going to use for promotion and demotion between the various types.

4.5207196*10**30 -> 45207196*10**37

Patrick R. Michaud wrote:

I think it would be better for things like unlimited-precision­ integers

and rationals to be Parrot generic PMCs rather than Perl 6 specific

ones, since there are other languages that also have unlimited-precision­

numbers (for example Python afaik) and it would be better to have a

common implementation. Several popular languages have unlimiteds now,

and more are coming over time.

Note that just as integers are naturally radix independent, the unlimited

rationals should be too, and the latter can compactly represent all

rationals as a triple of integers corresponding roughly to a (normalized)

[mantissa, radix, exponent] triple; with that approach you also get

unlimited floats for free, so no reason to make floats an exception where

they aren't unlimited where integers and other rationals are; after all,

what is a float or scientific notation than just another notation for a

rational value literal.

Note that just as integers are naturally radix independent, the unlimited

rationals should be too, and the latter can compactly represent all

rationals as a triple of integers corresponding roughly to a (normalized)

[mantissa, radix, exponent] triple; with that approach you also get

unlimited floats for free, so no reason to make floats an exception where

they aren't unlimited where integers and other rationals are; after all,

what is a float or scientific notation than just another notation for a

rational value literal.

I want to stress this last point. We have the three types Int, Rat and Num.

What exactly is the purpose of Num? The IEEE formats will be handled

by num64 and the like. Is it just there for holding properties? Or does

it do some more advanced numeric stuff?

Another matter is how to represent irrationals. With IEEE floats which are

basically non-uniformly spaced integers imprecession is involved anyway.

But sqrt(2) is a ratio of two infinite integers. How is that handled? Here

I see a way for Num to shine as a type that also involves lazy approximations.

But then we need a way for the programmer to specify how these approximations

shall be handled.

I want to stress this last point. We have the three types Int, Rat and Num.

What exactly is the purpose of Num? The IEEE formats will be handled

by num64 and the like. Is it just there for holding properties? Or does

it do some more advanced numeric stuff?

trivial and vice versa. But promotion (or demotion) between IEEE floats

and rationals is really hard and I don't know of a language that even

tries. The major problem is that the demotion from rational to IEEE

float is very lossy. In general, there are many possible distinct

rationals that convert into the same IEEE value and converting IEEE

float to the simplest rational out of that set is a very expensive

operation.. Once you're in rationals you probably never want to demote

back to IEEE (except possibly at the very end). Every language that

supports rationals, that I know of, leaves it up to the programmer to

decide whether they will be doing computations in IEEE float or

rationals and do not try to automatically convert back and forth. I

looked at thos and basically gave up when I was writing the perl 5

Bigint and Bigrat packages.

Before you discuss implementations, you should define exactly what rules

you are going to use for promotion and demotion between the various types.

Studiously ignoring that request to nail down promotion and demotion, I'm

going to jump straight to implementation, and ask:

If one has floating point in the mix [and however much one uses rationals,

and has the parser store all decimal string constants as rationals, floating

point enters the mix as soon as someone wants to use transcendental functions

such as sin(), exp() or sqrt()], I can't see how any implementation that wants

to preserve "infinite" precision for as long as possible is going to work,

apart from

storing every value as a thunk that holds the sequence of operations that

were used to compute the value, and defer calculation for as long as

possible. (And possibly as a sop to efficiency, cache the floating point

outcome of evaluating the thunk if it gets called)

Nicholas Clark

At 18:06 +0200 10/5/08, TSa (Thomas Sandla ) wrote:

Symbolic algebra packages handle irrationals like sqrt(2) with a "root

As for unlimited precision in floats I'd rather see a floating point

TSa (Thomas Sandla ) wrote:

"Int", "Rat" [1] and "Num" are all human types. They work like humans were

taught numbers work in math class. They have no size limits. They shouldn't

lose accuracy. [2]

As soon as you imply that numbers have a size limit or lose accuracy you are

thinking like a computer. That's why "num64" is not a replacement for "Num",

conceptually nor is "int64" a replacement for "Int". They have limits and

lose accuracy.

[2] "Num" should have an optional limit on the number of decimal places

it remembers, like NUMERIC in SQL, but that's a simple truncation.

If one has floating point in the mix [and however much one uses rationals,

and has the parser store all decimal string constants as rationals, floating

point enters the mix as soon as someone wants to use transcendental functions

such as sin(), exp() or sqrt()], I can't see how any implementation that wants

to preserve "infinite" precision for as long as possible is going to work,

apart from

storing every value as a thunk that holds the sequence of operations that

were used to compute the value, and defer calculation for as long as

possible. (And possibly as a sop to efficiency, cache the floating point

outcome of evaluating the thunk if it gets called)

I disagree.

For starters, any "limit" built into a type definition should be defined

not as stated above but rather with a simple subtype declaration, eg

"subtype of Rat where ..." that tests for example that the Rat is an

exact multiple of 1/1000.

Second, any truncation should be done at the operator level not at the

type level; for example, the rational division operator could have an

optional extra argument that says the result must be rounded to be an

exact multiple of 1/1000; without the extra argument, the division

doesn't truncate anything.

Any numeric operations that would return an irrational number in the

general case, such as sqrt() and sin(), and the user desires the result

to be truncated to an exact rational number rather than as a symbolic

number, then those operators should have an extra argument that

specifies rounding, eg to an exact multiple of 1/1000.

Note, a generic numeric rounding operator would also take the "exact

multiple of" argument rather than a "number of digits" argument, except

when that operator is simply rounding to an integer, in which case no

such argument is applicable.

Note, for extra determinism and flexibility, any operation

rounding/truncating­ to a rational would also take an optional argument

specifying the rounding method, eg so users can choose between the likes

of half-up, to-even, to-zero, etc. Then Perl can easily copy any

semantics a user desires, including when code is ported from other

languages and wants to maintain exact semantics.

Now, as I see it, if "Num" has any purpose apart from "Rat", it would be

like a "whatever" numeric type or effectively a union of the

Int|Rat|that-symbol­ic-number-type|etc types, for people that just want

to accept numbers from somewhere and don't care about the exact

semantics. The actual underlying type used in any given situation would

determine the exact semantics. So Int and Rat would be exact and

unlimited precision, and maybe Symbolic or IRat or something would be

the symbolic number type, also with exact precision components.

Darren Duncan wrote:

That seems like scattering a lot of redundant extra arguments

around. The nice thing about doing it as part of the type is

you just specify it once.

But instead of truncating data in the type, maybe what I want

is to leave the full accuracy inside and instead override

string/numification­ to display only 2 decimal places.

Yes, this is very important for currency operations.

That sounds right. It's the "whatever can conceivably be

called a number" type.