Elysian Shadows

Rebornxeno wrote:I never realized how spoiled I am working with c++ for windows all the time, all I gotta do is some #include and bam all the windows functions available to me. With lisp I have to make all these foreign function definitions and stuff... Anyone reading this know of a way to go around an os? As in, making a window without having to use the windows api. I even use the windows api just for accessing the screen buffer so I can't even do that to just draw straight to the screen.

There are two ways to make a window without using the windows api: 1) don't use windows (you'll still have to use another API though) or 2) use a library that, in turn, uses the windows api.

It seems to me that you might not want your entire application to be lisp; you may want to use lisp for the AI, but embed it in a C/++ application for actual interaction with the user. I'm not sure how you'd do that, but it seems like a better idea than trying to do window management from within lisp

Well how does the os make a window then? Or how does it control what gets displayed to the screen. If I can get that low level control to the screen that the os uses for all its graphical stuff, surely I can make a window without needing the os. Google isn't helping in this regard however...

You're digging far too deep here. You want to use the OS, because the OS handles all the nasty device interactions for you. Especially with a high-level language like lisp, the last thing you want to do is override the OS.

A google search for managing windows in lisp only got me an x11 window manager written in lisp (not what you're looking for), and a search for embedding lisp got me this: http://ecls.sourceforge.net/. I don't know if it's really what you want, but it's what I found.

This all seems like a bit of a hassle. Why dynamically modify your own code? Aren't there plenty of learning algorithms out there that don't require the treatment of code as data? Although treating code as data can be useful, it's not how computers are designed to work on the large scale, so you'll just be fighting the platform you're trying to use. Treat data as data, and use that data to control your code. It can effectively do the same thing, but it ends up being much less messy than self-modifying code.

Is that an elaborate way of saying you don't know? You are right though that I most likely wouldn't use it, as the fli and ffi stuff isn't too bad. I almost like it, almost. Though I'd still like to know how they manage to do it, for curiosity's sake.

Ginto8 wrote:Why dynamically modify your own code? Aren't there plenty of learning algorithms out there that don't require the treatment of code as data? Although treating code as data can be useful, it's not how computers are designed to work on the large scale, so you'll just be fighting the platform you're trying to use. Treat data as data, and use that data to control your code. It can effectively do the same thing, but it ends up being much less messy than self-modifying code.

Way to miss the ENTIRE point of studying artificial intelligence bro.. There are boatloads of reasons to treat code as data in his area of interest, and it's NOT a new idea. Again Lisp being case-in-point, John McCarthy released it in 1958 which is probably before your parents were born. Lisp is no the only choice however, Python is also in fairly wide use as an AI language today.

Here is an article on Python's usefullness in regards to AI research:
http://programmer-art.org/articles/rese ... telligence

Surely there are plenty more great resources out there if you're willing to take the time to find them.

Well dandymcgee, you're obviously more educated on this one than I am

The main reason I was suggesting using a more data-driven approach is that C and other statically-compiled languages have issues with modifying their own code, so I was suggesting having the code be less concretely "code". If you used data (for example, a genetic learning algorithm's genome) to control how the code behaves, and then modify that data, making the code act in a different way, you accomplish the same goal (treating "behavior", whether that behavior is code or not, as data) while avoiding the messiness of self-modifying programs written in less-dynamic languages.

But that's assuming that he's trying to find behavior as opposed to having a learning algorithm literally write a program. If that's what he wants, the set of difficulties is entirely different.

Please let me know if I'm full of shit; I'd prefer to learn than remain so.

I thought about using python, but it has a few drawbacks; no macros and having to be fully interpreted. Oh and great news with the foreign function stuff, there is an implementation of lisp, Corman lisp, that's already loaded with all the windows functionality needed. So I don't even have to finish writing the functions myself!

In that link he talks about ELIZA, and going through the examples package in my cl folder is the ELIZA program :P

Yeah c sucks at modifying itself, thats why I'm using lisp for now lol.

Ginto8 wrote: The main reason I was suggesting using a more data-driven approach is that C and other statically-compiled languages have issues with modifying their own code, so I was suggesting having the code be less concretely "code".

Which is exactly why he shouldn't use C.

Rebornxeno wrote:Yeah c sucks at modifying itself, thats why I'm using lisp for now lol.

And he isn't.. problem solved.

Ginto8 wrote: But that's assuming that he's trying to find behavior as opposed to having a learning algorithm literally write a program. If that's what he wants, the set of difficulties is entirely different.

Absolutely. The term "AI" is very broad and all-inclusive. I recommended Lisp and Python because of their extreme flexibility when it comes to language processing.

However, not all AI research has to do with processing language. For instance, one might consider path-finding a subject in the field of AI. In this case, you may not find Lisp to be nearly as helpful.

Again, I recommended Lisp for the theoretical research aspect of it. This means coming up with test inputs and generating their corresponding outputs. I most certainly wouldn't recommend using Lisp to create a 2D platformer. Though the enemy requires some form of AI to determine how best to attack the player, this is an extraordinarily small application of AI and is far from the main focus of the program.

If you're interested in using Common Lisp for AI, you might want to take a look at Peter Norvig's Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp.

http://norvig.com/paip.html

I'd recommend picking up The Dragon Book (Compilers: Principles, Techniques, and Tools) or another similar book on compilers. Also, study modern Java Virtual Machines like Oracle's HotSpot. It uses JIT compilation but only for segments of bytecode where the benefit of running native code greatly outweighs the time it takes to JIT compile.

Soma wrote:I'd recommend picking up The Dragon Book (Compilers: Principles, Techniques, and Tools) or another similar book on compilers. Also, study modern Java Virtual Machines like Oracle's HotSpot. It uses JIT compilation but only for segments of bytecode where the benefit of running native code greatly outweighs the time it takes to JIT compile.

TBCH, I just finished a class in compilers using the "Dragon Book" and have to say, it's the most 'dense' book I have read in a long time..

short wrote:

Soma wrote:I'd recommend picking up The Dragon Book (Compilers: Principles, Techniques, and Tools) or another similar book on compilers. Also, study modern Java Virtual Machines like Oracle's HotSpot. It uses JIT compilation but only for segments of bytecode where the benefit of running native code greatly outweighs the time it takes to JIT compile.

TBCH, I just finished a class in compilers using the "Dragon Book" and have to say, it's the most 'dense' book I have read in a long time..

I'm not a huge fan of the few compiler books I've come across really. You got any recommendations?