Rationalizing numeric types

[yary]

Thinking over my programming career, there were a few occasions I had to
spend time working around floating point errors, and it was a nuisance.
There were even fewer times when I worked with transcendental numbers-
programs dealing with geometry or tones or logarithmic scales- and those
times, floating point was good enough.

Which is to say, Perl 6's Rats would have solved my nuisance issues, and I
would not have appreciated exact types for irrational numbers in my tasks
to date.

Still, I couldn't resist thinking about them and web-searching on them a
bit more, and here's my brain-dump. Periodic continued fractions
 can represent any quadratic
root
.
Haskel has this package implementing a quadratic irrational type
,
and it can translate between those and continued fractions. ... here is a
decent intro to continued fractions
.

That's a comprehensive answer for square roots of rationals, but not
for transcendental
numbers . My math is
not so hot, but perhaps a generalized continued fraction
 type could
perfectly represent transcendental constants like pi and e, with trig and
log/exponentiation functions using them. Then Perl 6 could get this famous
relationship *exactly right*:

say 1 + e ** (pi * i)

... though I suspect it really does take a symbolic math package to get all
combinations of the trig & exponential functions right

.

-y

Re: Rationalizing numeric types

[Solomon Foster]

Yary,

There already is a Perl 6 continue fractions module.  Spoiler alert: it
doesn't work in the least.  But I'd be happy to give you a commit bit.

I don't think we should even begin to think about including something like
that in the Perl 6 core before we have a complete, working implementation
in a module.

Frankly, I'm much more concerned with making the math functions we already
have support the types we already have.  For instance, right now most such
operations use standard floating point doubles under the hood.  The exact
range of Ints and Rats vastly exceeds that of doubles, so this means that
(at least in theory) there are perfectly good mathematical answers we could
return that we're not.

So, for instance, according to Wolfram Alpha, ln(3 * 10 ** 500)
= 1152.391158785690951700390972579104629505198234872209237468398...  On the
other hand, if I give Rakudo that same problem (switch ln to log), we get
"Inf", because 3 * 10 ** 500 cannot be presented as a double.

That said, I'm not terrible concerned about that problem, either.  But if
you were hankering for a Perl 6 math problem to work on, IMO it would be a
much better one than trying to exactly represent irrational numbers.


On Mon, Jun 22, 2015 at 1:41 PM, yary  wrote:

> Thinking over my programming career, there were a few occasions I had to
> spend time working around floating point errors, and it was a nuisance.
> There were even fewer times when I worked with transcendental numbers-
> programs dealing with geometry or tones or logarithmic scales- and those
> times, floating point was good enough.
>
> Which is to say, Perl 6's Rats would have solved my nuisance issues, and I
> would not have appreciated exact types for irrational numbers in my tasks
> to date.
>
> Still, I couldn't resist thinking about them and web-searching on them a
> bit more, and here's my brain-dump. Periodic continued fractions
>  can represent any quadratic
> root
> .
> Haskel has this package implementing a quadratic irrational type
> ,
> and it can translate between those and continued fractions. ... here is a
> decent intro to continued fractions
> 
> .
>
> That's a comprehensive answer for square roots of rationals, but not for 
> transcendental
> numbers . My math is
> not so hot, but perhaps a generalized continued fraction
>  type could
> perfectly represent transcendental constants like pi and e, with trig and
> log/exponentiation functions using them. Then Perl 6 could get this famous
> relationship *exactly right*:
>
> say 1 + e ** (pi * i)
>
> ... though I suspect it really does take a symbolic math package to get
> all combinations of the trig & exponential functions right
> 
> .
>
> -y
>



-- 
Solomon Foster: colo...@gmail.com
HarmonyWare, Inc: http://www.harmonyware.com

Re: Language design

[Darren Duncan]

On 2015-06-16 2:15 PM, The Sidhekin wrote:

On Tue, Jun 16, 2015 at 10:52 PM, Michael Zedeler  wrote:
...and unpredictable performance is a cost you're willing to pay?

   I don't write performance-critical applications, but even if I did, why would
I prefer getting the wrong answer faster?


I agree with Sidhekin and similar mentalities.

On the range between safety/correctness and speed, a good programming language / 
tool should always default to the most safe/correct option when the user doesn't 
specify where on the range they want, and leave it to the power users to 
explicitly make the trade-off when they know what they're doing.


In this case, people who explicitly want floats because of performance rather 
than exact rationals do indeed count as power users.


Normal people are more interested in not being surprised by the answers they get 
to what should be common-sense questions, such as when adding 10.3 to 14.2.


I should also point out that finance / anything to do with money is an extremely 
common use case that cares very much about math being exact, its not just 
esoteric science applications.


This all being said, I draw the line where implementing is much more complicated 
to serve esoteric cases.  So for example while exact precision rationals 
absolutely should be default / part of core, something like symbolic values eg 
exact representations of irrational numbers, are perfectly valid to, and 
probably shouldn't, be part of core.  Exact rationals are not particularly 
complicated.  Its perfectly reasonable to expect in the core that if someone 
does math that is known to deal with irrationals in general, that loss of 
precision then is acceptable.


-- Darren Duncan