On Jun 22, 3:00 pm, Daniel Gagnon <redalas...@gmail.com> wrote: > > Lets just make things easy for the > > average guy.., > > If we base the decision on the average guy not writing high performance > numeric apps, then we should also base it on the fact that he does not need > more than a long in 99% of cases either as Rich points out. And longs are a > much simpler concept to grok.
My work depends. I've written some audio code in different languages and that needs to be fast. But writing fast math-heavy code is not just a case of "no auto-promotion" or "primitives only". You'll have to be very careful about float <-> int conversions too (so, for instance, you want to multiply floats only or ints only wherever possible) and you also need to be very careful about how your algorithm is structured. My point is, I expect all code that isn't written with performance in mind to be slow. But for almost all non-audio work, I really don't care all that much, as long as I can get better performance in the few pieces of code that need it. For that reason, I really dislike having to use the ugly *' variants to get the "correct" math ops. To me, a 10 to 20% "slowdown" (or rather, less accelleration compared to the current 1.1 branch) is worth it if it guarantees that "unbounded" data can still be handled by naive code, and it encourages use of "correct" math in code where speed isn't that important. Really speed-intensive code will need to be documented as using specific input types. I.e. for audio code, you generally use floats or doubles for all data, and any deviation from that will cause problems. For this kind of code, there is no reason at all to support extra-wide numbers. But for most code, I expect to be able to just cram in a bunch of "untyped" numbers and get the correct answer even if it's a bit slower. I do see the argument that ''longs and doubles should be enough for everybody'' and it's generally true. But making them the default will mean that in the longer run you won't be able to use your bigints with any library, since they'll all default to using the exception-throwing math. I may have misinterpreted the current proposals somewhere, so please correct me if I'm wrong. Keeping up with this thread is kinda hard. Just my 2 cnts. Joost. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
