Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^5: What will scientific computing in Perl 6 look like?

by moritz (Cardinal)
on Jul 15, 2008 at 08:08 UTC ( #697663=note: print w/ replies, xml ) Need Help??


in reply to Re^4: What will scientific computing in Perl 6 look like?
in thread What will scientific computing in Perl 6 look like?

Well, Perl 6's type system has difficulties with respect to numeric types, because they don't form a nice hierarchy. Luckily we have roles, and thus can have a type of all (scalar) numeric types without pressing them into a hierarchy.

Implementing the numeric types correctly is a bit tricky, but the fact remains that the user (aka Perl 6 programmer) can simply add (or override) operators for each pair of types. If one of them is always a user-defined one you can guarantee no clashes with existing semantics.

So I don't see how Perl 6 isn't a solution wrt to adding new numeric types to the language - would you care to elaborate?


Comment on Re^5: What will scientific computing in Perl 6 look like?
Re^6: What will scientific computing in Perl 6 look like?
by TimToady (Parson) on Jul 15, 2008 at 16:31 UTC
    I believe the book's qualms about calling that a solution involve the possibility of a combinatorial explosion if the language forces you do define all possible pairings, and the opacity and artificial stupidity of the solution if the computer is attempting to use artificial intelligence to second-guess the programmer's ideas of what should be intuited when types are not arrangeable in a simple "tower".

    Of course, this does not stop us from trying to solve the problem anyway... :)

      Exactly.

      If you limit yourself to a few numeric types, the problem won't seem to be that big a deal. If you know the long list of numeric types that mathematicians have (including many number of parametrized families of numeric types), it starts to become harder. Particularly when the answer has to be a different type than either operand (eg a Gaussian integer plus a rational number is generally a Gaussian rational).

        I think that's a problem with mathematics, not with programming languages. When you define a new type of number, and you want to be able to use it in arithmetic operations with other numbers, you have to define what the outcome will be.

        Mathematicians are a bit sloppy about this sometimes because they except you to know what the right thing is, but if they aren't sloppy have to go through the same motions as somebody who writes a class for a new numeric type in Perl 6.

        So of course you are right in the sense that Perl 6 doesn't solve a problem that's not yet solved in mathematics, but I think it might be a bit too optimistic to really expect that ;-)

        Of all the Perl programs written, how many will use Gaussian numbers?

        Or look at it another way. How many Perl programs will make use of all that "long list of numeric types that mathematicians have"?

        The vast majority of Perl programs will use nothing more than the basics, and the few that do will each probably only use one or two of those exotics. So long as whatever packages are used to provide the required conversions between the exotic types they implement and one of the built in basic types, where applicable, everyone is happy.

        Conclusion: The theoretical problem of a combinatorial explosion of type conversions never arises.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://697663]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (7)
As of 2014-09-23 08:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (211 votes), past polls