Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Lisp BigO

Name: Anonymous 2012-01-02 16:07

How fast is:
 
(cdr list...)

Name: Anonymous 2012-01-02 18:57

Suppose that we have a method of always inferring the type of a variable in a dynamic language. And suppose we would like to know if an algorithm, A will halt or not. We can construct a new algorithm, B

function B()
  if(halts(A))
    a = "lol, I'm a string"
  else
    a = 1337
  end
  print(a)
end

We use the method to find out what the type of a will be when it is printed. If a is a string, then A halts. If a is an int, then A will not halt.

Name: Anonymous 2012-01-02 18:58

>>26
Again, you have zero clue what you're talking about. Now tell me what you do for a living? Given the fact you seem totally clueless about what you're talking about, I'm willing to bet you do tech support at the very best.

Name: Anonymous 2012-01-02 19:02

>>27
*as to what*

Name: Anonymous 2012-01-02 19:04

>>26
Did anyone claim type inference for dynamicly typed languages? Compilers tend to do it for trivial cases, but of course it won't do it for any non-trivial cases. Also, a static language (like ML) could just solve this problem by making a's type like this: type string_or_int = S of string | B of int;;, no problem there, it's limited enough for type-inference, but not free enough for dynamic typing.

Name: Anonymous 2012-01-02 19:07

>>27

yeap, you're right, I did it the wrong way. Hold on...

Name: Anonymous 2012-01-02 19:09

>>30
No. The only thing you need to do is shut up.

Name: Anonymous 2012-01-02 19:10

>>29

mr >>27-san didn't like my example of wrapping primitives in tagged objects, so I was just suggesting that type inference is not possible in general. That proof is wrong though, let me try again...

Name: Anonymous 2012-01-02 19:11

>>27
No... he's right. By this time you guys are arguing about static type inference in a dynamically typed language, which is insane on its face, but >>26-kun isn't full of shit, just irrelevant.

Name: Anonymous 2012-01-02 19:12

>>32
And you still haven't told us what you do for a living. Given your subpar technical responses on here, again, I'm willing to bet you work some shit hourly general labor labor.

Name: >>32 2012-01-02 19:15

naw, wait, I think the proof is correct. >>27-san, what do you find wrong with the proof?

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-02 19:20

>>35
He missed two cases,

Name: Anonymous 2012-01-02 19:24

>>36
I must know...

Name: Anonymous 2012-01-02 19:25

>>26
Suppose that we have a method of always inferring the value of a variable in a static language. And suppose we would like to know if an algorithm, A will halt or not. We can construct a new algorithm, B

function B()
  if(halts(A))
    a = 1
  else
    a = 0
  end
  print(a)
end

We use the method to find out what the value of a will be when it is printed. If a is 1, then A halts. If a is 0, then A will not halt.

Name: Anonymous 2012-01-02 19:28

>>29
Heh, the ML solution involves type tags anyway.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-02 19:29

>>37
You need the additional case(s) because it's proof by contradiction. However, the minimum wage dipshit that posted the proof only supplies a really sloppy version of one case.

Name: kodak_gallery_programmer !!kCq+A64Losi56ze 2012-01-02 19:31

>>38
You need the other case in order to arrive at the contradiction you dipshit. Cripes. Please shut up and go read a book.

Name: Anonymous 2012-01-02 19:35

ENTERPRISE JAVA SOLUTION


public static void print(Object o) {
  System.out.printf("%s",o.toString());
}

Name: Anonymous 2012-01-02 19:48

>>40
yeah it was sloppy. Lemme try again.

Suppose for the sake of contradiction that we have the ability to always predict the type of a variable in a dynamic language. We will reach a contradiction by showing that the haling problem is decidable. Suppose that halts is a function that takes an algorithm as its input and will return true if A will halt, and false if A will not halt. Note that the halts function need not halt itself. Let A be an arbitrary algorithm. Define B to be the following:

function B()
  if(halts(A))
    a = "lol I'm a string"
  else
    a = 1337
  end
  print(a)
end

We can now implement a special Halts function, that will halt on all inputs:

function Halts(A)
  function B()
    if halts(A) then
      a = "lol I'm a string"
    else
      a = 1337
    end
    print(a)
  end
  a_predicted_type = predict_type_when_printed(B, 'a')
  if a_predicted_type == 'string' then
    return true
  else
    return false
  end
end

Halts will halt on all inputs, as the only routines it only calls the check_the_type function, which is assumed to be decidable. Halts correctly decides when algorithms will halt or not because halts correctly indicates when an algorithm will halt or not (or does it)***. So Halts is a solution to the halting problem which halts on all inputs, which implies that the halting problem is decidable, and we have reached a contradiction. Therefore the initial assumption that predicting a type of a variable in a language is decidable, must be false.

I think that would do it, although, *** what if halts(A) doesn't halt? Then its return value is not defined right? So what would be the behavior of the check_type function, when it is checking the type of a variable at a point in the algorithm that can never be reached? There's probably a better way of doing this.

Name: >>43 2012-01-02 19:56

It might be better to first show that determining whether a statement is reached or not is undecidable, and then use that instead. Then you could reduce it to determining whether the statement that changes a from an int to a string is executed or not.

Name: Anonymous 2012-01-02 20:44

>>43
And this still doesn't support any of your idiotic assertions. Please do us all a favor and go kill yourself.

Name: Anonymous 2012-01-02 20:59

>>45
got banned from irc again huh

Name: Anonymous 2012-01-02 21:03

>>46
/prog/ has an irc?

oh lordy i can only imagine the retardation in that room, kodak, frozenvoid,tripfags

Name: Anonymous 2012-01-02 21:18

Name: Anonymous 2012-01-02 21:28

>>45

Alright, I'll do it better this time.

Part one, showing that determining whether or not a statement is executed is undecidable. Suppose for the sake that determining whether or not a statement is executed is decidable. We will reach a contradiction by showing that the halting problem is decidable. Here is the solution:

function halts(A)
  function B()
    A()
    execute_special_statement()
  end
  statement_would_be_executed = inspect_B_and determine_if_execute_special_statement is executed
  return statement_would_be_executed
end

If A halts, then execute_special_statement will be executed, and halts(A) will return true. If A does not halt, then execute_special_statement would never be executed, and halts(A) will return false. Because the process of determining whether execute_special_statement will halt or not is assumed to be a decider, then we have that halts is also a decider. By producing a solution to the halting problem that halts on all its inputs we have shown that the halting problem is decidable, which is a contradiction. Hence, the problem of determining whether a statement is executed or not must be undecidable.


Part 2: Showing that perfect type prediction is undecidable. Suppose for the sake of contradiction perfect type prediction is decidable. We will reach a contradiction by showing that determining whether or not a statement is executed is decidable. Let A be an arbitrary algorithm, with a() being an arbitrary statement within A.

function A()
 ...
 a()
 ...
end

We will produce an algorithm, Executes(A,a) that will return true if a() is executed when A is ran, and false if a() is not executed when A is ran, and we will show that Executes halts on all inputs.

We will produce a new algorithm from A, called B, defined as follows:

function B()
  my_var = "lol I'm a string"
  <first chunk of code from A>
  {
    my_var = 1337
    a()
  }
  <second chunk of code from A>
  print(my_var)
end

note that my_var is a string when it is printed if and only if a() is never executed, and my_var is an int if and only if a() is executed.

function Executes(A,a)
  let B be defined in terms of A and a, as above
  my_var_type_when_printed = predict_type_when_printed(B, 'my_var)
  if my_var_type_when_printed == 'int' then
    return true
  else
    return false
  end
end

Executes is a decider, because it relies only on type prediction, which is assumed to be decidable. Executes correctly determines when a is executed within A, because my_var becomes an int if and only if a() is executed within A. So Executes is a solution to the problem to checking whether a statement is executed or not, that halts on all inputs, which shows that the problem of determining whether a statement is executed or not, is decidable, which is a contradiction. Therefore, the initial assumption of type prediction being decidable must be false.

>>47

yeap, just like every other irc channel, right?

Name: Anonymous 2012-01-02 21:36

>>47
There were/are a handful of /prog/-related channels. The few that I lurk in don't seem to have too much visibile stupidity, nor are they frequented by those characters you mention, and even if some occurs, it's not like it's hard to ban or ``mute'' someone(either ban, or +m and +v rest of the people). However, like all IRC channels, there is persistent identity (unless you try hard to avoid that, but won't really work if you're the only one interesting in doing that, in which case, just using some other protocol might be better), which leads to a different kind of community than anonymous BBSes, at best it only has people who go to both in common, but as forms of communication they are far too different to maintain a ``culture'' unaltered.

Name: Anonymous 2012-01-02 21:39

>>48
No, and i most certain don't use any social networking sites at all yet alone spyware sites.


go back to /g/ you ``faggot''.

Name: Anonymous 2012-01-02 22:20

Can (reverse <list>) be implemented using tail recursion? If yes, show how.

Answer: Yes.
(define my-reverse (lambda (l)
    (define f (lambda (l a)
        (if (null? l)
            a
            (f
                (cdr l)
                (cons (car l) a)))))
    (f l '())))

Name: Anonymous 2012-01-02 22:35

>>49
(define halts (lambda (a)
    (define f (lambda ()
        ((a) (execute-special-statement)))
    (set! statement_would_be_executed
        (and
            (inspect B)
            (determine-if-execute-special-statement-is-executed)))))

It's in Lisp. Lisp can solve the halting problem. The GC runs out of memory, and halts.

Name: Anonymous 2012-01-03 0:11

>>52

let reverse l =
    let rec rev l' l = match l with
    | [] -> l'
    | x::xs -> rev (x::l') xs
    in rev [] l;;


Now with 93% less parens.

Name: Anonymous 2012-01-03 2:25

I would write, it except it already exists: (reverse list)

Name: Anonymous 2012-01-03 3:56

>>55
It still has too many parens.

Name: Anonymous 2012-01-03 5:26

>>52
(define (reverse xs) (foldl cons '() xs))

Name: Anonymous 2012-01-04 1:31

>>56
What about #'reverse?

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List