Menu
▾
▴
clusterviz-devel — This list is intended for developmental related issues of the ClusterViz package
You can subscribe to this list here.
| 2006 |
Jan
(17) |
Feb
(4) |
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Jonas M. <na...@us...> - 2006-04-19 22:08:14
|
Hello everybody, while reading a paper I just came across the term "k-medoid clustering" which seems to be the same as k-median clustering. I did not look to thoroughly into this but it might be an idea to think about including this algorithm. Another idea that I just had was offering the opportunity to project data to the first three principal components when visualizing clustering processes of greater than three dimensional data. As I have used PCA already a couple of times and as it is really not much more than an eigenvector analysis of the correlation (or covariance) matrix of the data I might implement it in the near future. Kind regards, Jonas. |
|
From: Jonas M. <na...@us...> - 2006-03-12 23:25:25
|
Dear Karsten, On Sunday 12 March 2006 21:11, K. Weinert wrote: > Hello Jonas, > > the code in the RC 0.2 branch seems to work fine. Set it free! > > Considering the numerical problems in the higher-dimensional case in the > soft-k-means algorithm, I'm afraid I cannot contribute anything. Can you > point me to a paper or textbook describing the algorithm? I'm interested > in learning about it... If you can get your hands onto "Information Theory, Inference and Learning Algorithms" by David J.C. MacKay, take a look at it! This is the book that we read in a university course. I think it is quite nice read - I even bought it myself. It is also mentioned in our CREDITS file. Chapter 20 details the k-means algorithm. Soft k-means is in 20.2 and what we call mixture models in out implementation is found in 22.3 as "Enhancements to soft K-Means". The problems that we run into are detailed in 22.4 "A fatal flaw of maximum likelihood". Regards, Jonas. |
|
From: Jonas M. <na...@us...> - 2006-03-12 23:19:45
|
I am now in the process of preparing the release package. On Sunday 12 March 2006 22:33, Janne Grunau wrote: > On Saturday 11 March 2006 19:46, Jonas Maaskola wrote: > > This is a small reminder. Please give me some feedback as to your > > approval of the state of the RC for version 0.2. If there should be > > no objection by tommorow evening I will release version 0.2 in the > > present state. > > Approval. The error string is ok. One minor issue though: Exiting waits > for the cluster calculation to finish. Iirc it was working. and should > work in trunk. Thanks for the hint! It was a problem with a variable named exitNOW in visualkmeans and we set exitNow to True in clusterdisplay. We could have avoided this problem if we settled on a uniform variable naming scheme or if we implemented getter and setter methods for class members variables. > ciao Janne Regards, Jonas. |
|
From: Janne G. <gr...@mo...> - 2006-03-12 21:40:51
|
On Saturday 11 March 2006 19:46, Jonas Maaskola wrote: > This is a small reminder. Please give me some feedback as to your > approval of the state of the RC for version 0.2. If there should be > no objection by tommorow evening I will release version 0.2 in the > present state. Approval. The error string is ok. One minor issue though: Exiting waits=20 for the cluster calculation to finish. Iirc it was working. and should=20 work in trunk. ciao Janne |
|
From: K. W. <k.w...@gm...> - 2006-03-12 20:12:16
|
Hello Jonas, the code in the RC 0.2 branch seems to work fine. Set it free! Considering the numerical problems in the higher-dimensional case in the soft-k-means algorithm, I'm afraid I cannot contribute anything. Can you point me to a paper or textbook describing the algorithm? I'm interested in learning about it... Kind regards, Karsten. |
|
From: Jonas M. <na...@us...> - 2006-03-11 18:46:33
|
This is a small reminder. Please give me some feedback as to your approval of the state of the RC for version 0.2. If there should be no objection by tommorow evening I will release version 0.2 in the present state. Kind regards, Jonas Maaskola. |
|
From: Jonas M. <jo...@ma...> - 2006-03-07 01:17:10
|
I merged a couple of patches that had been applied to the RC branch back to= =20 trunk. This required subsequently to make sure that the data center=20 calculation happens at a later point in time, more specifically after the=20 data transformation is done. Apart from that I finally setteled on a way to handle the case of 0=20 responsibilities of individual data samples in soft k-means and mixture=20 models. This is a problem that is more important in higher dimensional data= =20 as there our usual euclidean distance amounts to higher relative difference= s=20 between data samples and cluster centers which leads to a more uneven=20 distribution of responsibilities among the data samples. When the=20 responsibilitiy for the total of clusters of an individual sample gets=20 rounded down to 0 we are in numerical problems. As this is a non-trivial issue with these algorithms I decided that we shou= ld=20 at least prompt the user and point him to the issue. Possibilities in this case include: restarting the algorithm and hoping for= =20 the best, or using hard k-means which seemingly does not suffer from this=20 problem. We might consider implementing algorithmic remedies to deal with this probl= em=20 and / or the problem of tiny cluster center stdandard deviations. For the=20 latter we could maybe enforce minimal values for the standard deviations.=20 This might even help in certain of the prior cases. For the prior cases we= =20 could possibly also resort to a technique along the notion of pseudo counts= ,=20 but I did not yet think this through I must say. =46eedback highly appreciated - as always! With this issue settled for the moment I would consider the moment come to= =20 release the version 0.2 of Clusterviz - at this time still without the new= =20 additions of Karsten's in trunk. What are your thoughts? Give this RC a tes= t=20 and tell me if there are any issues left in your opinion. Kind regards, Jonas. |
|
From: Jonas M. <jo...@ma...> - 2006-03-06 01:40:17
|
Hello, On Sunday 05 March 2006 22:15, K. Weinert wrote: > Hi, > in the last days I commited some code and introduced a new class > threadconn. It should do all the thread management and communication. > > In particular, the clustering algorithm class is now not derived von > threading.Thread anymore. Instead, threadconn.start creates a new > Thread object by itself. Looks interesting, yet it seems as if you forgot to commit an updated versi= on=20 of the clusterviz front-end script itself. Please do so, if you have an=20 updated version, as I would like to give it a little testing. My quick hack= s=20 to the version of the script that I have here did not produce the desired=20 result in a couple of minutes. I will reply at a later moment to the questions you put forward in your mai= l. Kind regards, Jonas. |
|
From: K. W. <k.w...@gm...> - 2006-03-05 21:16:20
|
Hi, in the last days I commited some code and introduced a new class threadconn. It should do all the thread management and communication. In particular, the clustering algorithm class is now not derived von threading.Thread anymore. Instead, threadconn.start creates a new Thread object by itself. What's your opinion about all this? Do you think it's useful or does it make the things too complicated? Personally, I don't like that the clusterdisplay class is still used by both threads, the changeAssignment und the updateCluster method by the clustering thread and all other methods by the gui thread. To resolve this, I suggest creating a new data class, which is shared by both threads and holds the data, the transformation matrix, and the history, but no display code. I think this could simplify the things: for instance, it would be easier to change the data set without restarting the program or to save/read history data. What do you think about this suggestion? Would be nice if you encourage me a bit -- or stop me if you don't like it.. Kind regards, Karsten. |
|
From: Janne G. <gr...@mo...> - 2006-02-25 18:33:28
|
On Friday 24 February 2006 22:37, Janne Grunau wrote: > Hi, > > Sourceforge activated the subversion service. > I' migrating our repository right now. So please stay with revision > 144. I will post then the migrating is finished. Migration is finished. I found no way to migrate the repository location=20 with svn. So the best way to migrate ist probably a new checkout from=20 sourceforge. svn co https://svn.sourceforge.net/svnroot/clusterviz clusterviz With 'diff -rq -x .svn clusterviz/ InfoTheory/' you can check for=20 modified or extra files in the old checkout. Please commit changes only to sourcefourge. I will disable or remove the=20 repository at the MPI next week. best regards Janne |
|
From: Janne G. <gr...@mo...> - 2006-02-24 21:36:04
|
Hi, Sourceforge activated the subversion service. I' migrating our repository right now. So please stay with revision 144. I will post then the migrating is finished. ciao Janne |
|
From: Jonas M. <na...@us...> - 2006-02-10 15:00:13
|
Hey, I fixed a couple of bugs and updated some of the README file and the presen= t=20 state of the branch for the release candidate for version 0.2 has again=20 improved. What remains to be decided whether it should be fixed for this=20 version or left for later. The problem is that with higher (>3) dimensional data mixture models fail m= ost=20 of the times because of a overflow error in computing the responsiblities.= =20 The implementation of the hard k-means algorithm seems to behave nicely. Wi= th=20 the soft k-means there seem to be occasional problems. I would like to ask you to look into this issue, if you find the time, as i= t=20 seems to me to be the last show-stopper before releasing version 0.2. Kind regards, Jonas. =2D-=20 ********************************************************************* Jonas Maaskola Konrad-Zuse-Zentrum f=FCr Informationstechnik Berlin Takustr.7 Tel: +49 30 84185-333 14195 Berlin Fax: +49 30 84185-311 ********************************************************************* |
|
From: Jonas M. <na...@us...> - 2006-02-03 16:37:27
|
Hey, I added a branch for the release candidate of version 0.2 to the branches subdirectory in SVN. I already did some tests on it, but would like to ask you to check it out yourselves as well, to make sure it really has already reached release quality at this state. After updating your local copies of the repository, you can create a source distribution by invoking python setup.py sdist in the RC directory. Copy the resulting package to some place in your filesystem (or better even: to some other computer) and install it from there to see whether it is complete. Give it a few tests and tell me your results afterwards. Actually I do not expect too many glimpses, so I believe we could possibly release it tomorrow. Karsten, your current work will be released together with version 0.3, which we might release quite soon (think about a few weeks, to let the code mature). So please give me some feedback as soon as you checked it out. PS: I will send you the current state of the RC-Package via private communication. Kind regards, Jonas. |
|
From: K. W. <k.w...@gm...> - 2006-01-31 13:15:25
|
Hello! Jonas Maaskola wrote: >>> - the other named glutwin manages the trackball and the clusterdisplay >>> and the GLUT callbacks. It does some thread management, too. > > > That is ok in principle. But can we please find another name for this class? I > do not like how it has that "-win" suffix which seems to be used > ubiquituously in the MS Windows world. Maybe be more verbose and use "window" > or something the like or rename it to something similar. (Maybe it is plain > silly to whine about variable names - but hey we are free to choose them!) I'll do this next time I work on the code. By the way, could we rename "auxiliary", too? It reminds me on one book on functional analysis I had to work with. It had a section titled "the most important theorems on functional analysis". It sounds interesting, but you don't know what's in it unless you look into it. Since auxiliary contains data related functions, maybe "data.py" would be appropriate? > There were indeed some other errors introduced as you seem not to have worked > on the most recent revisions. I noticed that changes to scripts/clusterviz > which I had commited in revisions 116 and 121 were not anymore in the code. > So I had to recommit that stuff. Please make sure always to work on the > newest revisions - especially before commiting. Sorry about that. I will use the svn work copy from python from now on (that is, I will not call setup.py install anymore). When there's only one clusterviz installation on my PC, confusions like that should not happen again. > >>> The trackball class has been cleaned up and the clusterviz script adapted >>> to employ the glutwin class instead of the clusterdisplay class. I know you >>> wanted more atomic commits, but I did not know how to split this step into >>> smaller ones. > > > Could you please verify that issues like the one I found and described above > did not happen to other parts of the code? I will look into that too, but > having more eyes check it would be better. Yet, as far as I can tell from the > diff between revision 124 and 125 nothing else of this kind has happend. > I think the clusterviz script was the only not-up-to-date file I used. I did call svn update before commiting, but since the python scripts are stored in a different place ($(python)/scripts) than the package itself ($(python)/lib/site-packages/clusterviz), there must have gone something wrong. > Using this new directory strucutre we could for example introduce now a > 0.2-release-candidate branch to make it really stable and robust so that it > reaches release quality. The question would then be whether we wait until > Karsten's present work is finished or whether we want to release the prior > state as 0.2 and have his work lead to 0.3. What do you think? I will continue next Sunday. I hope to get it done then, but it seems a bit involved.. So if you want to release this week, don't wait for me... Regards, Karsten. -- Wikar, der Desktop-Wiki: http://userpage.fu-berlin.de/~kweinert/wikar/ |
|
From: Jonas M. <na...@us...> - 2006-01-29 20:57:24
|
Hey, I just commited a reconfiguration of the repository layout. I introduced basically three directories. With this I follow a rather standard directory policy in revision control systems. I will detail what the directories are for below. trunk/ This directory is for the main line of development. I moved the former contents into this directory. branches/ Should we have the need for parallel lines of development just copy the current (or an older) state of trunk here with the command: svn cp trunk branches/newBranch The so created branches can lateron easily be merged back into the main development line when they have reached maturation. tags/ This directory can be used to preserve old states of the code. For example when we have releases we can just copy the state of trunk at release time into there and can lateron easily identify and retrieve the state of the code that was released. In CVS there is the concept of tagging individual commits. But this here is an easier way of doing it. Using this new directory strucutre we could for example introduce now a 0.2-release-candidate branch to make it really stable and robust so that it reaches release quality. The question would then be whether we wait until Karsten's present work is finished or whether we want to release the prior state as 0.2 and have his work lead to 0.3. What do you think? PS: Do you think we should include the data/ directory into trunk/ or have it seperately? Kind regards, Jonas. |
|
From: Jonas M. <na...@us...> - 2006-01-29 20:22:24
|
Hey, On Sunday 29 January 2006 19:13, K.W...@gm... wrote: > Hello! > Few minutes ago I commited a rather big change. I divided the > clusterdisplay class into two classes: > - one named again clusterdisplay, which contains all the clever code > needed to display the data, clusters and trajectories and to keep the > history, > - the other named glutwin manages the trackball and the clusterdisplay > and the GLUT callbacks. It does some thread management, too. That is ok in principle. But can we please find another name for this class? I do not like how it has that "-win" suffix which seems to be used ubiquituously in the MS Windows world. Maybe be more verbose and use "window" or something the like or rename it to something similar. (Maybe it is plain silly to whine about variable names - but hey we are free to choose them!) > I hope you like it (please give feedback). As far as I can see, it > introduced no error to the code, except one: Currently, there is no status > message telling the computation is over. There were indeed some other errors introduced as you seem not to have worked on the most recent revisions. I noticed that changes to scripts/clusterviz which I had commited in revisions 116 and 121 were not anymore in the code. So I had to recommit that stuff. Please make sure always to work on the newest revisions - especially before commiting. > I would like to correct this issue by introducing another class responsible > for all communication between the OpenGL thread and the cluster algorithm > thread. This would probably simplify (i.e. shorten) the parameter list to > the cluster algorithm, too. Please tell me if you don't want this. In my opinion the introduction of such a class would seem reasonable. So please go ahead with that. > The trackball class has been cleaned up and the clusterviz script adapted > to employ the glutwin class instead of the clusterdisplay class. I know you > wanted more atomic commits, but I did not know how to split this step into > smaller ones. Could you please verify that issues like the one I found and described above did not happen to other parts of the code? I will look into that too, but having more eyes check it would be better. Yet, as far as I can tell from the diff between revision 124 and 125 nothing else of this kind has happend. > Kind regards, > Karsten. Regards, Jonas. |
|
From: <K.W...@gm...> - 2006-01-29 18:13:12
|
Hello! Few minutes ago I commited a rather big change. I divided the clusterdisplay class into two classes: - one named again clusterdisplay, which contains all the clever code needed to display the data, clusters and trajectories and to keep the history, - the other named glutwin manages the trackball and the clusterdisplay and the GLUT callbacks. It does some thread management, too. I hope you like it (please give feedback). As far as I can see, it introduced no error to the code, except one: Currently, there is no status message telling the computation is over. I would like to correct this issue by introducing another class responsible for all communication between the OpenGL thread and the cluster algorithm thread. This would probably simplify (i.e. shorten) the parameter list to the cluster algorithm, too. Please tell me if you don't want this. The trackball class has been cleaned up and the clusterviz script adapted to employ the glutwin class instead of the clusterdisplay class. I know you wanted more atomic commits, but I did not know how to split this step into smaller ones. Kind regards, Karsten. -- Wikar, der Desktop-Wiki: http://userpage.fu-berlin.de/~kweinert/wikar -- 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse für Mail, Message, More +++ |
|
From: <K.W...@gm...> - 2006-01-26 16:49:22
|
Hi,
yesterday I tried again to figure out the right scale value and I failed
again. I think I will wait until I know more about projection matrices and
OpenGL before I try again. However, here is what I found out:
If you call:
gluPerspective(angle, aspect, near, far)
P= glGetFloatv(GL_PROJECTION_MATRIX)
then for all reasonable values of near and angle, it holds
P(0,0,0) == (0,0,-1)
P(tan_degree(angle/2)*aspect, 0,0) == (1,0,-1)
P(0,tan_degree(angle/2),0) == (0,1,-1)
I assumed here that tan interprets its arguments as degree, so using
math.tan would involve some scaling. The right hand sides are results of the
matrix-by-vector-multiplication. I used this function to do it, but I am not
sure if it is the right way:
def apply_matrix(A,v):
if len(v)==3: v.append(1.)
res=[]
for zeile in A:
res.append(sum([a*vi for (a,vi) in zip(zeile,v)]))
if res[-1]!=0:
for i in range(len(res)): res[i]= res[i]/res[-1]
return res[:-1]
I have no clue how to use the projection matrix to synchronize the mouse
movement and the translation of the scene. I thought the view plane is
perpendicular to the z-axis, its center being at z=-near, but since you said
it's only a clipping parameter, I know I was wrong...
====
I spotted in the TODO file you'd like an orthogonal perspective, too. I
think this would require a rewrite of the zoom function. Maybe using
gluLookAt instead? And then the scale parameter of the pan function would be
different, too.
====
What I like to do on Sunday, is to divide the clusterdisplay class into two
classes, one for the window-handling (keyboard and mouse binding,
reshaping,..) and one for drawing the data points, cluster centres etc.
Please stop me if you don't want this.
====
One small change to trackball.py I comitted: Now gluPerspective is called at
the program start and when resizing the window, too. Hope everything went
right with svn.
Regards,
Karsten.
--
Wikar -- der Desktop-Wiki: http://userpage.fu-berlin.de/~kweinert/wikar/
--
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
|
|
From: Janne G. <gr...@mo...> - 2006-01-23 16:48:23
|
On Monday 23 January 2006 16:33, K.W...@gm... wrote: > Hello! > Changing the rotation center is not that difficult. Here is > a revised version of recalculateTransformationMatrix: nice. > I could not access the svn respository. It says > svn: PROPFIND Anfrage fehlgeschlagen auf '/InfoTheory' > svn: PROPFIND von '/InfoTheory': Autorisierung fehlgeschlagen > (https://cvs.molgen.mpg.de) > after I entered the username Janne sent me. It works for me. I will reply you in private for details. > Concerning the scale parameter, I am stuck. What do the near and far > parameter in gluPerspective mean? IIRC these are only clipping parameters. All objects nearer/farther away than the near/far parameter are not rendered. regards Janne |
|
From: Jonas M. <na...@us...> - 2006-01-23 16:38:47
|
Hey, On Monday 23 January 2006 16:33, K.W...@gm... wrote: > Hello! > Changing the rotation center is not that difficult. Here is > a revised version of recalculateTransformationMatrix: > > def recalculateTransformationMatrix(self): > glPushMatrix() > glLoadIdentity() > glTranslatef(-self.center[0], -self.center[1], -self.center[2]) > glRotated(self.angle, self.axis[0], self.axis[1], self.axis[2]) > glTranslatef(*self.center) > glMultMatrixf(self.transform) > self.transform = glGetFloatv(GL_MODELVIEW_MATRIX) > glPopMatrix() > > Note the two calls of glTranslate. Great! It works exactly the way I imagined it. > I could not access the svn respository. It says > svn: PROPFIND Anfrage fehlgeschlagen auf '/InfoTheory' > svn: PROPFIND von '/InfoTheory': Autorisierung fehlgeschlagen > (https://cvs.molgen.mpg.de) > after I entered the username Janne sent me. I can not reproduce any problems with the repository, so the problem must be related to your credentials. Maybe Janne can help out? Otherwise I might reconsider duplicating the svn-content into my private svn-server which I can readily administrate. I commited your above cited recalculateTransformationMatrix in the meanwhile. > Concerning the scale parameter, I am stuck. What do the near and far > parameter in gluPerspective mean? These two are distances from the eye point to clipping planes. Variable near specifies the minimum distance in front of which the objects are clipped and not shown. Variable far specifies the farthest distance behind which objects are clipped. Consider this (please use fixed font): /-------|--- /----------- | /---|-- | _/--- | | x-<=_ | Objects shown | Objects clipped \--- | | \---|-- | \----------- | \-------|--- |<--near---->| Objects clipped |<----------far-------------------->| Hope to help, kind regards, Jonas. |
|
From: <K.W...@gm...> - 2006-01-23 15:33:29
|
Hello!
Changing the rotation center is not that difficult. Here is
a revised version of recalculateTransformationMatrix:
def recalculateTransformationMatrix(self):
glPushMatrix()
glLoadIdentity()
glTranslatef(-self.center[0], -self.center[1], -self.center[2])
glRotated(self.angle, self.axis[0], self.axis[1], self.axis[2])
glTranslatef(*self.center)
glMultMatrixf(self.transform)
self.transform = glGetFloatv(GL_MODELVIEW_MATRIX)
glPopMatrix()
Note the two calls of glTranslate.
I could not access the svn respository. It says
svn: PROPFIND Anfrage fehlgeschlagen auf '/InfoTheory'
svn: PROPFIND von '/InfoTheory': Autorisierung fehlgeschlagen
(https://cvs.molgen.mpg.de)
after I entered the username Janne sent me.
Concerning the scale parameter, I am stuck. What do the near and far
parameter in gluPerspective mean?
Regards,
Karsten.
--
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
|
|
From: Jonas M. <na...@us...> - 2006-01-19 20:00:57
|
Hey, could you please test the present state of ClusterViz? I implemented a safeguarding mechanism to ensure that user specified transformation matrices have appropriate dimensionality. I would say with the two new features of panning and the projection of high-dimensional data working it would be about time for the release of version 0.2. What do think? Of course, before release time we will have to make sure there are no unnecessary glimpses in the code. Kind regards, Jonas. |
|
From: Jonas M. <na...@us...> - 2006-01-19 19:29:31
|
Hey, On Tuesday 17 January 2006 23:15, K.W...@gm... wrote: > I also tried the 4-D projection feature and it seems work pretty well! It > raises if I choose dim 4 on a 3-dimensional data set, though. How exactly did you mean this? If you give a 4x3 transformation matrix? Would be a good idea to do some dimensional consistency checking on user-defined transformation matrices. Regards, Jonas. |
|
From: Jonas M. <na...@us...> - 2006-01-19 19:03:10
|
Hey, (In the following I edited your mail a little to enhance readability, as it did not seem to conform to the 80 character per line standard)... On Tuesday 17 January 2006 23:15, K.W...@gm... wrote: > Hello, > a few minutes ago I posted two files for the panning feature. Since I made > several changes (which I sketch below), I did not post diffs but the whole > files. Please tell me if there is a better way to post. Well, now that you got an account for the SVN-server, make use of it! As soon as your changes do not contain any evident errors and your code behaves seemingly correct - commit it! This is way better than having us check every line of your coding. Also it easens the way we can verify. And thirdly: as it is a revision control system we could easily go back to a prior state should things turn out bad. So don't worry. But please try and follow some atomicity principle in the commits. I took a look at your code and it looks generally ok! The panning works basically and we could leave as it is. Though I imagined a slightly different behavior in the beginning: Now, when you pan, the point about which we rotate is not changed. I thought that the panning would also influence the point around which NEW rotations happen. Notice that only the new rotations would be affected. Thus it would probably not be possible anymore to separate the transform and center matrix anymore as we have it now (or the transform matrix would have to be modified while pannig - and it is not clear to me how this would boil down mathematically). My way would always perform the new rotations about the center of the view and therefore you could have the scene rotate about different points (than the mean of data) which might be desirable - or not. I would say this is open for discussion. > In this proposal, I tried to keep the things simple. There is even no pan > matrix kept, but rather the center member variable is put back in use. This seems to be a possible way to do it for now. > Furthermore, I moved the lastx/y member variables to the clusterdisplay > class. They are passed as parameters to gltbZoom and gltbPan. I think this > is a good idea since lastx/y stored a mouse state, and the clusterdisplay > does also store some mouse state (button and state) -- so why not store it > in one place? I also removed gltbMouse from the trackball class for the same > reason. We should make sure the code for user interaction is handled in one place or at least consistently. Let's rethink the locations. > And there is a second reason: > I suggest removing all glut code from the trackball class, since maybe > someday glut might not suffice anymore and then it would be nice to reuse > the trackball class. For me this reason seems minor. Do you have any specific other library in mind that would replace GLUT? Perhaps OpenGLContext or how it is called? This library semt to have some nice properties but it also was somewhat bulky and obstrusive. > At last, I commented out for clarity some unused code in clusterdisplay.py > (but all I changed were the mouse and motion methods.) And I ran a > ":%s/;$//g" in vim on the trackball.py, for aesthetical reasons ;-) That is principally ok - though it would have been preferable to do that in a different proposal / commit. Then it would have been clearer which changes were relevant and which were purely aesthetic. > The scale parameter in trackball.gltbPan needs to be set more carefully, > but this requires good knowledge of gluPerspective. If you like the overall > proposal, I will look into it. Go ahead! I placed the question of the scale parameter into the TODO file. > I also tried the 4-D projection feature and it seems work pretty well! It > raises if I choose dim 4 on a 3-dimensional data set, though. I will look into this. > I also like > the script which generates the > data. Wouldn't it be nice to use it directly rather than by way of a > intermediary data file? If you have propositions on how to do that.. I should not forget to say, that after checking your code (and slightly editing it: there was another variable in clusterdisplay that is now superfluous) I commited it. But please feel free to commit yourself in the future. Regards, Jonas. |
|
From: <K.W...@gm...> - 2006-01-17 22:15:24
|
Hello, a few minutes ago I posted two files for the panning feature. Since I made several changes (which I sketch below), I did not post diffs but the whole files. Please tell me if there is a better way to post. In this proposal, I tried to keep the things simple. There is even no pan matrix kept, but rather the center member variable is put back in use. Furthermore, I moved the lastx/y member variables to the clusterdisplay class. They are passed as parameters to gltbZoom and gltbPan. I think this is a good idea since lastx/y stored a mouse state, and the clusterdisplay does also store some mouse state (button and state) -- so why not store it in one place? I also removed gltbMouse from the trackball class for the same reason. And there is a second reason: I suggest removing all glut code from the trackball class, since maybe someday glut might not suffice anymore and then it would be nice to reuse the trackball class. At last, I commented out for clarity some unused code in clusterdisplay.py (but all I changed were the mouse and motion methods.) And I ran a ":%s/;$//g" in vim on the trackball.py, for aesthetical reasons ;-) The scale parameter in trackball.gltbPan needs to be set more carefully, but this requires good knowledge of gluPerspective. If you like the overall proposal, I will look into it. I also tried the 4-D projection feature and it seems work pretty well! It raises if I choose dim 4 on a 3-dimensional data set, though. I also like the script which generates the data. Wouldn't it be nice to use it directly rather than by way of a intermediary data file? Kind regards, Karsten. -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie |
