On Tuesday 06 October 2009 22:31:27 Garth N. Wells wrote: > Johan Hake wrote: > > On Tuesday 06 October 2009 22:18:04 Anders Logg wrote: > >> On Tue, Oct 06, 2009 at 09:13:45PM +0100, Garth N. Wells wrote: > >>> Anders Logg wrote: > >>>> On Tue, Oct 06, 2009 at 10:05:24PM +0200, Johan Hake wrote: > >>>>> On Tuesday 06 October 2009 21:58:29 Andy Ray Terrel wrote: > >>>>>> On Tue, Oct 6, 2009 at 2:43 PM, Anders Logg <l...@simula.no> wrote: > >>>>>>> On Tue, Oct 06, 2009 at 02:28:40PM -0500, Andy Ray Terrel wrote: > >>>>>>>> Sorry for being dense but computing the SHA1 hash for what > >>>>>>>> essentially is a string compare seems a bit overkill. > >>>>>>> > >>>>>>> I want to avoid a call to strcmp in a piece of code that needs to > >>>>>>> be fast. What I do (it seems to work now) is to compute the 20 byte > >>>>>>> SHA-1 hash from the ~40 byte finite element signature which is > >>>>>>> typically something like > >>>>>>> > >>>>>>> FiniteElement('Lagrange', 'triangle', 1) > >>>>>>> > >>>>>>> I then cast the SHA-1 hash to an 8 byte void* and use that for > >>>>>>> comparison. This may not be very safe but this is not exactly > >>>>>>> cryptography. The number of possible hashes is the same as the > >>>>>>> address space so it should be fine. > >>>>>> > >>>>>> Yes I guess if you have a large number of comparisons it might be > >>>>>> faster. I forget there are a lot of signature checks for the > >>>>>> function space stuff. > >>>>>> > >>>>>> Computing the hash is O(n) just like strcmp, it really depends on > >>>>>> the constants. I would just do the timing before I said anything. > >>>>> > >>>>> Would it be an idea to extend ufc::finite_element with a > >>>>> hash_signature()? Then you can compute the hash using hashlib in > >>>>> python during code creation. > >>>>> > >>>>> Johan > >>>> > >>>> Sounds like a good idea. Only it requires changes to DOLFIN, UFC, FFC > >>>> and SyFi... > >>>> > >>>> Are there any objections to this? > >>> > >>> I'm not sure that this is a good idea. It complicates UFC. > > > > Complicates? One function returning a string? > > How would I write it by hand?
I have heard that the human brain is an amazing machinery. Couldn't you just learn the hash-algorithm and type it right in? ;) > It's common for new methods that the UFC-compliant code is hand generated. Ok, see you point. I have _never_ written a single line of ufc code so it did not struck me as a problem. Johan > > Garth > > But I agree with Anders that it > > > requires a lot to change and that it therefore is a good thing to think > > about it. > > > >> It's either that or using boost. I'm looking at both options. > >> > >> Calling boost is simpler since it requires the smallest change. If we > >> decide to go with that option now, we can keep this in mind for the > >> next update of UFC. > > > > Sounds good. > > > > Johan > > > >> -- > >> Anders > >> > >>> Garth > >>> > >>>>>> I looked there are a lot of libraries out there for this but OpenSSL > >>>>>> is by far the most pervasive. > >>>>>> > >>>>>> -- Andy > >>>>>> > >>>>>>>> On Tue, Oct 6, 2009 at 2:18 PM, Anders Logg <l...@simula.no> wrote: > >>>>>>>>> I'm contemplating adding a dependency to OpenSSL for computing > >>>>>>>>> hashes of things like element signatures. > >>>>>>>>> > >>>>>>>>> This is what breaks Kristian's code. Comparing element pointers > >>>>>>>>> does not work since the UFC class creates its own elements which > >>>>>>>>> are different from the ones existing in FunctionSpace classes. > >>>>>>>>> > >>>>>>>>> Would there be any difficulties with depending on OpenSSL? Are > >>>>>>>>> there simpler alternatives for a function that takes a string a > >>>>>>>>> returns a message digest like the SHA1 function in OpenSSL? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -----BEGIN PGP SIGNATURE----- > >>>>>>>>> Version: GnuPG v1.4.9 (GNU/Linux) > >>>>>>>>> > >>>>>>>>> iEYEARECAAYFAkrLmCAACgkQTuwUCDsYZdEk3ACgl7+tHjclHzLesh+g/1vOzIo9 > >>>>>>>>> tJsAn1fHGu+dzyA/ndNpy88/RFWNTbEB > >>>>>>>>> =24AA > >>>>>>>>> -----END PGP SIGNATURE----- > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> DOLFIN-dev mailing list > >>>>>>>>> DOLFIN-dev@fenics.org > >>>>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> DOLFIN-dev mailing list > >>>>>>>> DOLFIN-dev@fenics.org > >>>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > >>>>>>> > >>>>>>> -----BEGIN PGP SIGNATURE----- > >>>>>>> Version: GnuPG v1.4.9 (GNU/Linux) > >>>>>>> > >>>>>>> iEYEARECAAYFAkrLndAACgkQTuwUCDsYZdFlWACePT0FglJU+NTPnOBXi/h7WcHC > >>>>>>> E5EAn2vinxerlg6jTNuA4T+0Kp+CFuhz > >>>>>>> =68Dm > >>>>>>> -----END PGP SIGNATURE----- > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> DOLFIN-dev mailing list > >>>>>>> DOLFIN-dev@fenics.org > >>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > >>>>>> > >>>>>> _______________________________________________ > >>>>>> DOLFIN-dev mailing list > >>>>>> DOLFIN-dev@fenics.org > >>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > >>>>> > >>>>> _______________________________________________ > >>>>> DOLFIN-dev mailing list > >>>>> DOLFIN-dev@fenics.org > >>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>>- -- > >>>>> > >>>>> _______________________________________________ > >>>>> DOLFIN-dev mailing list > >>>>> DOLFIN-dev@fenics.org > >>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev > >>> > >>> _______________________________________________ > >>> DOLFIN-dev mailing list > >>> DOLFIN-dev@fenics.org > >>> http://www.fenics.org/mailman/listinfo/dolfin-dev > > > > _______________________________________________ > > DOLFIN-dev mailing list > > DOLFIN-dev@fenics.org > > http://www.fenics.org/mailman/listinfo/dolfin-dev > _______________________________________________ DOLFIN-dev mailing list DOLFIN-dev@fenics.org http://www.fenics.org/mailman/listinfo/dolfin-dev