On Wed, 19 Jul 2006, Talha Yalta wrote: Sorry, I've been busy with bug-fixing lately. I think the splash image you've made is rather spiffy in its own right, but it doesn't really say "gretl" to me. Some might find the gretl/Gretel pun excessively whimsical, but for better or worse the Gretel image _is_ the logo we've got: it's been on the website, on the cover of the manual, and in the Windows and xpm icons for years. So I think a gretl splash screen should at least "refer to" this image in some way. (Unless and until, perhaps, we do a total revamp of gretl's visual imagery, including new icons, website design, etc -- which may not be a bad idea at some point.) One other small comment: I found letters on the "phages" in the foreground a little distracting: I wanted to read what they said, but got "BLSMFE". Allin.

Well, those are not phages :) I was intending them to be some fancy beans (like the ones Hansel left in the forest to find his way). The letters on them have no meaning. They are just common letters used in econometric analysis, regressions etc. (For example, "B" is for beta commonly used for coefficients and I put the "e" at the end like the error term in a regresion. I can change the letters to read something else but the idea is that these beans lead the way out from the complexities of econometric analysis, or something like that :) I thought this was a clever way to refer to the tale but checking the internet, now I see that the common version of this tale features pebbles or bread crumbs instead of the beans that I knew as a kid :) I guess I can make them look more like pebbles if it is difficult to make the connection. If you want, I can impose the Gretel image in the background (maybe to the righthand side) pretty much like the greek letter G behind "GRETL 1.6.0" text. I want to do this the way "you" guys want it to be. I want it to be something everyone likes. I can change everything or even throw out the whole idea (even though I think its charming). Just give me some directions. Cheers... -- A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort. - Herm Allbright (1876-1944) --

One of the delights of Gretl is the speed at which it loads. Even on an old 400 Mh PC loading is instantaneous. A splash screen may tell one that something is happening for a program that takes time to load (e.g. Texmacs or Jabref). For a splash screen to be effective one would have to slow down loading Gretl and I do not think this is a good idea. One small suggestion about the interface (for consideration for some future version) would be to allow a user to step through a script line by line from the "script editor" John C Frain On 20/07/06, Riccardo Jack Lucchetti <r.lucchetti(a)univpm.it&gt; wrote: -- John C Frain

On Thu, 20 Jul 2006, Ignacio Díaz-Emparanza wrote: Jack and I know JMulti, and have used it for testing some of gretl's VECM functionality. It's a nice program. We should refer to it in the gretl docs along with R and Octave, as related free software. I'm not averse to the idea of some sort of collaboration, but I'm not sure what form it might take. Allin.

Allin Cottrell schrieb: Yes it should be mentioned. Actually, I know Markus (the developer of JMulti) because we're both from Berlin. (It's not that Berlin is so small, but when you deal with time series econometrics and are about the same age, then that happens.) At this point, I think the most useful starting point for a collaboration would be to make the datafiles convertible. I guess that's already a non-trivial task. Btw, in principle you can call Jmulti's routines from "anywhere" (as Java classes). With Markus's help we verified that for example you can use the Python language for that (using its Java implementation Jython). I can't speak for Markus, but my impression is that in some sense JMulti is a finished product in bugfix mode. But it's open source and in principle can be extended, but I think gretl's new function interface is more flexible in that respect. (not performance-wise, I guess) So much for that from me, Sven

So does this mean that I have to prepare the image more square sized? Also, I want to try a new version of my splash screen where the beans are replaced by white pebbles that lead the way. It is difficult to explain here but I can say it will look nice. The problem is, I don't want to spend time if you will dismiss it immediately, insisting on the existing Gretel image. Finally, if you like my work(s), I can volunteer to be the designer of artwork for other parts of the project as well such as documents, icons etc. However it won't work if you will be too attached to the "little girl". On 7/20/06, Allin Cottrell <cottrell(a)wfu.edu&gt; wrote: -- A positive attitude may not solve all your problems, but it will annoy enough people to make it worth the effort. - Herm Allbright (1876-1944) --

Yes, I already told Allin and Jack about JMulTi and I also told Markus about Gretl on JMulti forum. It's true that thay are both open source but the main problem with compatibillity is in different programming languages. JMulti is based on Jawa platform. I use them both. The oconnection between them is in Excel files which can be imported. Gretl is better in OLD, Logit, Probit, SURE etc. analisys while JMulTi is better in time series analisys like VAR and VEC, subset modelling. _________________________________________________________________ The new MSN Search Toolbar now includes Desktop search! http://join.msn.com/toolbar/overview

On Fri, July 21, 2006 20:43, john w wrote: To an extent. In jmulti, the number-crunching routines, which could be the main area of cooperation, are written in gauss and java is primarily used for building the user interface. This makes it much more difficult to share code: java is a loose C++ derivative, while gauss is a matrix interpreted language whose syntax is very different from C, which is what we use. It may be possible to share algorithms, though. In theory, I think it could be possible for jmulti to use our code by using our shared library. To be clearer: gretl can be thought of as 3 building blocks (I'm simplifying things quite a bit here; Allin, correct me if I'm wrong). The library, which contains all the numerical methods, and the two clients (graphical and command-line), which allow the user to run the code in the library through a user interface. For example, when you run OLS via the Model menu, the gretl program you're running sends all the necessary info to the library, which returns an object containing the estimated coefficients, auxiliary statistics and so on. The program's job is to display the results to you. In principle, anyone could write a program (in C, but also C++, java, python or whatever) with a different user interface which uses gretl's library. It should be technically possible to use the library from within a java program (I don't know how hard it would be, though), so jmulti could use our methods any time. IIRC, jmulti is GPL'ed too, so there shouldn't be any legal issues[*]. The reverse would be much harder, because there's no way I know of of running gauss code from within a C application. I would say that jmulti is specialised to time-series analysis, while gretl aims to be more comprehensive. For example, we're currently fine-tuning a totally revamped framework for panel data analysis. I don't think the jmulti people would be even remotely interested in such a thing. [*] Not really my business, but I wonder what the legal status of jmulti is, as they're using a non-free app (gauss) as an essential component of a GPL project. But maybe I misunderstood the whole thing. And, as I said, it's none of my business. Riccardo "Jack" Lucchetti Dipartimento di Economia Facoltà di Economia "G. Fuà" Ancona

Allin Cottrell schrieb: If you want a definitive answer, ask Markus, but afaik what's GPLed is the GUI layer and (probably) the econometric routines. Then they're shipping a binary Gauss runtime engine (GRE) for which they paid the (considerable) licence fee, of course. I guess the combination is comparable to GPLed .NET code in a sense: the runtime environment is closed source (I mean, your hardware environment is also proprietary!), but the code itself is open. -sven