From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id CC68C7EE51 for ; Fri, 10 May 2013 19:11:10 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anthony.tavener@gmail.com) identity=pra; client-ip=74.125.83.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of anthony.tavener@gmail.com designates 74.125.83.45 as permitted sender) identity=mailfrom; client-ip=74.125.83.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="anthony.tavener@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ee0-f45.google.com) identity=helo; client-ip=74.125.83.45; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anthony.tavener@gmail.com"; x-sender="postmaster@mail-ee0-f45.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUBAKcpjVFKfVMtk2dsb2JhbABSgz63XYg+dAgWDgEBAQEHCwsJFAQkgh8BAQEDAQEBAQsyARsJCQsBAwELBgULOyIBBAEMAQUBHAYTh3kBAwkGDKBNjD2CfoRgChknDViHRAEFDI8cB4NVA4kai1CCQoEmjioWKYRUHQ X-IPAS-Result: AtUBAKcpjVFKfVMtk2dsb2JhbABSgz63XYg+dAgWDgEBAQEHCwsJFAQkgh8BAQEDAQEBAQsyARsJCQsBAwELBgULOyIBBAEMAQUBHAYTh3kBAwkGDKBNjD2CfoRgChknDViHRAEFDI8cB4NVA4kai1CCQoEmjioWKYRUHQ X-IronPort-AV: E=Sophos;i="4.87,650,1363129200"; d="scan'208";a="16790001" Received: from mail-ee0-f45.google.com ([74.125.83.45]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 10 May 2013 19:11:10 +0200 Received: by mail-ee0-f45.google.com with SMTP id l10so590439eei.18 for ; Fri, 10 May 2013 10:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iI1p+W/frLgCpJp5FKFUj8iA25IPLidipbeE89NC7/A=; b=YG0MEphxKuWcXSQB0mCxzGRaAojcMztXu/utKYUiZysahin0pp+h08fHHVNHqgv1Vt 8yeSf7mKnm46mlDw1lCIYMCI/HGnSi328RzbH9X5DppGykIaZSMTo6yeiaCxWXDlKklb Ff/QbMxGM2tbiToERbO/aAuPfjp2xz0o+ZvL6i4c2xLQBVUkzDGjhkSDQL5UFxGdHetT PtyiQ7XnEI2bnxyLFc6mfTWlsoh687ArADEXGCkICwvq+d0bw4XBHonHSPR1jWKmVdKg F1zfkIN8CZm/ZhyCao/WDbIFBST8uWOy3n1cdXRv3a8GWuiAj15++w8CW6siCnf9yBnh k8Jw== MIME-Version: 1.0 X-Received: by 10.14.1.7 with SMTP id 7mr492203eec.41.1368205869800; Fri, 10 May 2013 10:11:09 -0700 (PDT) Received: by 10.14.118.12 with HTTP; Fri, 10 May 2013 10:11:09 -0700 (PDT) In-Reply-To: <313A2353F5864A008B0EA050D52AC789@erratique.ch> References: <5WRK1WTA-CFLT-K2D2-HI4C-UBS0MHNSFIAY@cs.ucy.ac.cy> <5189B929.2030808@riken.jp> <313A2353F5864A008B0EA050D52AC789@erratique.ch> Date: Fri, 10 May 2013 11:11:09 -0600 Message-ID: From: Anthony Tavener To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: Florent Monnier , ocaml-opengl , Caml List Content-Type: multipart/alternative; boundary=047d7b66f717d9945104dc6040df Subject: Re: [ocaml-opengl] [Caml-list] standard 3d vector library in OCaml --047d7b66f717d9945104dc6040df Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I've found that using a module prefix in combination with short (single letter) labels in mathematical contexts works very well. It strikes a balance of succinctness-in-use with enough verbosity to establish context. So I like Daniel's field names. :) They also correspond to shading language field designations. Before local module-opens I would avoid such names because opening more than one module would almost guarantee a conflict. Now I only open a few "prevasives"-like modules and use local-opens liberally. On Fri, May 10, 2013 at 11:01 AM, Daniel B=FCnzli wrote: > > > Le vendredi, 10 mai 2013 =E0 16:48, Florent Monnier a =E9crit : > > > 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? > > I think each of them serve different purpose (e.g. computational > trade-offs on embedded platforms) that's the reason why these things are > best left outside gg for now. > > > 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.) > > I don't plan to integrate these things, no pull requests please. At a > certain point I was planning to but it was becoming unwieldy -- remnant of > these ideas can be seen in the tmp/ directory of the first commit. Gg > provides you with the essentials to do 2D or 3D computer graphics. Sizes > and rectangles are ubiquitous: viewports, image extents, etc. and that's > the reason they are in. More general computational geometry tools are best > left to another dedicated library. > > > The internal representations for vectors and points are not public, > > which would imply to integrate these inside your module. > > Regarding the internal representation I still have to think about what I > will do. Gg is designed to interoperate with C so that means that the > representation will be cast in stone anyways. > > > 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 > > Well, no=85 it's horrible to read, hard to remember and inconsistent: if = you > look at all the other vector types in Gg their coordinate accessors all > have a single letter V2.{x,y}, P2.{x,y}, V3.{x,y,z}, P3.{x,y,z}, > V4.{x,y,z,w}, Color.{r,g,b,a}, Quat.{x,y,z,w}. Having Size2.{w,h} and > Size3.{w,h,d} feels natural. > > > I would recommend not to assume that everyone share the same cognition > > and tastes than you. > > I certainly don't assume that. I do however program and design to my > taste, not by consensus or compromise. > > Best, > > Daniel > > > _______________________________________________ > OpenGL mailing list > OpenGL@lists.ocaml.org > http://lists.ocaml.org/listinfo/opengl > --047d7b66f717d9945104dc6040df Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I've found that using a module prefix in combination w= ith short (single letter) labels in mathematical contexts works very well. = It strikes a balance of succinctness-in-use with enough verbosity to establ= ish context. So I like Daniel's field names. :) They also correspond to= shading language field designations. Before local module-opens I would avo= id such names because opening more than one module would almost guarantee a= conflict. Now I only open a few "prevasives"-like modules and us= e local-opens liberally.



On Fri, May 10, 2013 at 11:01 AM, Daniel B=FCnzli <= daniel.bue= nzli@erratique.ch> wrote:


Le vendredi, 10 mai 2013 =E0 16:48, Florent Monnier a =E9crit :

> A very good link, thanks a lot!
> There's a huge amount of content, could you share which you think<= br> > would be the more interesting for reuse in OCaml?

I think each of them serve different purpose (e.g. computational trad= e-offs on embedded platforms) that's the reason why these things are be= st left outside gg for now.

> 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<= br> > bounding-cirlces / bounding-spheres, complete math for geometry with > points, lines, planes, etc. (distances, intersections, projections,
> etc.)

I don't plan to integrate these things, no pull requests please. = At a certain point I was planning to but it was becoming unwieldy -- remnan= t of these ideas can be seen in the tmp/ directory of the first commit. Gg = provides you with the essentials to do 2D or 3D computer graphics. Sizes an= d rectangles are ubiquitous: viewports, image extents, etc. and that's = the reason they are in. More general computational geometry tools are best = left to another dedicated library.

> The internal representations for vectors and points are not public,
> which would imply to integrate these inside your module.

Regarding the internal representation I still have to think about wha= t I will do. Gg is designed to interoperate with C so that means that the r= epresentation will be cast in stone anyways.

> 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

Well, no=85 it's horrible to read, hard to remember and inconsist= ent: if you look at all the other vector types in Gg their coordinate acces= sors all have a single letter V2.{x,y}, P2.{x,y}, V3.{x,y,z}, P3.{x,y,z}, V= 4.{x,y,z,w}, Color.{r,g,b,a}, Quat.{x,y,z,w}. Having Size2.{w,h} and Size3.= {w,h,d} feels natural.

> I would recommend not to assume that everyone share the same cognition=
> and tastes than you.

I certainly don't assume that. I do however program and design to= my taste, not by consensus or compromise.

Best,

Daniel


_______________________________________________
OpenGL mailing list
OpenGL@lists.ocaml.org
http:/= /lists.ocaml.org/listinfo/opengl

--047d7b66f717d9945104dc6040df--