I never said we should not provides ways to tune code and get higher throughput or arbitrary sized numbers. There has to be a path to satisfies those needs. The stuff that was proposed on this thread (specialized ops, ...) should allow people to tune their code if they require to do so.
I said that the default approach had to be simple and should not be made solely on the basis of numeric intensive apps. If Rich finds auto promotion too costly to implement (and maintain) versus using longs that's reasonable, (he's the best placed to take that decision), then lets use longs and throw overflow exceptions. The default will still remain simple, if your numbers don't fit in a long it will bump. Anyway the long size as we know it will increase in size in the future so it may become a mood point. Auto promotion if doable can just enlarge the number of apps not having to care about huge number limits. Simplicity is not equivalent to a lack of sophisticated approaches when required. Caring about which numeric implementation to choose is not my first concern when it comes to design, it comes later if it ever comes up as an issue. I saw such needs in 30 years a number of times mostly in real time systems with limited hardware resources. Not a common need in apps in general these days. Today numeric performance is needed by some specific and narrow needs (heavy graphics, ,,,). If you really want max. numeric performance, work on a bridge to submit computations to your graphic card.... there will be greater payoffs than staying within the JVM. Luc P. 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. > > -- > 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 -- 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
