[erlang-questions] Erlang shows its slow face!

[Edmond Begumisa]

Small Correction...

> Of all the variations presented so far, IMO, Garcia's first is the  
> easiest to follow

They've been since some variations of this that are equally easy to follow  
and try to eliminate small but important flaws (including yours). The  
one's that try to use functions instead of list combination generators for  
the combinatorial part are the ones I have trouble reading. But that may  
just be me.

- Edmond -


On Tue, 16 Nov 2010 02:02:50 +1100, Edmond Begumisa  
<ebegumisa@REDACTED> wrote:

> Hello Richard,
>
> I have a question...
>
>> Erlang is a fine tool for jobs like this one.
>
> Interesting... I would have never thought this. I would have  
> instinctively reached for a language with mutable memory, thinking that  
> this would make the most sense for combinatorial* work (I don't know  
> this for fact, and I could be very wrong, but that's what instinct would  
> tell me.) But then, I'm relatively new to Erlang.
>
> * I've been calling this permutation but I don't know if that's accurate.
>
>> There is little point in optimising a bad algorithm.
>
> Well put. But say you have an 'ok' algorithm. Not the best, but not  
> blatantly flawed either.
>
> I think of optimisation as something you put on a version 2 to-do list.  
> Optimisation to me means staring hard at code and trying to figure out  
> ways to get it to perform better (faster, less memory, less CPU time,  
> etc). This normally means re-writing code that's easy to follow into  
> code that's no-so-easy to follow. Mind you, for Erlang, I don't look at  
> parallelising as optimisation as others seem to. To me, it's just a  
> building block made available and normally it can be applied without  
> changing an algo too much (I'd say it's not used enough).
>
> Of all the variations presented so far, IMO, Garcia's first is the  
> easiest to follow (ignoring that obvious flaw with the repeated list:seq  
> call). A non-mathematical mind like myself can see exactly what he's  
> trying to do. The others (including the ones from Willem and Tony that I  
> tried to parallelise), seem harder to follow. Maybe that's coz they are  
> optimised versions. The authors could have stared long and hard.
>
> So my question is: if version 1 isn't performing "reasonably" acceptably  
> for Garcia's purpose, and version 1 isn't blatantly flawed. Isn't this a  
> strong indicator that he's using the wrong tool?
>
> - Edmond -
>
> On Mon, 15 Nov 2010 12:29:49 +1100, Richard O'Keefe <ok@REDACTED>  
> wrote:
>
>>
>> On 14/11/2010, at 10:17 PM, Hynek Vychodil wrote:
>>  Anyway Erlang is not
>>> right tool for this job. You should use NIF if performance matter.
>>
>> Erlang is a fine tool for jobs like this one.
>> In fact, given its support for large integers,
>> it is about as good for combinatorial algorithms as
>> Smalltalk, though perhaps not as good as Lisp.
>> (But see LFE...)
>>
>> There is little point in optimising a bad algorithm.
>> A fairly naive rewrite turns it from O(N**3) into O(N**2).
>> What really counts here is how easy it is to spot the
>> algorithmic problem and switch to a better algorithm.
>>
>>
>>
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>>
>
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/