Kurzweil does a good job. He kicks Wolfram's butt with the simple argument that his given CAs are not sufficient enough to explain higher order complexity like intelligence.
Intersting are some numbers:
At a different level, we see it in the human brain itself, which starts with only 12 million bytes of specification in the genome, yet ends up with a complexity that is millions of times greater than its initial specification5.
(..)
The genome has 6 billion bits, which is 800 million bytes, but there is enormous repetition, e.g., the sequence "ALU" which is repeated 300,000 times. Applying compression to the redundancy, the genome is approximately 23 million bytes compressed, of which about half specifies the brain's starting conditions. The additional complexity (in the mature brain) comes from the use of stochastic (i.e., random within constraints) processes used to initially wire specific areas of the brain, followed by years of self-organization in response to the brain's interaction with its environment.
Thus roughly speaking we start with some kind of 12MB programm working on a 12MB set of input data.
Pretty good work that our little cellular automata do, when acting in the physical environment eh?
In a nutshell, Wolfram found a set of simple rules for cellular automatons that lead to complex behavior.
And? The convergence map of the iteration z=z^2+c will defines an amazingly complex image, the mandelbrot set.
The second part of his discovery is the principle of computational equivalence, again, summed up, it means that passed a 'threshold' (more or less), two computational processes can be regarded as equally complex. This is a BIG claim, one that will be investigated thoroughly by mathematicians.
This is very hard to accept for me.
There is a systematic study of finite systems and their computational power - the theory of computation/recursion theory in theoretical computer science - stuff like finite automata, turing machines and so on.
And even there, people started to realize that these models map to computing machinery gouverend by the rules of classical physic and started to think what could be done with a system that makes use of quantumn mechanical effects. And came up with quantumn computing, which has been proved to be more powerful for certain problems because it can make use of an inherent parallelism. Which makes clear that even the well hung classical recursion theory is not the last word concerning computational power. (And Wolfram pretty much fits in the classical department with cellular automatons).
Worse, recursion theory reveals that pretty many problems can't be computed in finite time by a finite machine. Thus already the classical theory makes clear that much can't be done that way.
In that sense our mathematical framework is more powerful, because we can nicley describe problems in it, which Turing machines can't solve.
And now Wolfram shows up and claims that anything
can be done with cellular automata? And we should use programs rather than mathematics.
This is in direct opposition to what I personally understood from my limited exposure to theoretical computer science.
I would have expected him -like any serious scientist- to compare his theory with the framework of existing theories.
Worse, he must understand that existing computing theory very well, his buddy Chatain is a very good theorist in that field. (He is the guy who found a real number omega where it can be proved that we can't compute it's digits).
Sorry, but until I have read his book and am convinced otherwise I believe Wolfram sells his remaining reputation to sack in a lot of money,
by producing one of those mathematical coffeetable books.
It is total mystery to me, why he is not more humble.
Take Hofstaedters Goedel, Escher, Bach for instance. (Which links recursion theory, graphical recursions, musical recursions:)
This book is nice to read, has lots of
pretty pictures and nice thoughts.
But Hofstaedter doesn't claim to be Newton 2.
Why was Wolfram not satisfied with just producing a nice book like Hofstaedter did?
Why must he claim he grokked it all?
My answer is he is either gone crackers or he is selling his reputation to generate more sales.
No you can't. Except you make it a new member of your set of basic/elementary functions.
If you integrate the equations of motion (which are second order differential equations in time)
with many problem instances you will encounter situations where exactly that impossibility of simplifying the solution symbolically into a closed form / analytic solution happens.
The mathematical systems studied before had the property of "a small change to the initial conditions results in the system to reach a
later state which is very close to the state it would have reached without the pertubation", the systems were forgiving so to say (wiggle a bit, it changes a bit).
The Lorzenz systems and the weather system however have property of "a small change to the initial condition might blow the system to a latter state which might be totally different
from the state it might have reached without pertubation"
Thus these systems are just very sensitive.
(wiggle a bit and the system makes a big jump
in some direction very sensitive to the wiggle).
It is rather surprising that this came as a surprise.
We don't have an equation of gravity that works for more then two bodies of mass, but what we can do is model each pair interaction for a short time interval, modify the system accordingly, advance the timer one tick, and repeat.
WTF? What is your mathematical background to say this? (..) At worst, you have to solve sets of differential equations (..)
To say that we don't have an equation is either obtuse, naive, or a deliberate troll.
Both of you are imprecise. The first poster complained that there is no analytic solution.
Which is true.
The second poster counterargumented that it is
easy to solve by some iterative procedure.
Whic is true as well but misses the point of the first poster.
What we deal with here is symbolic integration. Derivation (finding the f' for a given function)is simple because there are easy rules that yield the formulas of derivatives, integration (finding a function f for a given f') is an art because
we quickly end up with formulas that can't be simplified with the usual set of elementary functions and we are stuck with the integrals (which might be used to define functions, like erf). Look for Liouville's theorem to see how stuff like this is proved rigorously.
The more general problem is solving differential equations, systems of differential equations both in one or several changing variables.
Most physical laws tell you how to assemble the
set of differential equations. Writing down the newtonian forces for the planets is exactly that.
Solving these systems of differential equation is again called integration.
What turns out is that you can't write down the solution to the three body problem in general as some simple combination of elementary formulas.
It is not much different from the one dimensional integration case.
No magic. Just that you can't write down the solution in a simple closed form.
The one who proved that was Henri Poincare in his celestial mechanics treatise by the way.
It just means that the space of all solutions we can construct by assembling the usual cast of simple functions we employ is not large enough to hold every function which is singled out by the solution space of a differential equation.
The first was poster wrong in that he doesn't understand that the set of differential equations plus conditions is the precise description (if we neglegt general relativty and quantum effects:)
and that solutions are necessary of approximative nature if we don't want to extend our basic set of functions by lots of integral functions.
The second poster is wrong in labeling the first poster a troll, because he didn't understand his concern about closed solutions.
Think in terms of the real world where you can inspect your intended target from a distance
and decide what the best route is to get
there. That can't happen in 2D w/o alot of
cumbersome reference (ala CLI).
Photomesa is based on the
Jazz API (a Java class lib), that implements a ZUI (zoomable user interface), a paradigm sometimes described as 2.5 D interface.
You can use the mouse to move in xy plane und with an extra key press (or possibly via mouse wheel in J2SE 1.4) you change the height of the camera in z direction.
This combined with semantic zooming, which means different levels of detail associated with the height, make for very nice user interfaces.
A similiar API has been developed at Xerox France, the
VTM library which used by the W3C for the nice
IsaViz
tool.
Despite IMHO Java still sucks regarding performance, both APIs perform very well with large object scence graphs.
Like I wrote, combined with Java's luxury 2D API, it enables us to build attractive user interfaces.
We have 10 load balanced Java based app servers. Each one is a dual processor system. I have tried running our software with BSD's native Java platform and frankly it sucked.
Which native JDK version did you compare to what Linux native JDK version?
Of course it makes only sense to compare 1.3.x with 1.3.x, 1.4.x with 1.4.x and so on.
This is because Java VM implementation evolved greatly.
I built a dual P4-2,2 GHz FreeBSD 4.5-STABLE system last week,
and it performed very good (it even made use of the hyperthreading, there were 4 virtual CPUs).
I am not trolling, I am not anything.. but the performance was almost 1/3 of what I could get on Linux with IBM's JDK.
I'm pretty sure you are not comparing the same Java JDK version.
And if your suggestion to that issue is run in Linux compatibility mode, your smoking crack.
Why? Linux compatibility mode is just a different instructuion decode/execution mode of the kernel,
each system call is translated into a FreeBSD kernel system call, the libs that are used are original Red Hat libs.
That is why I was able to run the Linux 1.3.1 JDK on the dual box.
However the Linux ABI support is not 100%, I had a problem running the Versant OODB. Acting as client to other OODB nodes was no problem, but acting as server failed not because the database service daemon didn't run (it seemed to work fine) but because on administration tool which is used to create new database files barfed on a file locking issue (the call complained about a wrong argument). I had no time to resolve it, but with a bit of help, this should have been solved with a few mail exchanges with the Linux emulation port maintainer.
Linux Java SDK 1.4 didn't work too. I guess will not be fixed until someone with a need for it and debugging capabilities will hunt the issue down.
In general it is more useful to built a native
Java SDK. You should be able to built the 1.3.1 SDK, after you got the sources from Sun and the diffs from the FreeBSD Java project. This hassle is due to Sun's prohibition of self rolled binary releases. The legal problem was reported to have been resolved, but it has not led to a binary release yet.
Even compared to Solaris, we get more bang for the buck out of our little linux machines. Especially since IBM's JDK is SOO damn fast.
The fastest one should be Sun's 1.4.0 release.
Especially for Swing clients under X11, where they stopped moving bitmaps around instead of
drawing commands.
Note that I answered this despite I think that you are a troll.:)
A colleague of mine bought one at JavaOne too.
It was sold for USD 200. Estimated retail price in Germany is over $500.
I had the chance to have a look at it. The keyboard is sweet, but a bit unusual.
It is fun to launch a bash shell and start the vi editor. But I didn't came far, as the keyboard has no control keys.:)
The display is beautiful. The QT based GUI has a nice graphical design.
The Turing machine stores the state of the emulated program at every step. If the emulated program currently has the state that it had at any point in the past, it's in a loop and will continue forever. If not, there are only so many states... a LOT, mind you, but finite... and it will eventually terminate.
The Turing machine is not just a state machine. One thing you neglect is the dependency on input data.
A Turing machine is an abstract cpu together with a program which reads a finite number of strings as input and has a string as return value:
String f(String s1, String s2,.., String s_k)
What you describe might or might not decide if f("hi") halts, but certainly not f(s) (s some arbitrary String) in general, where you have to do your simulation for every possible s, from which there are infinitely many differents ones.
While he writes (Score:1, Funny) and (Score:1, Interesting), I often think he is (Score:-1, Overated) after reading his essays.
At least he doesn't plug his latest product (a true/.er would most likely use something PHP or Zope or Perl based anyway instead) in the interview, or did I overread that?:-)
There are few areas, where users should experience a lesser performance from a FreeBSD box than from a Linux one.
One is the nvidia OpenGL driver (a generic x86 driver in theory, a Linux specific one for a long time in practice).
Perhaps the out of the box tweaking is a bit conservative.
Linux SMP scaled better than FreeBSD's in the past, but how many users you know run multiprocessor boxes?
This is the company that though they could sell tens of thousands "Collector's Edition" Quake 3 tin boxes to a market that didn't even have 3D support shipping in the mainstream distributions!
My collector's box contained not only the Quake CD, but a second CD with some SuSE distro as well.
I didn't use that for obvious reasons, but I guess it would have prevented the problems you speak of.
Note the dramatic setup: The OS CD is just added for convenience, in case one needs it, with probably most people treating it like they would treat an AOL CD.
The game was the important bit, not the OS!
Isn't this sympathic compared to the strange cult over there in Redmond, the one with the dance around Windows XP?
Tsk, so much money for a good which should be a cheap commodity.
Quake was by the way a problematic product, because many people bought the Windows version and then used the game files with the free Linux version, they took from the net. I wonder if Loki got any extra royalties (for the additional Windows sales they triggered).
I've never done official tests, but Java always seems to take an order of magnitude more memory, and runs much slower.
Memory waste seems to be a bigger problem in Java, then it is in C++. (Which in turn has a much worse performance impact than the usual suspect VM interpretation).
I am not exactly sure why this is.
Is it because people have a garbage collector and thus they get more careless about memory cleanup?
Or is it because Java programs are on a higher abstraction level than C++ programs (which means more complex object hierarchies with much unfortunate temporary object creation/destruction)?
Maybe someone can explain to me, how Java could be faster than C++.
One argument is that a JVM like Hot Spot does dynamic compilation. The typical C/C++ code gets one once compiled. The resulting exe is hardly optimized after, even if you might take it to quite different execution environments.
Code generation involves making assumptions
about the execution environement and will result in certain influential decisions.
A JVM like Hotspot however probes the present environment and will profile how the compiled code behaves, and will probably try improving matters during interpretation.
This might lead to better and thus faster code
than the static one, we are used too.
I believe Intel's C/C++ compiler does a dynamic optimization at runtime too.
Might be interesting to compare that one to Hotspot Java code.:)
Computers are not really taken advantage of nowadays.
Well the Apple ][ people did amazing things with their weak hardware. But that was when hardware remained the same for a longer period. Today you can observe the same with the game consoles, which also show some impressive usage.
Weak compilers,
My impression was that compilers got cleverer, and need to get cleverer for the 64 bit PCs.
Java will be a viable choice when the bytecode is run directly by commodity cpu-s.
The interesting and unique bit about Java bytecode is not it being just intermediate code, but it being security proven intermediate code.
Actually a computer architecture would be interesting, that "thinks" in classes, objects and references.
For each language, the report conflates the standard library with the language itself. Languages are grammar and semantics.
Java the language is not too interesting (just a dumbed down C++ version, or sanitized C++ version depending on who you ask:)
Of course one is comparing the Java 2 SDK (the language, the libs, the compiler, the hot spot vm, plus the available IDEs) to the Windows/MSVC++ combo.
If a DLL is allready loaded there will no second one get loaded, the already loaded one is reused(so the one in the dircectory where the AP is is IGNORED!).
You describe the case a.exe loads a.dll and b.exe loads a.dll (same name, but this a.dll containing incompatible code).
Which won't work, because we end up with both
a.exe and b.exe mapping in/sharing the first a.dll only.
Java however gives you with custome class loaders full control over your loaded classes. No problem to have the same class in endless different versions in your VM:-)
Funny enough this seems to turn out a kind of Java specific problem:
We have two different Java apps, which means at some point two different Java classes, that explicitly contain a reference each to a natively implemented OODB driver.
The thinking mistake was that these are not two different Windows apps. It is just one, the Java interpreter, interpreting two different Java apps.
As the Database Inspector allready had his LIBRARY.dll loaded the system refused to laod a second library with the same name. Instead of that the system linked the allready loaded library to the Java program.
We observed link errors with our app if someone used the db inspector tool before.
What I didn't realize before was, that this is not the same like running two different apps like a.exe and b.exe.
In fact this is java.exe interpreting a.class here and the same java.exe (in a different instance, which typically just means a different data segment for a new set of instance variables) interpreting b.class there.
Now a.class has a System.loadLibrary() call that pulls in old.dll while b.class has a call that pulls in new.dll. Thus Windows must map somehow old.dll into the javaw.exe process memory plus must map new.dll
at the same to into javaw.exe process space. This won't work with just one (shared) javaw.exe code segement instance in memory, I guess.
As far as I can see all your problems stem from the fact that you are using the javaw.exe to run your (non-managed) app as opposed to using some native code and running a native app.
Before the discussion with you guys here, I blamed the mess just on Windows.
I thought once an instance of a dll is mapped into some process, no other process can map the same lib (same means, same interface signatures, the name of the dll is slightly different) but of different (incompatible) version successfully into its process memory space.
I realized that is not true, because I don't have two different processes. I mistook the two different programs (db inspector, our JWS app) for different apps. But they are not.
Both times the same Java interpreter (javaw.exe) is active. Which means one shared instance in the code segments and probably some kind of shared management of mapped in dlls, as an exe under Windows is really just a mapped in kind of dll, if I remember right. This is very likely the reason for my dll trouble.
If I use two different Java interpreters, eg by installing a second runtime (or better like it wa s suggested above, if I deploy the JWS app with its own Java interpreter). Then I have really two different/distinguished apps in memory, which should have not interference when loading the dlls.
About switching to native code:
Too bad I have to use Java, and the available JWS version, even if it has bugs and undesirable behaviour.:)
While I have sources for them (this stuff is available under Sun Community License) I am not allowed to fix matters and distribute an "improved" version of the JRE and JWS to our clients.:(
That license issue is my personal problem with Java. I understand that it helped Sun to fight Microsoft for a certain degree, but for me this is a hinderance.
Sorry about the disgression from the original game topic of this discussion forum.
This is why I in my report recommend that you bundle your own JVM with your app. That way you can put any of your DLLs in the same directory as your javaw.exe, you are sure it is only started with your app, and you are sure that the JVM behaves exactly as during your own tests.
Yes, that sounds like the right thing to do.
In fact the Java installer for use with Web Start I created to pull in matching DLLs was based on sample code by a poster from the JWS forum over at Sun, who first published how to roll your own JVM for Web Start installation.:)
Different JVM has different performance characteristics and take different non-standard parameters, so you can play safe only by bundling your own JVM.
I thought about this shortly, when 1.4 came out recently which triggered a couple of errors in our large application (one we had was a funny error regarding the Vector class, another remarkable one the fragility of 1.4's jpeg decoder which dies on jpegs with embedded thumbnail preview:)
But I would probably (out of lazyness) just twiddle with the part of the jnlp descriptor, where one mentions the allowed JVMs, if I hadn't had this discussion with you guys. Hm, probably the most fruitful discussion I personally had on Slashdot for a long time. Something wrong here?:)
BTW, I have heard several people complain that they couldn't get the Java webstart to work (as users), so I don't consider it stable enough for production use.
No doubt, Java Web Start is not a ripe product.
I grapple with it for several months now, and experienced many pitfalls with it. (Read the jnlp/JWS developer forum over at Sun for more:)
It is frustrating to see such a good idea only finished for 90% or so.
I was surprised that Sun put it in 1.4, regarding the quirks which are not ironed out yet.
On the other hand this will force them to repair it sooner or later.
Perhaps they had to simply issue it, regarding that.net assemblies and the global assembly cache look very similiar like JWS, if I'm reading their descriptions correctly.
From what I saw, Java Web Start was developed initially on the Solaris Plattform, and then ported to Windows in a hurry, without thinking
too much if it was really possible to recreate the same under Windwows.
I believe this because some parts of the JNLP API (I mean the support services which should be offered by any JNLP client) like triggering a jar/resource transport into the JWS cache, or removing an item from the JWS cache do not seem to work properly under Windows. At least I didn't get them to work. The reason for their failure might be that files that are in use can be deleted under UNIX without problems, while they can't under Windows.
Further, the main two technical guys (Rene Schmidt who wrote the jnlp Specification, and another guy who seemed to do the implementation)
seem to have vanished from Earth. They showed up on the jnlp discussion forum up to a certain point in time (about may 2001) also the last Java One article by these persons showed up around that time. Then nothing. Looks to me like they were taken away from this project, with the result of no major development happening anymore to the product (except small bug fixes).
Other madness includes dealing with native libs, where surprisingly Windows caused me less pain than Linux. I still don't know if a certain problem I had with Java3D distribution via JWS (which was possible for Windows), which involved having to resolve circular shared library dependencies, is really fixable or a principle problem.
Then we have the fact that Java Web Start is program useful for client boxes, and these are in 90% of the cases Windows machines. In certain for my company commercially interesting company environments, such boxes are administered well, which means that the user has no Administrator priviledges, in contrast to the typical home user.
Everything, including JWS installation, and the voodoo the Java app deployed via JWS might need, can't depend on having adimin rights there.
Unfortunateley the driver of the OODB we used, required admin rights for it's installation. (Which was unnecessary for a pure client setup - they required it because their install also included the case of server install, which would have added a Windows Service/daemon).
Others detected JWS dialing out to Sun, which should be a big no in a secured company environment.
Just a couple of items which showed a lack of real world usage of JWS.:)
Then we have the JWS cache update mechanism, which is often unpredictable to me. And a bloody "lazy/eager evaluation" behaviour and strange dependency tracking and..
BUT, when JWS works, this is a damned comfortable and useful thing. It helped us much during inhouse development, when the non developers had to test things. People who don't know the intricacies of Java installation on their boxes and how make Java apps run from jars. They just want to click and launch.
Thanks again for discussing with me, I hope the insights won will help me to make our app more bulletproof!
Thanks for the link. It tells about the lookup procedure for dlls. So much so good.
It is a bit unclear in regard to the term The directory from which the application loaded.
In my case we talk about a set of Java jar files, moved over to the client box via Java Web Start. The application running is the javaw.exe in some installation directory. Over several stations it will pull in the jar that contains the reference to the native code which will trigger the LoadLibrary call. It could be that this LoadLibrary call is in some file different from the javaw.exe position.
However my particular problem was a different one: It was not about not finding a dll but instead some other program already pulled in an older version of the dll now I'm busted.
The kick is that it is a different program only from the perspective of the Java programmer and user (here a database inspector written in Java, there a Java Web Start application), but it is the same program from the perspective of Windows (the same javaw.exe that interprets both Java apps).
To be more precise: somebody already opened a database inspector tool, this is a java program too, but it will trigger a LoadLibrary call to an older dll revision. Thus we have javaw.exe mapping in old.dll.
Now I need to ran a Java program that needs to use new.dll, which would make the same javaw.exe to map to new.dll.
As far as I understand, I can't do this, because it is the same app for windows.
A solution would be to have a dedicated Java VM (with its own javaw.exe) that is used for Java Web Start execution.
I used a different solution in that I created a Java based installer that does some detection work and pulls in an application part that references the same foo.dll hat was already pulled in, if.
Everyone created Java IDEs for propellorheads instead of tools to let art school dropouts create shiny, brightly colored objects. There were a few people who drank the koolaid and created horrifying animated buttons using Java, but there were very few beautiful little Java widgets.
How many people master both crafts - programming and good graphical design arts?
Not so many. One of the few I got aware of is
John Maeda who first studied computer science,
then did arts school, today an influential MIT professor. Cool artist that uses the cheap repetetive features of a computer to create beautiful art.
There is no such thing as a "dll hell". All.dll's are loaded from your current working directory, your path, and the windows system directory, in that order.
Of course there is.
What do you do if some application already sucked in version 1 of a dll, while another application needs (the incompatible) version 2 of that dll?
Even using Java doesn't prevent from dll hell under Windows. I experienced exact this problem with the (native) Java driver of an OODB.:(
Another obstacle is controlling the load paths, which is not always possible.
For this, the.net "assemblies" will hopefully turn out to be major improvment.
Slashdot Mirror
Intersting are some numbers:
At a different level, we see it in the human brain itself, which starts with only 12 million bytes of specification in the genome, yet ends up with a complexity that is millions of times greater than its initial specification5. (..) The genome has 6 billion bits, which is 800 million bytes, but there is enormous repetition, e.g., the sequence "ALU" which is repeated 300,000 times. Applying compression to the redundancy, the genome is approximately 23 million bytes compressed, of which about half specifies the brain's starting conditions. The additional complexity (in the mature brain) comes from the use of stochastic (i.e., random within constraints) processes used to initially wire specific areas of the brain, followed by years of self-organization in response to the brain's interaction with its environment.
Thus roughly speaking we start with some kind of 12MB programm working on a 12MB set of input data. Pretty good work that our little cellular automata do, when acting in the physical environment eh?
Sir, allow me to kick your arse with Erlang!
And? The convergence map of the iteration z=z^2+c will defines an amazingly complex image, the mandelbrot set.
The second part of his discovery is the principle of computational equivalence, again, summed up, it means that passed a 'threshold' (more or less), two computational processes can be regarded as equally complex. This is a BIG claim, one that will be investigated thoroughly by mathematicians.
This is very hard to accept for me.
There is a systematic study of finite systems and their computational power - the theory of computation/recursion theory in theoretical computer science - stuff like finite automata, turing machines and so on.
And even there, people started to realize that these models map to computing machinery gouverend by the rules of classical physic and started to think what could be done with a system that makes use of quantumn mechanical effects. And came up with quantumn computing, which has been proved to be more powerful for certain problems because it can make use of an inherent parallelism. Which makes clear that even the well hung classical recursion theory is not the last word concerning computational power. (And Wolfram pretty much fits in the classical department with cellular automatons).
Worse, recursion theory reveals that pretty many problems can't be computed in finite time by a finite machine. Thus already the classical theory makes clear that much can't be done that way.
In that sense our mathematical framework is more powerful, because we can nicley describe problems in it, which Turing machines can't solve.
And now Wolfram shows up and claims that anything can be done with cellular automata? And we should use programs rather than mathematics.
This is in direct opposition to what I personally understood from my limited exposure to theoretical computer science.
I would have expected him -like any serious scientist- to compare his theory with the framework of existing theories.
Worse, he must understand that existing computing theory very well, his buddy Chatain is a very good theorist in that field. (He is the guy who found a real number omega where it can be proved that we can't compute it's digits).
Sorry, but until I have read his book and am convinced otherwise I believe Wolfram sells his remaining reputation to sack in a lot of money, by producing one of those mathematical coffeetable books.
It is total mystery to me, why he is not more humble. Take Hofstaedters Goedel, Escher, Bach for instance. (Which links recursion theory, graphical recursions, musical recursions :)
This book is nice to read, has lots of
pretty pictures and nice thoughts.
But Hofstaedter doesn't claim to be Newton 2.
Why was Wolfram not satisfied with just producing a nice book like Hofstaedter did?
Why must he claim he grokked it all?
My answer is he is either gone crackers or he is selling his reputation to generate more sales.
Regards,
Marc
Can you simplify
f(x) = int_{0}^{x} exp(-t*t) dt ?
No you can't. Except you make it a new member of your set of basic/elementary functions.
If you integrate the equations of motion (which are second order differential equations in time) with many problem instances you will encounter situations where exactly that impossibility of simplifying the solution symbolically into a closed form / analytic solution happens.
The Lorzenz systems and the weather system however have property of "a small change to the initial condition might blow the system to a latter state which might be totally different from the state it might have reached without pertubation" Thus these systems are just very sensitive. (wiggle a bit and the system makes a big jump in some direction very sensitive to the wiggle).
It is rather surprising that this came as a surprise.
WTF? What is your mathematical background to say this? (..) At worst, you have to solve sets of differential equations (..)
To say that we don't have an equation is either obtuse, naive, or a deliberate troll.
Both of you are imprecise. The first poster complained that there is no analytic solution. Which is true. The second poster counterargumented that it is easy to solve by some iterative procedure. Whic is true as well but misses the point of the first poster.
What we deal with here is symbolic integration. Derivation (finding the f' for a given function)is simple because there are easy rules that yield the formulas of derivatives, integration (finding a function f for a given f') is an art because we quickly end up with formulas that can't be simplified with the usual set of elementary functions and we are stuck with the integrals (which might be used to define functions, like erf). Look for Liouville's theorem to see how stuff like this is proved rigorously.
The more general problem is solving differential equations, systems of differential equations both in one or several changing variables.
Most physical laws tell you how to assemble the set of differential equations. Writing down the newtonian forces for the planets is exactly that.
Solving these systems of differential equation is again called integration.
What turns out is that you can't write down the solution to the three body problem in general as some simple combination of elementary formulas. It is not much different from the one dimensional integration case. No magic. Just that you can't write down the solution in a simple closed form. The one who proved that was Henri Poincare in his celestial mechanics treatise by the way.
It just means that the space of all solutions we can construct by assembling the usual cast of simple functions we employ is not large enough to hold every function which is singled out by the solution space of a differential equation.
The first was poster wrong in that he doesn't understand that the set of differential equations plus conditions is the precise description (if we neglegt general relativty and quantum effects :)
and that solutions are necessary of approximative nature if we don't want to extend our basic set of functions by lots of integral functions.
The second poster is wrong in labeling the first poster a troll, because he didn't understand his concern about closed solutions.
Regards, Marc
Photomesa is based on the Jazz API (a Java class lib), that implements a ZUI (zoomable user interface), a paradigm sometimes described as 2.5 D interface.
You can use the mouse to move in xy plane und with an extra key press (or possibly via mouse wheel in J2SE 1.4) you change the height of the camera in z direction. This combined with semantic zooming, which means different levels of detail associated with the height, make for very nice user interfaces.
A similiar API has been developed at Xerox France, the VTM library which used by the W3C for the nice IsaViz tool.
Despite IMHO Java still sucks regarding performance, both APIs perform very well with large object scence graphs. Like I wrote, combined with Java's luxury 2D API, it enables us to build attractive user interfaces.
Regards,
Marc
Of course it makes only sense to compare 1.3.x with 1.3.x, 1.4.x with 1.4.x and so on. This is because Java VM implementation evolved greatly.
I built a dual P4-2,2 GHz FreeBSD 4.5-STABLE system last week, and it performed very good (it even made use of the hyperthreading, there were 4 virtual CPUs).
I am not trolling, I am not anything.. but the performance was almost 1/3 of what I could get on Linux with IBM's JDK.
I'm pretty sure you are not comparing the same Java JDK version.
And if your suggestion to that issue is run in Linux compatibility mode, your smoking crack. Why? Linux compatibility mode is just a different instructuion decode/execution mode of the kernel, each system call is translated into a FreeBSD kernel system call, the libs that are used are original Red Hat libs. That is why I was able to run the Linux 1.3.1 JDK on the dual box.
However the Linux ABI support is not 100%, I had a problem running the Versant OODB. Acting as client to other OODB nodes was no problem, but acting as server failed not because the database service daemon didn't run (it seemed to work fine) but because on administration tool which is used to create new database files barfed on a file locking issue (the call complained about a wrong argument). I had no time to resolve it, but with a bit of help, this should have been solved with a few mail exchanges with the Linux emulation port maintainer. Linux Java SDK 1.4 didn't work too. I guess will not be fixed until someone with a need for it and debugging capabilities will hunt the issue down.
In general it is more useful to built a native Java SDK. You should be able to built the 1.3.1 SDK, after you got the sources from Sun and the diffs from the FreeBSD Java project. This hassle is due to Sun's prohibition of self rolled binary releases. The legal problem was reported to have been resolved, but it has not led to a binary release yet.
Even compared to Solaris, we get more bang for the buck out of our little linux machines. Especially since IBM's JDK is SOO damn fast.
The fastest one should be Sun's 1.4.0 release. Especially for Swing clients under X11, where they stopped moving bitmaps around instead of drawing commands.
Note that I answered this despite I think that you are a troll. :)
Hmm .. I have to try out Fn + Left shift + Right shift + <- next time he brings the Zaurus in. :-)
A colleague of mine bought one at JavaOne too. It was sold for USD 200. Estimated retail price in Germany is over $500.
I had the chance to have a look at it. The keyboard is sweet, but a bit unusual. It is fun to launch a bash shell and start the vi editor. But I didn't came far, as the keyboard has no control keys. :)
The display is beautiful. The QT based GUI has a nice graphical design.
The weak spot seems to be the battery.
For $200-$300 I would buy one immediatly.
Regards,
Marc
vi was written by Bill Joy, another prominent Sun employee (is he a vice president like Gosling too?)
The Turing machine is not just a state machine. One thing you neglect is the dependency on input data.
A Turing machine is an abstract cpu together with a program which reads a finite number of strings as input and has a string as return value: .., String s_k)
String f(String s1, String s2,
What you describe might or might not decide if f("hi") halts, but certainly not f(s) (s some arbitrary String) in general, where you have to do your simulation for every possible s, from which there are infinitely many differents ones.
While he writes (Score:1, Funny) and (Score:1, Interesting), I often think he is (Score:-1, Overated) after reading his essays.
At least he doesn't plug his latest product (a true /.er would most likely use something PHP or Zope or Perl based anyway instead) in the interview, or did I overread that? :-)
One is the nvidia OpenGL driver (a generic x86 driver in theory, a Linux specific one for a long time in practice). Perhaps the out of the box tweaking is a bit conservative.
Linux SMP scaled better than FreeBSD's in the past, but how many users you know run multiprocessor boxes?
That's why I believe you post bullshit.
My collector's box contained not only the Quake CD, but a second CD with some SuSE distro as well. I didn't use that for obvious reasons, but I guess it would have prevented the problems you speak of.
Note the dramatic setup: The OS CD is just added for convenience, in case one needs it, with probably most people treating it like they would treat an AOL CD. The game was the important bit, not the OS!
Isn't this sympathic compared to the strange cult over there in Redmond, the one with the dance around Windows XP? Tsk, so much money for a good which should be a cheap commodity.
Quake was by the way a problematic product, because many people bought the Windows version and then used the game files with the free Linux version, they took from the net. I wonder if Loki got any extra royalties (for the additional Windows sales they triggered).
Regards,
Marc
Memory waste seems to be a bigger problem in Java, then it is in C++. (Which in turn has a much worse performance impact than the usual suspect VM interpretation).
I am not exactly sure why this is.
Maybe someone can explain to me, how Java could be faster than C++.
One argument is that a JVM like Hot Spot does dynamic compilation. The typical C/C++ code gets one once compiled. The resulting exe is hardly optimized after, even if you might take it to quite different execution environments.
Code generation involves making assumptions about the execution environement and will result in certain influential decisions.
A JVM like Hotspot however probes the present environment and will profile how the compiled code behaves, and will probably try improving matters during interpretation.
This might lead to better and thus faster code than the static one, we are used too.
I believe Intel's C/C++ compiler does a dynamic optimization at runtime too.
Might be interesting to compare that one to Hotspot Java code. :)
Well the Apple ][ people did amazing things with their weak hardware. But that was when hardware remained the same for a longer period. Today you can observe the same with the game consoles, which also show some impressive usage.
Weak compilers,
My impression was that compilers got cleverer, and need to get cleverer for the 64 bit PCs.
Java will be a viable choice when the bytecode is run directly by commodity cpu-s.
The interesting and unique bit about Java bytecode is not it being just intermediate code, but it being security proven intermediate code.
Actually a computer architecture would be interesting, that "thinks" in classes, objects and references.
Something like the old Lisp machines did?
Java the language is not too interesting (just a dumbed down C++ version, or sanitized C++ version depending on who you ask :)
Of course one is comparing the Java 2 SDK (the language, the libs, the compiler, the hot spot vm, plus the available IDEs) to the Windows/MSVC++ combo.
You describe the case a.exe loads a.dll and b.exe loads a.dll (same name, but this a.dll containing incompatible code).
Which won't work, because we end up with both a.exe and b.exe mapping in/sharing the first a.dll only.
Java however gives you with custome class loaders full control over your loaded classes. No problem to have the same class in endless different versions in your VM :-)
Funny enough this seems to turn out a kind of Java specific problem:
We have two different Java apps, which means at some point two different Java classes, that explicitly contain a reference each to a natively implemented OODB driver.
The thinking mistake was that these are not two different Windows apps. It is just one, the Java interpreter, interpreting two different Java apps.
We observed link errors with our app if someone used the db inspector tool before.
What I didn't realize before was, that this is not the same like running two different apps like a.exe and b.exe.
In fact this is java.exe interpreting a.class here and the same java.exe (in a different instance, which typically just means a different data segment for a new set of instance variables) interpreting b.class there.
Now a.class has a System.loadLibrary() call that pulls in old.dll while b.class has a call that pulls in new.dll. Thus Windows must map somehow old.dll into the javaw.exe process memory plus must map new.dll at the same to into javaw.exe process space. This won't work with just one (shared) javaw.exe code segement instance in memory, I guess.
I will try it tomorrow. :)
Before the discussion with you guys here, I blamed the mess just on Windows. I thought once an instance of a dll is mapped into some process, no other process can map the same lib (same means, same interface signatures, the name of the dll is slightly different) but of different (incompatible) version successfully into its process memory space. I realized that is not true, because I don't have two different processes. I mistook the two different programs (db inspector, our JWS app) for different apps. But they are not. Both times the same Java interpreter (javaw.exe) is active. Which means one shared instance in the code segments and probably some kind of shared management of mapped in dlls, as an exe under Windows is really just a mapped in kind of dll, if I remember right. This is very likely the reason for my dll trouble.
If I use two different Java interpreters, eg by installing a second runtime (or better like it wa s suggested above, if I deploy the JWS app with its own Java interpreter). Then I have really two different/distinguished apps in memory, which should have not interference when loading the dlls.
About switching to native code: Too bad I have to use Java, and the available JWS version, even if it has bugs and undesirable behaviour. :)
While I have sources for them (this stuff is available under Sun Community License) I am not allowed to fix matters and distribute an "improved" version of the JRE and JWS to our clients. :(
That license issue is my personal problem with Java. I understand that it helped Sun to fight Microsoft for a certain degree, but for me this is a hinderance.
Sorry about the disgression from the original game topic of this discussion forum.
Yes, that sounds like the right thing to do.
In fact the Java installer for use with Web Start I created to pull in matching DLLs was based on sample code by a poster from the JWS forum over at Sun, who first published how to roll your own JVM for Web Start installation. :)
Different JVM has different performance characteristics and take different non-standard parameters, so you can play safe only by bundling your own JVM.
I thought about this shortly, when 1.4 came out recently which triggered a couple of errors in our large application (one we had was a funny error regarding the Vector class, another remarkable one the fragility of 1.4's jpeg decoder which dies on jpegs with embedded thumbnail preview :)
But I would probably (out of lazyness) just twiddle with the part of the jnlp descriptor, where one mentions the allowed JVMs, if I hadn't had this discussion with you guys. Hm, probably the most fruitful discussion I personally had on Slashdot for a long time. Something wrong here? :)
BTW, I have heard several people complain that they couldn't get the Java webstart to work (as users), so I don't consider it stable enough for production use.
No doubt, Java Web Start is not a ripe product. I grapple with it for several months now, and experienced many pitfalls with it. (Read the jnlp/JWS developer forum over at Sun for more :)
It is frustrating to see such a good idea only finished for 90% or so.
I was surprised that Sun put it in 1.4, regarding the quirks which are not ironed out yet. On the other hand this will force them to repair it sooner or later.
Perhaps they had to simply issue it, regarding that .net assemblies and the global assembly cache look very similiar like JWS, if I'm reading their descriptions correctly.
From what I saw, Java Web Start was developed initially on the Solaris Plattform, and then ported to Windows in a hurry, without thinking too much if it was really possible to recreate the same under Windwows.
I believe this because some parts of the JNLP API (I mean the support services which should be offered by any JNLP client) like triggering a jar/resource transport into the JWS cache, or removing an item from the JWS cache do not seem to work properly under Windows. At least I didn't get them to work. The reason for their failure might be that files that are in use can be deleted under UNIX without problems, while they can't under Windows.
Further, the main two technical guys (Rene Schmidt who wrote the jnlp Specification, and another guy who seemed to do the implementation) seem to have vanished from Earth. They showed up on the jnlp discussion forum up to a certain point in time (about may 2001) also the last Java One article by these persons showed up around that time. Then nothing. Looks to me like they were taken away from this project, with the result of no major development happening anymore to the product (except small bug fixes).
Other madness includes dealing with native libs, where surprisingly Windows caused me less pain than Linux. I still don't know if a certain problem I had with Java3D distribution via JWS (which was possible for Windows), which involved having to resolve circular shared library dependencies, is really fixable or a principle problem.
Then we have the fact that Java Web Start is program useful for client boxes, and these are in 90% of the cases Windows machines. In certain for my company commercially interesting company environments, such boxes are administered well, which means that the user has no Administrator priviledges, in contrast to the typical home user.
Everything, including JWS installation, and the voodoo the Java app deployed via JWS might need, can't depend on having adimin rights there.
Unfortunateley the driver of the OODB we used, required admin rights for it's installation. (Which was unnecessary for a pure client setup - they required it because their install also included the case of server install, which would have added a Windows Service/daemon).
Others detected JWS dialing out to Sun, which should be a big no in a secured company environment.
Just a couple of items which showed a lack of real world usage of JWS. :)
Then we have the JWS cache update mechanism, which is often unpredictable to me. And a bloody "lazy/eager evaluation" behaviour and strange dependency tracking and ..
BUT, when JWS works, this is a damned comfortable and useful thing. It helped us much during inhouse development, when the non developers had to test things. People who don't know the intricacies of Java installation on their boxes and how make Java apps run from jars. They just want to click and launch.
Thanks again for discussing with me, I hope the insights won will help me to make our app more bulletproof!
Regards,
Marc
It is a bit unclear in regard to the term The directory from which the application loaded. In my case we talk about a set of Java jar files, moved over to the client box via Java Web Start. The application running is the javaw.exe in some installation directory. Over several stations it will pull in the jar that contains the reference to the native code which will trigger the LoadLibrary call. It could be that this LoadLibrary call is in some file different from the javaw.exe position.
However my particular problem was a different one: It was not about not finding a dll but instead some other program already pulled in an older version of the dll now I'm busted.
The kick is that it is a different program only from the perspective of the Java programmer and user (here a database inspector written in Java, there a Java Web Start application), but it is the same program from the perspective of Windows (the same javaw.exe that interprets both Java apps).
To be more precise: somebody already opened a database inspector tool, this is a java program too, but it will trigger a LoadLibrary call to an older dll revision. Thus we have javaw.exe mapping in old.dll. Now I need to ran a Java program that needs to use new.dll, which would make the same javaw.exe to map to new.dll.
As far as I understand, I can't do this, because it is the same app for windows.
A solution would be to have a dedicated Java VM (with its own javaw.exe) that is used for Java Web Start execution. I used a different solution in that I created a Java based installer that does some detection work and pulls in an application part that references the same foo.dll hat was already pulled in, if.
Is this DLL hell? I would say yes.
Regards,
Marc
How many people master both crafts - programming and good graphical design arts?
Not so many. One of the few I got aware of is John Maeda who first studied computer science, then did arts school, today an influential MIT professor. Cool artist that uses the cheap repetetive features of a computer to create beautiful art.
He did some cool Java applets as well, I particulary like the MIT navigation prototype.
If no one manages to educate and interest more propelerheads in arts, we will stay with the flash people for the mainstream presentations.
Did I mention that scientific apps are among the worst GUIs I ever saw? :-)
Of course there is.
What do you do if some application already sucked in version 1 of a dll, while another application needs (the incompatible) version 2 of that dll?
Even using Java doesn't prevent from dll hell under Windows. I experienced exact this problem with the (native) Java driver of an OODB. :(
Another obstacle is controlling the load paths, which is not always possible.
For this, the .net "assemblies" will hopefully turn out to be major improvment.
Regards,
Marc