Johan Hake wrote:
> 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? ;)
>
Maybe, but I would have to practice a little first.
Garth
>> 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
