Re^4: Reasons for Using Perl 6

Real world programming tends to involve functions. For instance, trigonometric functions are very common. How exactly does Perl 6 do it right? What is the domain of accurate calculations? Say, can it do simple interest calculations accurately?

Perl and speed aren't mutually exclusive. You can have a low-level module or Inline::C doing the heavy lifting and still benefit from rapid prototyping or other comforts that Perl allows.

Comment on Re^4: Reasons for Using Perl 6

Replies are listed 'Best First'.
Re^5: Reasons for Using Perl 6 by Laurent_R (Canon) on Dec 23, 2017 at 20:24 UTC
Perl 6 is using the `Rat` type to represent rational numbers, such as 1/3, 23/7, .564, etc. With such numbers, calculations made with the four basic operators are generally accurate. This is because the `Rat` type represents rationals with two integers, one for the numerator and one for the denominator. When using irrational numbers, such as square root of 2, or trigonometric functions, then Perl 6 is forced to use floating-point arithmetic and suffers from the same drawbacks as other programming languages. So Perl 6 can do simple interest calculations accurately, but for compound interest calculations, it would fall back on floating-point arithmetic (and its flaws) for most common cases (although it is often possible to work around this if needed). I agree with your point about Perl and speed not being necessarily mutually exclusive. Even though I am dealing with huge volumes of data (so speed is important to me), I have never needed to actually use things such as `Inline::C` at $work.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Reasons for Using Perl 6
by Laurent_R (Canon) on Dec 23, 2017 at 20:24 UTC

Rat

When using irrational numbers, such as square root of 2, or trigonometric functions, then Perl 6 is forced to use floating-point arithmetic and suffers from the same drawbacks as other programming languages.

So Perl 6 can do simple interest calculations accurately, but for compound interest calculations, it would fall back on floating-point arithmetic (and its flaws) for most common cases (although it is often possible to work around this if needed).

I agree with your point about Perl and speed not being necessarily mutually exclusive. Even though I am dealing with huge volumes of data (so speed is important to me), I have never needed to actually use things such as Inline::C at $work.

[reply]
[d/l]
[select]