IMP-dev

imp-dev@salilab.org

869 discussions

Re: [IMP-dev] [IMP-commits] r1333 - in trunk/modules/em: include src
by Keren Lasker 28 Jan '09

28 Jan '09

Javi please update the SConsript files as well On Jan 28, 2009, at 3:26 PM, Notification of IMP commits wrote: > Author: javi(a)SALILAB.ORG > Date: 2009-01-28 15:26:55 -0800 (Wed, 28 Jan 2009) > New Revision: 1333 > > Added: > trunk/modules/em/include/endian.h > trunk/modules/em/src/endian.cpp > Log: > Some small change to complete ImageHeader class > > Added: trunk/modules/em/include/endian.h > =================================================================== > --- trunk/modules/em/include/endian.h (rev 0) > +++ trunk/modules/em/include/endian.h 2009-01-28 23:26:55 UTC (rev > 1333) > @@ -0,0 +1,61 @@ > +/** > + * \file endian.h > + * \brief functions to deal with endian of EM images > + * \author Javier Velazquez-Muriel > + * Copyright 2007-8 Sali Lab. All rights reserved. > +*/ > + > +#ifndef IMPEM_ENDIAN_H > +#define IMPEM_ENDIAN_H > + > +#include "em_exports.h" > +#include <iostream> > +#include <fstream> > +#include <cstring> > +#include <cstdio> > + > +IMPEM_BEGIN_NAMESPACE > + > +//! Reads from file in normal or reverse order > +/** \ingroup LittleBigEndian > + * \param[in] reverse If true, the data will be read in reverse > order. > + */ > +void reversed_read(void *dest, size_t size, size_t nitems, > std::ifstream& f, > + bool reverse); > + > +//! Writes to a file in normal or reversed order > +/** > + * \ingroup LittleBigEndian > + * > + * This function is the same as fread from C, but at the end there > is a flag > + * saying if data should be read in reverse order or not. > + * > + * \param[in] reverse If true, the data will be read in reverse > order. > + */ > +void reversed_write(const void* src,size_t size,size_t nitems, > + std::ofstream& f,bool reverse = false); > + > + > +//! Conversion between little and big endian. Goes both ways > +/** > + * \ingroup LittleBigEndian > + */ > +#define little22bigendian(x) byte_swap((unsigned char*)& x,sizeof(x)) > +void byte_swap(unsigned char* b, int n); > + > +//! Returns 1 if machine is big endian else 0 > +/** > + * \ingroup LittleBigEndian > + */ > +bool is_big_endian(void); > + > +//! Returns 1 if machine is little endian else 0 > +/** > + * \ingroup LittleBigEndian > + */ > +bool is_little_endian(void); > + > + > +IMPEM_END_NAMESPACE > + > +#endif /* IMPEM_ENDIAN_H */ > > Added: trunk/modules/em/src/endian.cpp > =================================================================== > --- trunk/modules/em/src/endian.cpp (rev 0) > +++ trunk/modules/em/src/endian.cpp 2009-01-28 23:26:55 UTC (rev 1333) > @@ -0,0 +1,85 @@ > +/** > + * \file endian.cpp > + * \brief Calculate score based on fit to EM map. > + * Copyright 2007-8 Sali Lab. All rights reserved. > +*/ > + > +#include <IMP/em/endian.h> > + > +IMPEM_BEGIN_NAMESPACE > + > +void reversed_read(void *dest, size_t size, size_t nitems, > std::ifstream& f, > + bool reverse) > +{ > + if (!reverse) { > + char *ptr = (char *)dest; > + f.read(ptr,size*nitems); > + } else { > + char *ptr = (char *)dest; > + bool end = false; > + for (size_t n = 0; n < nitems; n++) { > + for (int i = size - 1; i >= 0; i--) { > + f.get(ptr + i,1); > + if (f.eof() || f.bad()) { > + end = true; > + break; > + } > + } > + if (end) { > + break; > + } > + ptr += size; > + } > + } > +} > + > +void reversed_write(const void *src, size_t size, size_t nitems, > + std::ofstream& f,bool reverse) > +{ > + if (!reverse) { > + char *ptr = (char *)src; > + f.write(ptr,size*nitems); > + } > + else { > + char *ptr = (char *)src; > + bool end = false; > + for (size_t n = 0; n < nitems; n++) { > + for (int i = size - 1; i >= 0; i--) { > + f.put(*(ptr + i)); > + if(f.bad()) { > + end = true; > + break; > + } > + } > + if (end) { > + break; > + } > + ptr += size; > + } > + } > +} > + > +void byte_swap(unsigned char * b, int n) > +{ > + register int i = 0; > + register int j = n - 1; > + while (i < j) { > + std::swap(b[i], b[j]); > + i++, j--; > + } > +} > + > +bool is_little_endian(void) > +{ > + static const unsigned long ul = 0x00000001; > + return ((int)(*((unsigned char *) &ul))) != 0; > +} > + > + > +bool is_big_endian(void) > +{ > + static const unsigned long ul = 0x01000000; > + return ((int)(*((unsigned char *) &ul))) != 0; > +} > + > +IMPEM_END_NAMESPACE > > _______________________________________________ > IMP-commits mailing list > IMP-commits(a)salilab.org > https://salilab.org/mailman/listinfo/imp-commits

2 1

Re: [IMP-dev] [IMP-commits] r1333 - in trunk/modules/em: include src
by Keren Lasker 28 Jan '09

28 Jan '09

1 0

performance of Connectivity restraint
by Keren Lasker 28 Jan '09

28 Jan '09

hi all, I am writing a test case for adding hierarchy support in DOMINO, and it seems that the connectivity restraint works incredibly sssllllooowww between two proteins each of ~100 residues. i=0 ub = IMP.core.HarmonicUpperBound(1.0, 0.1) ss= IMP.core.DistancePairScore(ub) r= IMP.core.ConnectivityRestraint(ss) ps = IMP.Particles() ps_refined=[] for j in xrange(2): ps_refined.append(IMP.core.hierarchy_get_leaves(self.h_particles[i+j])) ps.append(self.particles[i+j]) for e in ps_refined: r.add_particles(e) beg = time.time() r.evaluate(None) end = time.time() dt = end - beg print 'connectivity restraint calculation took %9.6f Seconds' % (dt) The evaluate function takes ~20 seconds. am I missing something here? is there a faster implementation using some external library ? thanks, Keren.

2 6

removing indexes
by Daniel Russel 28 Jan '09

28 Jan '09

As was previously warned, I just patched the kernel to remove particle indexes. All the modules in svn are fixed so that they compile except for em, which didn't compile anyway. The changes to be aware of are: - Particles now have names which are strings identifying them (Particle::get_name, Particle::set_name). You should use these when you print particle-related error messages. - Particle::get_index goes away (it is currently left there for backwards compatiblity, but will really go away next week. Domino at least needs to be patched for this). - Model::get_particle(unsigned int) goes away (likewise, it is left in for backward compatibility until next week. The current implementation is linear though.) - the IMP_LIST_IMPL macro takes another argument, so just add a comma at the end if the compiler complains at you

1 0

Re: [IMP-dev] EM issues
by Javier Ángel Velázquez Muriel 28 Jan '09

28 Jan '09

> I can't build EM and so was poking through the code. > > - EM{noise, resample, etc} should be just be {noise, resample, etc} to be > consistent with other names in other modules and the core (all access are > already prefixed with via the paths and namespaces). > > Only the files have that name. Functions don't have the prefix. > > - in general it is less error prone to use an enum for modes rather than a > string (in noise, for example) as they get documented better and can only > exist in correct values > > > > - calling the arguments to add_noise op1 and op2 is horrible. They should > have descriptive names. > > add_noise uses different functions with different meanings for op1 and op2, thus they can't be described properly. They are 2 arguments. > > - given we have a rotation class, "project" should use that rather than its > own convention for defining rotations > > project is a hard function to develop, and the math behind it is far better implemented with a given convention. Hence the definition. > > - in general we avoid passing return return values as arguments > ("project"). At the very least, if you do that you need to make sure that > the non-return arguments are const refs, rather than refs and the last > arguments. > > reasonable > > _______________________________________________ > IMP-dev mailing list > IMP-dev(a)salilab.org > https://salilab.org/mailman/listinfo/imp-dev > > >

2 1

EM issues
by Daniel Russel 28 Jan '09

28 Jan '09

I can't build EM and so was poking through the code. - EM{noise, resample, etc} should be just be {noise, resample, etc} to be consistent with other names in other modules and the core (all access are already prefixed with via the paths and namespaces). - in general it is less error prone to use an enum for modes rather than a string (in noise, for example) as they get documented better and can only exist in correct values - calling the arguments to add_noise op1 and op2 is horrible. They should have descriptive names. - given we have a rotation class, "project" should use that rather than its own convention for defining rotations - in general we avoid passing return return values as arguments ("project"). At the very least, if you do that you need to make sure that the non-return arguments are const refs, rather than refs and the last arguments.

1 0

Re: [IMP-dev] [IMP-commits] r1297 - trunk/modules/algebra/include
by Daniel Russel 28 Jan '09

28 Jan '09

It also means that when someone creates a default Transformation3D, you don't know if they want the identity transform or just will initialize it later. And it's not symmetric with the Vector3D and the Rotation3D. On Jan 27, 2009, at 10:16 PM, Notification of IMP commits wrote: > Author: kerenl(a)SALILAB.ORG > Date: 2009-01-27 22:16:23 -0800 (Tue, 27 Jan 2009) > New Revision: 1297 > > Modified: > trunk/modules/algebra/include/Transformation3D.h > Log: > change to default constrator to initilize the identity transformation > > Modified: trunk/modules/algebra/include/Transformation3D.h > =================================================================== > --- trunk/modules/algebra/include/Transformation3D.h 2009-01-27 > 22:26:43 UTC (rev 1296) > +++ trunk/modules/algebra/include/Transformation3D.h 2009-01-28 > 06:16:23 UTC (rev 1297) > @@ -25,6 +25,8 @@ > typedef Transformation3D This; > //! construct and invalid transformation > Transformation3D(){ > + trans_=Vector3D(0.0,0.0,0.0); > + rot_ = identity_rotation(); > } > /** basic constructor*/ > Transformation3D(const Rotation3D& r, const Vector3D& t) > > _______________________________________________ > IMP-commits mailing list > IMP-commits(a)salilab.org > https://salilab.org/mailman/listinfo/imp-commits

3 6

Re: [IMP-dev] [IMP-commits] r1297 - trunk/modules/algebra/include
by Daniel Russel 27 Jan '09

27 Jan '09

I really don't like having the default constructor have some meaning like that since you have no way of knowing what it is doing without reading the documentation. Much better to have a method produce the identity transform. On Jan 27, 2009, at 10:16 PM, Notification of IMP commits wrote: > Author: kerenl(a)SALILAB.ORG > Date: 2009-01-27 22:16:23 -0800 (Tue, 27 Jan 2009) > New Revision: 1297 > > Modified: > trunk/modules/algebra/include/Transformation3D.h > Log: > change to default constrator to initilize the identity transformation > > Modified: trunk/modules/algebra/include/Transformation3D.h > =================================================================== > --- trunk/modules/algebra/include/Transformation3D.h 2009-01-27 > 22:26:43 UTC (rev 1296) > +++ trunk/modules/algebra/include/Transformation3D.h 2009-01-28 > 06:16:23 UTC (rev 1297) > @@ -25,6 +25,8 @@ > typedef Transformation3D This; > //! construct and invalid transformation > Transformation3D(){ > + trans_=Vector3D(0.0,0.0,0.0); > + rot_ = identity_rotation(); > } > /** basic constructor*/ > Transformation3D(const Rotation3D& r, const Vector3D& t) > > _______________________________________________ > IMP-commits mailing list > IMP-commits(a)salilab.org > https://salilab.org/mailman/listinfo/imp-commits

1 0

modules question
by Keren Lasker 27 Jan '09

27 Jan '09

hi, One of the functions defined in domino::TransformationMappedDiscreteSet is: algebra::Transformation3D get_trans(Particle *p_target, long state_ind) const; my domino.i includes Algebra.h, and still I get: modules/domino/pyext/domino_wrap.cc: In function 'PyObject* _wrap_TransformationMappedDiscreteSet_get_trans(PyObject*, PyObject*)': modules/domino/pyext/domino_wrap.cc:11592: error: 'algebra' has not been declared modules/domino/pyext/domino_wrap.cc:11592: error: expected `;' before 'result' modules/domino/pyext/domino_wrap.cc:11612: error: 'result' was not declared in this scope modules/domino/pyext/domino_wrap.cc:11621: error: expected type- specifier before 'algebra' modules/domino/pyext/domino_wrap.cc:11621: error: expected `)' before 'algebra' modules/domino/pyext/domino_wrap.cc:11621: error: expected `)' before ';' token (which corresponds to the return value of get_trans) should I add something else to domino.i to make it work? thanks, Keren.

2 2

Restraints and Hierarchy
by Keren Lasker 27 Jan '09

27 Jan '09

hi, Lets say I have two proteins A and B and I want to calculate a distance restraint between them. Usually it would be preferable to calculate the distance restraint between their centroids. However, their centroids are derived from the positions of their atoms. So - even if I calculate the centroids of the protein particle and add XYZ attributes, the calculating of the distance restraint will be true for the first time - but the state of the XYZ attributes of the protein particles should be updated according to the atom positions. Has anyway come across this issue before? thanks, Keren.

3 5

← Newer
1
...
51
52
53
54
55
56
57
...
87
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

IMP-dev