Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re: Challenge: Simple algorithm for continuing series of integers

by BrowserUk (Patriarch)
on Oct 19, 2008 at 20:43 UTC ( [id://718086]=note: print w/replies, xml ) Need Help??


in reply to Challenge: Simple algorithm for continuing series of integers

As a purely intellectual challenge, provided that you recognise that any solution will be severally restricted in the sequences it will recognise, and will inevitably mis-categorise some high 90s percentage of the possiblities, then it is vaguely interesting.

As an expenditure of Perl6 development time, it is a complete waste.

This is because it would take an immense amount of effort (and code) to do anything more than a 'piss poor job'. And even if that effort was expended and the code incorporated, and it was possible for the computer to intuit the sequence behind (say):

my @sequence = 1, 18, 4, 13 .. *;

The human being (that mythical maintanence programmer), will unlikely be able to do the same!

And almost everyone is going to code that as:

my @sequence = 1, 18, 4, 13 .. *; ## dartboard

Which means it would be far simpler and far better to avoid the "magical" and just incorporate (or have a module that supplies), a few pre-defined sequences like:

my @odds = ODDS; ## or LAZY_ODDS or LAZY_ODDS_FROM( 11 ) my @evens = EVENS; my @board = DARTBOARD;

A simple module that supplies a bunch of these 'well named sequences' would be easy to code and infinitely extensible and keep the need for potentially buggy and always limited 'magical' code out of the core.

Building, testing and verifying a module that contained/exported the entire OEIS database manually would probably take far less time, than trying to write code to divine 1% of them. And it probably would not take a great deal of effort to write code to query the OEIS database directly, and generate the module automatically.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^2: Challenge: Simple algorithm for continuing series of integers
by JavaFan (Canon) on Oct 19, 2008 at 21:55 UTC
    I fully agree.

    Note that "magical guessing" the sequence makes it quite hard to improve the ... * operator.

    Suppose in perl 6.0, you have such a magical ... * operator, that "guesses" how a sequence continues. Now, for 6.1, someone comes up with an idea to "improve" the operator, allowing it to "better guess" certain classes of sequences. But how would you know such an improvement wouldn't break someone codes? The "improvement" is going to change the guess of certain start sequences (otherwise, there wouldn't be such an improvement). But someone else may be quite content with the 6.0 guess. So this isn't an operator that could easily "tune" itself over releases - unless you don't care about backwards compatability.

      It would be relatively easy to make a rule that new guessers are allowed to work only on the unguessable residue left over from previous versions. And of course, there's little reason to install guessers that would be opaque to most readers, and I expect that the writer of the program should certainly name the series or the generator function such that it is clear to the reader.

      So actually, I was serious in my proposal that we make it easy to pull well-named generator functions from a well-known database, and then the numbers on the front are just examples of the first few values in the series--the real meat is in the function name. But a name is a useful abstraction, compared to forcing people to write complicated closures that might be just as unreadable as * is. And the standard function derived in a standard fashion may well be more optimizable than the user-written equivalent, where various idiosyncratic usages may make optimization difficult.

      So that's why the spec currently limits * guessing to some very simple cases, and I have no problem with taking a very conservative approach to adding more guessers.

        compared to forcing people to write complicated closures that might be just as unreadable as * is. ... the spec currently limits * guessing to some very simple cases

        If the guesser is limited to simple cases, then the closures it would replace, would be simple also. By the time you get to the point where the closure would give any reasonably competent programmer a problem to understand, the chances of the guesser, guessing correctly are close to nil.

        Even the simplest input to the guesser, say: 1,2,3 currently elicits a gnat's genitalia off of 13,000 matches at the OEIS.

        Adding a fourth term 4 cuts that to 5,500; a fifth gets you 3,500; a 6th, 2,500; a 7th, 2,000; an 8th 2,000. And you're still close to 1,500 by the time you have specified the first 9 terms.

        I didn't keep going to see how many leads you'd have to specify to uniquely identify even this simplest of sequences, but I tried a few others:

        1. 1,4,9,16,25 - 125 possibles.
        2. 1,2,4,8,16 - 346 possibles.
        3. 1,3,5,7,9 - 233 possibles.
        4. 2,4,6,8,10 - 213 possibles.
        5. 1,10,100,1000 - 36 possibles.

        It's frankly hard to see the win from having a "simple" guesser. And hard to see the possibility of something more accurate.

        Especially when it would be so cheap and simple to provide the top ten or 100 most common sequences named as built-ins, or in a core module.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re^2: Challenge: Simple algorithm for continuing series of integers
by Perlbotics (Archbishop) on Oct 19, 2008 at 22:54 UTC

    Well, I like the challenge as is, but I also think that the magical whatever * has not much practical use - or I cannot imagine one yet but for the simplest sequences.

    Which means it would be far simpler and far better to avoid the "magical" and just...
    Agreed, there would be too much room for ambiguity. Although TIMTOWTDI is part of the philosophy (* vs. {...}), I guess we will finally end with YABP (BP=best practice):

    The Series Operator ...

    • Never use the magical whatever (*).
    • Define arithmetic and geometric series with an explicit closure.

    But it is late and my visionary powers are dwindling ... ;-)

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others learning in the Monastery: (2)
As of 2024-04-24 23:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found