I agree with Zvi here. Such a change would cause much confusion to users who do not want this feature. It would be better to add a new datatype for this and a set of functions operating on this type. BUT I would put the new BIFs in a separate module and not just dump them into erlang.<br>
<br>I don't agree with you on your other "mistakes":<br><br>1. With records we were constrained to make them as fast as pure tuple operations. We maybe could have made a new datatype for it though.<br>2. And I think that lists are a wonderful datatype for processing strings.<br>
<br>Robert<br><br><div><span class="gmail_quote">On 06/04/2008, <b class="gmail_sendername">Zvi</b> <<a href="mailto:exta7@walla.com">exta7@walla.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br> James,<br> <br> With generic tuples it's impossible to implement efficient SIMD operations.<br> Also there is many undefined/confusing behaiviors, when elements of tuple<br> are not numeric.<br> <br> This is the same kind of mistakes, like 2 bad design decisions made in<br>
Erlang:<br> 1. "Ohh, record looks just like a tuple!", so let's throw in some syntactic<br> sugar for this, instead of real immutable structs/dictionaries.<br> 2. "Ohh, string looks just like a list of integers!", so let's throw in some<br>
syntactic sugar for this, instead of implementing real Unicode-aware<br> immutable string datatype.<br> <br> In my opinion Erlang might be a good match, not only for High Availability<br> (HA) applications, but also High Performance Computing (HPC) applications,<br>
and it might wipe out MPI as de-facto standard, by additing highly optimized<br> Matlab-like "matrix of double"/"multidimensional array of double" datatype.<br> Array Programming is also such a good fit for FP, since you may naturaly<br>
extend map and fold/reduce for this datatype.<br> Also, vector math, even if not implemented efficiently, makes you much more<br> productive and allows you to prototype with one-liners from shell. Combining<br> this with Erlang's built-in concurrency and distrition primitives it makes<br>
it Super-High-level language. Unlike other Array programming languages, I<br> propose that Erlang matrix datatype will be immutable.<br> <br> So, in my view Erlang should be H^3 (read as H-cube) language:<br> <br> Highly Available<br>
HPC<br> High-level<br> <br> For the start maybe it's possible to take some code from PyNum<br> (unfortunately Octave has GNU license).<br> <br> <a href="http://en.wikipedia.org/wiki/Category:Array_programming_languages">http://en.wikipedia.org/wiki/Category:Array_programming_languages</a><br>
<a href="http://en.wikipedia.org/wiki/Numpy">http://en.wikipedia.org/wiki/Numpy</a><br> <a href="http://en.wikipedia.org/wiki/GNU_Octave">http://en.wikipedia.org/wiki/GNU_Octave</a><br> <br> <br> BTW, I somewhat disappointed with vector math implemented in Matlab and<br>
kdb+/Q. It's not much faster than serial Erlang code (and much much slower<br> than parallel Erlang code). You can see it in my little PI calculation<br> benchmark:<br> <br> Matlab:<br> <br> >> tic; N=1000000; Step = 1/N; PI = Step*sum(4./(1+(((1:N)-0.5)*Step).^2));<br>
>> toc<br> Elapsed time is 0.125428 seconds.<br> <br> Q:<br> <br> q)N:1000000<br> q)Step:1%N<br> q)PI: {[]; Step*((4f % (1f + ((Step*((1+ til N)-0.5)) xexp 2))) +/)}<br> q)PI()<br> 3.141593<br> q)\t do[1000;PI()]<br>
264359<br> q)<br> <br> i.e. 264 ms<br> <br> on my dual CPU workstation I getting ~ 200 ms.<br> <br> <br> Erlang:<br> <br> Serial tail-recursuive Erlang version takes ~ 170 ms - 300 ms (on different<br> machines).<br> Parallel Erlang version on 16 cores takes 15 ms<br>
<br> Zvi<br> <br> <br> <br> James Hague wrote:<br> ><br> >> Has anyone given any thought to adding vector instructions or otherwise<br> >> adding support for vectors to Erlang?<br> ><br> > I've proposed adding APL-style vector operations on tuples:<br>
><br> > {1,2,3} + 1 ==> {2,3,4}<br> > {1,2,3) * 2 ==> {2,4,6}<br> > 2 * {1,2,3} ==> {2,4,6}<br> > {1,2,3} + {3,2,1} ==> {4,4,4}<br> ><br> > The operations apply to the top level only; they're not recursive.<br>
> This would make vector math style code a lot simpler to write in<br> > Erlang. One of the points raised in response to this was that we<br> > shouldn't be overloading tuple operations like this, but have a<br>
> special "vector of float" type. I'm not sure I agree with that.<br> > _______________________________________________<br> > erlang-questions mailing list<br> > <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br> ><br> ><br> <br><br> --<br> View this message in context: <a href="http://www.nabble.com/Vector-instructions-tp16468138p16529946.html">http://www.nabble.com/Vector-instructions-tp16468138p16529946.html</a><br>
Sent from the Erlang Questions mailing list archive at Nabble.com.<br> <br> _______________________________________________<br> erlang-questions mailing list<br> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br> </blockquote></div><br>