[ocaml-opengl] [Caml-list] standard 3d vector library in OCaml
Florent Monnier
monnier.florent at gmail.com
Fri May 10 16:48:47 BST 2013
2013/5/10, Daniel Bünzli:
>> But I don't like it for xy or xyz triples. I prefer tuples for this
>> because it makes it more easy to exchange data between different ocaml
>> components and modules. For these I usually prefer something easy to
>> exchanges between different ocaml modules than something easy to
>> exchange with C.
>
> It's not only about C, it's also about avoiding boxed representations to
> reduce memory usage and provide more memory locality. I agree deconstructing
> these values is more painful than tuples but I hope this encourages you to
> perform computations vector-wise rather than coordinate-wise -- the
> implementation of gg does the latter so that its users can work as much as
> possible vector-wise with reasonable performance, falling back to
> coordinate-wise computations only in bottlenecks.
I do understand.
But what I was trying to explain is that I usually have 2 or 3 or even
more modules/components/libs each using 3D coordinates.
Then it is easy to exchange values that are (float * float * float).
Anything else makes things difficult for exchanges and needs to be converted.
>> I appreciate the grey background.
>
> In my browser the background is white. In fact I now see that the background
> of the body is transparent in the stylesheet so that gray must be a default
> value in your browser...
Indeed, your page is the first one I see with transparent background.
It is not recommended to define text color without background color.
If the default browser background color is black one would see nothing.
>> What is the license of your CSS, is it the same than your libs?
>
> Yes feel free to reuse the stylesheet. Maintaining it is a little bit
> annoying as ocamldoc's markup tend to change from one version to the other
> and it's still hard to style because of formatting instructions in the
> markup and generation patterns that disallow you to distinguish certain case
> you'd like to (even with the deranged power of css).
I know, this is the same for me.
> Myself I hope I can eventually drop that in favour of what is happening
> around opam doc in the OCaml platform [1]; provided they provide a sensitive
> stylesheet, which for me means reasonably dense vertically, not too wide
> horizontally and good use of white space instead of box disease -- blame the
> css border property for that.
I was thinking to group html api-docs of many libs together (and maybe
even keep all recent versions of the libs) with a css switcher
(probably hosted on the ocaml forge). I even thought about a name like
"ocamldoc-zen-garden" (inspired from "css-zen-garden"). What would you
think about such an idea?
>> Also you're providing only linear interpolation.
>> Is it that you're not using easing, or is it that you're using another
>> module for it?
>
> For now I decided to leave that out of the library. I think there are many
> ways you'd like to do that depending on the context (e.g. see the links to
> shaping functions at the bottom of this page [2]). Since I was doubting I
> left it out.
I would enjoy to know which of these you are considering.
[...]
> [2] http://www.flong.com/texts/code/
A very good link, thanks a lot!
There's a huge amount of content, could you share which you think
would be the more interesting for reuse in OCaml?
> The goal of gg is also the keep a certain minimalism -- in fact I was even
> tempted to split the 2D from the 3D using the module language but eventually
> thought it was more consistant and less bureaucratic to have everything
> together.
It seems logic to me to do it the way you've made it.
I would only comment that if you add Sizes, BBoxes, then why not also
bounding-cirlces / bounding-spheres, complete math for geometry with
points, lines, planes, etc. (distances, intersections, projections,
etc.)
The internal representations for vectors and points are not public,
which would imply to integrate these inside your module. Would you
accept pull requests for these, or you want to keep the current
minimalism?
> I dislike libraries that give aliases for the same things. It puts a useless
> cognitive burden on code readers which have to remember that there are two
> ways of naming the same thing and it results in inconsistant library usage
> style. I usually go with shorter names (sometimes too short I agree) because
> I like code compactness and stick to 80 columns.
Maybe a compromise could be found,
between one letter function names:
Size3.w
Size3.h
Size3.d
and complete names:
Size3.width
Size3.height
Size3.depth
could be 3 letters abbreviations:
Size3.wid
Size3.hei
Size3.dep
I would recommend not to assume that everyone share the same cognition
and tastes than you.
--
Regards
More information about the OpenGL
mailing list