While there are "double" types for OpenGL, like GLdouble (reference-1<http://opengl.czweb.org/ch03/031-034.html>, reference-2 <http://opengl.czweb.org/ch03/031-034.html>), their use is, softly speaking, not wide-spread: reference-3<http://blog.hvidtfeldts.net/index.php/2012/07/double-precision-in-opengl-and-webgl/>, reference-4<http://stackoverflow.com/questions/10012985/why-does-opengl-use-float-rather-than-double> and reference-5<http://stackoverflow.com/questions/2079906/float-vs-double-on-graphics-hardware>. I think that the real situation is very clearly described in these papers. You won't find an OpenGL programmer using double precision, unless he either has a *very* specific task or he does not know what he's doing. Doubles may be considered an archaism in OpenGL. At least, that's the current plot. I know no programmers who used doulbes in OpenGL since version 2.x, as far as I remember.
As for the binding that I am using, - it is LWJGL, please see their javadoc <http://lwjgl.org/javadoc/>to find no mentions of double (for real usage at least). Also, the function glVertex*d is not often used from Java bindings, as far as I know. I did not browse through all their reference pages, but I am almost sure, you won't find a single mention of use of 64-bit types. You can only find such references in rather old info. Yeah, for what reason? Imagine you buy, say 4Gb super-cool NVIDIA videocard to play a game or run a scientific sumulation and... suddenly it becomes as if being 2Gb? No, doubles are not present on GPUs. Sorry, I am pretty tired argumenting that on IRC already... :) I work in multimedia company, believe me, I know what I'm saying. And Mikera is right. I did not mention that in my original message, but we also work with simply lots of hardware (sometimes we equip huge building and complexes, full with all kinds of electronics and comms and devices and stuff). Yes, they are 32, 16 and often even 8 bit hardware components. That is a huge market, really. I understand that there can be some challenge implementing the support for the datatypes, but, the benifit of doing that outweights the costs so much.. like having two hands instead of one. And don't say that most things in the world require one hand to do them.. On Monday, September 9, 2013 9:12:49 PM UTC+4, tbc++ wrote: > > Also, how much of this is a limit of the OpenGL library you are using? The > raw OpenGL API supports glVertex3d and glVertex3f. Is the double version > not supported by your java interface library? > > Timothy > > > On Mon, Sep 9, 2013 at 11:07 AM, Timothy Baldridge > <tbald...@gmail.com<javascript:> > > wrote: > >> It's worth noting that the restrictions to IFn do not apply to >> definterface and deftype. Not that solves all (or any) of your problems, >> I've used definterface before to lock down the actual types used. >> >> Timothy >> >> >> On Mon, Sep 9, 2013 at 11:03 AM, Jozef Wagner >> <jozef....@gmail.com<javascript:> >> > wrote: >> >>> You can typehing ints for locals (let, loop), restrictions are just for >>> function arguments. >>> AFAIK the reason is combinatorial explosion at >>> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/IFn.java#L91 >>> I have the same problem with char. Because I cannot typehint e.g. my >>> whitespace? function with ^char, I recieve a boxed Object and thus cannot >>> use == for comparison. >>> >>> JW >>> >>> >>> On Mon, Sep 9, 2013 at 6:02 PM, Mikera <mike.r.an...@gmail.com<javascript:> >>> > wrote: >>> >>>> +1 for supporting all the JVM primitive types properly. >>>> >>>> It is worth noting that the benefits would extend much further than >>>> just OpenGL, e.g.: >>>> - int is a commonly used type in Java interop. Casting to/from it all >>>> the time is a minor annoyance/overhead >>>> - int is the type used for array indexing on the JVM >>>> - all the small (< 8 byte) primitive types save memory footprint, >>>> which is important since memory bandwidth is the limiting factor in some >>>> workloads >>>> - int/float fit into a register (and therefore perform much better) on >>>> 32 bit machines (which still exist, believe it or not....) >>>> - char is a pretty useful primitive type if you are doing text >>>> processing >>>> - byte is also frequently useful, especially for IO >>>> >>>> I believe that with some enhancements to the Clojure compiler, >>>> supporting all the JVM primitive types shouldn't be too difficult, and it >>>> would provide many benefits both in terms of overall performance and >>>> interop convenience. >>>> >>>> On Monday, 9 September 2013 21:43:12 UTC+8, Alex Fowler wrote: >>>>> >>>>> Hello! >>>>> >>>>> With this letter I would like to receive an answer from somebody from >>>>> the development team (if anyone else has something to say, you're surely >>>>> welcome :) ). >>>>> >>>>> I am working for a big multimedia company and recently I have been >>>>> considering moving to Clojure as the main language of development. We >>>>> have >>>>> been doing Java and Scala before, but now when I tried Clojure and see >>>>> the >>>>> possibilities it provides, I would definitely stand for it to be our >>>>> ground. However, while I am so satisfied with everything - the language, >>>>> the community, the Java interop, there is still something that hinders >>>>> and >>>>> makes me linger. Namely, the lack of good support of floats and ints in >>>>> the >>>>> language. While many people would not consider it to be a huge >>>>> disadvantage >>>>> or even notice it, things are not so bright when it comes to OpenGL. >>>>> >>>>> The case is that OpenGL and 3D graphics hardware in general has no >>>>> support for doubles or longs. Therefore, all libraries, all data and all >>>>> computations are meant to be performed with floats and ints (shaders >>>>> too). >>>>> Due to the lack of good support of these data types in Clojure (for >>>>> example, there are no ^float and ^int typehints, float and int values can >>>>> only be typecasted to, all calculations always retain doubles and longs), >>>>> results in too many extra typecasts, which are absolutely unnecessary and >>>>> take too much time. So, calculations become very cumbersome, even if we >>>>> do >>>>> not take mandatory boxing into account. >>>>> >>>>> Considering that such kinds of calculations are usually abuntant in >>>>> the aforementioned types of applications, the penalty grows really huge. >>>>> I >>>>> have endeavoured several discussions on the IRC to find out possible >>>>> workarounds. Although many good proposals by many good people were made, >>>>> aimed at improving the situation, none of them could solve the >>>>> fundamental >>>>> lack of the ability to manipulate 32bit primitive (or even boxed) data >>>>> types. That lack renders Clojure not really suitable for heavy-load >>>>> OpenGL >>>>> applications that require somewhat extensive calculations: some kinds of >>>>> games, simulations, generative graphics and so on. Considering how >>>>> superior >>>>> Clojure is to any other language available for JVM, that black spot looks >>>>> especially embarrasing. And I could imagine falling back to Java for fast >>>>> computations, just like we fall back to ASM in, say C, that is very >>>>> undesirable and discouraging, since we want to pick Clojure for Clojure >>>>> and >>>>> it will be too cumbersome to make 50/50% Java/Clojure apps just to work >>>>> around that design decision. >>>>> >>>>> Therefore, while deciding if to pick Clojure as the base for our >>>>> development, I would like to know answers to the following questions: >>>>> >>>>> 1) What is the current reason for the support for these types to be >>>>> missing? >>>>> 2) Are there any plans for improvement of support for floats, ints and >>>>> maybe, localized unboxed calculations? Or is there some advice on how to >>>>> enable their support? >>>>> 3) What is you vision for Clojure + OpenGL applications? >>>>> 4) Is it possible to request support for floats, ints and maybe shorts >>>>> for the language? >>>>> 5) Is it possible to request support for localized unboxed >>>>> calculations, like (with-unboxed ... ) and localized float-only and >>>>> int-only calculations, like, say in special macros (with-floats-&-ints >>>>> ... >>>>> here go (+) (-) and stuff ONLY with floats/ints ... ) ? >>>>> >>>>> Preferably, I would like to hear the answers from somebody from the >>>>> development team, because I have already received enough support from the >>>>> community, on the IRC, I appreciate it, but now I have to make a serious >>>>> choice for our company and I feel quite responsible for that. I also feel >>>>> that these questions are very important for any specialist that works >>>>> with >>>>> OpenGL and influence Clojure acceptance for OpenGL-enabled applications >>>>> world-wide. Thank you. >>>>> >>>> -- >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Clojure" group. >>>> To post to this group, send email to clo...@googlegroups.com<javascript:> >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> To unsubscribe from this group, send email to >>>> clojure+u...@googlegroups.com <javascript:> >>>> 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 unsubscribe from this group and stop receiving emails from it, send >>>> an email to clojure+u...@googlegroups.com <javascript:>. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com<javascript:> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com <javascript:> >>> 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 unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> >> >> -- >> “One of the main causes of the fall of the Roman Empire was that–lacking >> zero–they had no way to indicate successful termination of their C >> programs.” >> (Robert Firth) >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
