An interview with Larry Wall (LinuxVoice)

Posted Jul 18, 2015 6:12 UTC (Sat) by epa (subscriber, #39769)
In reply to: An interview with Larry Wall (LinuxVoice) by Cyberax
Parent article: An interview with Larry Wall (LinuxVoice)

There is a third choice other than binary (which as you say can never store fractions like 0.1) or decimal (which works fine for 0.1, but cannot store 1/3). Many languages have a rational number type which can store all numbers expressible as A/B where A and B are integers. I think this is what Perl 6 uses by default and what the other poster was referring to.

An interview with Larry Wall (LinuxVoice)

Posted Jul 22, 2015 17:00 UTC (Wed) by salimma (subscriber, #34460) [Link]

And it's the default in many Lisps too

An interview with Larry Wall (LinuxVoice)

Posted Jul 22, 2015 17:53 UTC (Wed) by anselm (subscriber, #2796) [Link] (10 responses)

So you would presumably use 22/7 (or something like it) for π?

An interview with Larry Wall (LinuxVoice)

Posted Jul 22, 2015 18:33 UTC (Wed) by rsidd (subscriber, #2582) [Link] (9 responses)

It would be silly to default to ratios of integers. Technically every floating point number on a computer is a rational number. The issue is merely that what is a terminating decimal, like 0.1, need not be a terminating binary, and therefore decimal arithmetic translated to binary and back to decimal may not be what you expect. One has two choices then -- store it as 1/10 (and store π as 314159265358979323/100000000000000000) or store it in the proper machine representation. Most of us prefer the latter and know what the tiny differences from the "expected" answer mean. From raiph's remarks it would seem perl defaults to an integer-ratio for 0.1, and possibly even for π. What puzzles the rest of us is what is the benefit of this.

A sensible thing for a language to do, if it must bother with rational numbers without being asked, would be to use a rational representation when the number is explicitly given as a ratio of integers, and the machine floating point representation otherwise. So 1/10 would be rational and 0.1 would be a float, and their product would be coerced to be a float. Lisp, for instance, does this (at least common lisp does). Python on the other hand has a fractions module that must be used if this behaviour is desired, otherwise python 2 treats 1/10 as an int (0) and python 3 treats it as a float (0.1).

An interview with Larry Wall (LinuxVoice)

Posted Jul 22, 2015 19:49 UTC (Wed) by raiph (guest, #89283) [Link]

http://blogs.perl.org/users/brad_gilbert/2014/10/perl6-pi...

may be of interest

An interview with Larry Wall (LinuxVoice)

Posted Jul 23, 2015 3:49 UTC (Thu) by raiph (guest, #89283) [Link] (7 responses)

> It would be silly to default to ratios of integers [for pi]

Yes. Pi is irrational, not rational. Any finite representation of an irrational number is going to be approximate, no matter what.

> One has two choices then -- store [0.1] as 1/10 ... or store it in the proper machine representation.

Do you see that you've indulged in circular reasoning there? You've implied that a particular machine storage representation of rational numbers is not proper simply because it isn't floating point. (And, most ironically, you're saying this despite the former being a 100% accurate representation and the latter approximate.)

> Most of us prefer [an inaccurate representation over an accurate one]

I don't think that's true. I think most of us prefer the most appropriate representation for a particular use case if it makes a difference worth making for that use case.

This often means floating point. But, for many uses of rationals, especially decimals, exact rationals are a viable choice, indeed may I say obvious choice, if you care about accuracy and simplicity.

> From raiph's remarks it would seem perl defaults to an integer-ratio for 0.1, and possibly even for π.

Yes, for 0.1.

The π value built in to Perl 6 is stored as a floating point number.

> What puzzles the rest of us is what is the benefit of this.

Almost all practical rational math, eg decimal math where input and output values have any number of digits before the decimal point and up to 15 or so digits after, will be 100% accurate by default, whereas floating point can go wrong at one digit after the decimal point, such as with `0.1 + 0.2 - 0.3`.

So, treating rationals as rationals can provide two crystal clear benefits over floating point: accuracy and simplicity.

> A sensible thing for a language to do ... would be to use a rational representation when the number is explicitly given as a ratio of integers ... So 1/10 would be rational

Right. That's what Perl 6 does and most other languages do not.

> and 0.1 would be a float

0.1 is *exactly* the same number as 1/10. It's just specified with a different notation. Given that Perl 6 supports accurate rational processing it makes little sense to treat `123456789.987654321` as anything other than 123456789987654321/1000000000.

In Perl 6, if you want floating point then you explicitly coerce, eg `Num(0.1)`, or use scientific notation, which is universally understood to be approximate, such as eg `1e-1` for 0.1 or `2.99792458e+8` for the m/s speed of light.

An interview with Larry Wall (LinuxVoice)

Posted Jul 23, 2015 4:38 UTC (Thu) by rsidd (subscriber, #2582) [Link] (6 responses)

The π value built in to Perl 6 is stored as a floating point number

Ok, so π is built in -- is every conceivable required irrational also built in? e I would guess, but what about the golden ratio, the Euler-Mascheroni constant, etc etc? What about physical constants like the electronic charge, Planck's constant, etc, which are quantities measured to some accuracy and not exact fractions?

whereas floating point can go wrong at one digit after the decimal point, such as with `0.1 + 0.2 - 0.3`.

Huh? python (both 2 and 3) give me 5.551115123125783e-17 which is 17 digits after the decimal point, not 1 digit. Who exactly cares about this? If you were building a football stadium and your calculation gave you this sort of error, you would be wrong by one-hundredth the radius of an atomic nucleus.

Given that Perl 6 supports accurate rational processing it makes little sense to treat `123456789.987654321` as anything other than 123456789987654321/1000000000.

This is exactly where we disagree. You think treating 123456789.987654321 as a fraction is reasonable and even desirable. I think it is ridiculous. When you have a number with more than two or three digits after the decimal, it is almost certainly an inexact value -- a roundoff, or a measurement, or just a ballpark figure. There is absolutely no reason to treat it as a fraction. It hurts performance and does not improve accuracy. And when people want the fraction 1/10, they will write 1/10, not 0.1. Out of curiosity, were there any mathematical/scientific programmers behind these Perl 6 decisions?

An interview with Larry Wall (LinuxVoice)

Posted Jul 23, 2015 21:59 UTC (Thu) by flussence (guest, #85566) [Link]

> Ok, so π is built in -- is every conceivable required irrational also built in? e I would guess, but what about the golden ratio, the Euler-Mascheroni constant, etc etc? What about physical constants like the electronic charge, Planck's constant, etc, which are quantities measured to some accuracy and not exact fractions?

Why do you hold Perl 6 to an absurd standard here but languages like Javascript, PHP and Python get a silent free pass?

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 4:29 UTC (Fri) by raiph (guest, #89283) [Link]

> e I would guess, but what about the golden ratio, the Euler-Mascheroni constant, etc etc? What about physical constants like the electronic charge, Planck's constant, etc, which are quantities measured to some accuracy and not exact fractions?

Without installing anything you can compile:

say e**(i*π) + 1

... and get an approximation of the right result. (Yes, that i is the square root of -1.)

But I'm pretty sure that's about the maximum extent of it at the moment ie there aren't (m)any other mathematical constants defined in the standard setting.

> > whereas floating point can go wrong at one digit after the decimal point, such as with `0.1 + 0.2 - 0.3`.

> Huh? python (both 2 and 3) give me 5.551115123125783e-17 which is 17 digits after the decimal point, not 1 digit.

I was talking about the user *input* (one decimal digit, presumed accurate) not the computer generated *output*.

> When you have a number with more than two or three digits after the decimal ...

Numbers with just one or two digits after the decimal are considered an important use case. For example, writing 4.10 to represent 4 dollars and 10 cents.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 5:53 UTC (Fri) by rsidd (subscriber, #2582) [Link] (3 responses)

Why do you hold Perl 6 to an absurd standard here but languages like Javascript, PHP and Python get a silent free pass?

I guess I wasn't clear enough. You said pi is a float because it's built-in and you know it is irrational, but if you write 3.14159265 it will be treated as the fraction 314159265/100000000. So I was asking what about other constants? If I write phi=1.61803398 why should perl assume that I have a fraction in mind? If I wanted a fraction I'd write a fraction. Other languages don't have this problem, you can define what constants you like and they will be treated as floats without coercion. In Perl 6, even you managed to get the coercion wrong here.

Numbers with just one or two digits after the decimal are considered an important use case. For example, writing 4.10 to represent 4 dollars and 10 cents.

This is a special case. For 4 dollars 10 cents, you will write 4.10, not 4.1 or 4.100. Changing how floats are treated in the language because of this special case is just weird. Counting in cents, as integers, is the sensible thing to do. But if you want smaller units than one cent (eg compound interest calculations), you want floats, not fractions.

Normally (ie when it's some other quantity, not money), when you write 4.10 you mean that it is known to a precision of two digits after the decimal point. If you write 4.1 it means you know it to 1 digit precision. If you mean the exact fraction you will write 4 1/10, not either of the above.

Anyway, enough of this argument. It is clear that you are convinced treating 4.1 or 3.14159 as fractions is the correct thing to do, will not be persuaded that it is wrong, and will not succeed in persuading others that it is right. Let us see if the Perl 6 way catches on. It's only been 15 years so far. Me, I have my eye on Julia.

An interview with Larry Wall (LinuxVoice)

Posted Jul 24, 2015 9:53 UTC (Fri) by raiph (guest, #89283) [Link]

Maybe https://en.wikipedia.org/wiki/Decimal#Decimal_fractions will persuade you, at least about decimal fractions, where I could not.

Thanks for the exchange. :)

An interview with Larry Wall (LinuxVoice)

Posted Jul 26, 2015 15:56 UTC (Sun) by flussence (guest, #85566) [Link]

I get a strong impression you aren't even reading what you're arguing against, never mind who said it.

An interview with Larry Wall (LinuxVoice)

Posted Jul 28, 2015 9:06 UTC (Tue) by dvdeug (guest, #10998) [Link]

As long as you're writing 1.61803398, I don't see any justification for saying "If I wanted a fraction I'd write a fraction." A float is a fraction with a numerator between 0 and 2^24 and denominator of 2^24, times a power of 2. 1.61803398 looks a lot more like a decimal fraction then a floating point number. Maybe an explicit exponent, like 1.61803398E0, would make it clear that you wanted a float.

It's a trade-off of speed for less user surprise, and for a language with as little stress on raw speed as Perl, that's usually a good trade off. Accuracy is probably a wash; I bet there's a lot of times where you get back the exact best answer you could get with rationals where floats are less then precise, especially for less experienced users who aren't thinking in terms of IEEE754. I don't know Perl or Perl 6, but I assume if you want floats, you can explicitly demand them.