The implementation of norm should use hypot to avoid overflow/underflow.

For V3.norm and V4.norm, should factor out the largest element in absolute value as Complex.norm.

Dear Daniel,

There is an interesting method for almost uniform sampling of SO(3) (i.e. the space
of all possible rotations).
This can be useful in some numerical simulations.

cf. "Super-Fibonacci Spirals: Fast, Low-Discrepancy Sampling of SO(3)"
by Marc Alexa

Regards,
F.

On thing that would be useful — to me at least — for boxes is to be able to "add" a point, i.e., to enlarge a box to make sure it contains an additional point. Signature (with maybe a better name):

val add_pt : box -> p -> box

(can be implemented for all box types). Doing it for a collection of points would also be interesting:

val bounding : p list -> box

See this comment by @Chris00 85585f5#commitcomment-20598156

Transforms that map boxes to boxes e.g. for Box2. Need to find a name and location though.

let map_box ~src ~dst =
  M3.mul (M3.move2 (Box2.o dst)) @@
  M3.mul (M3.scale2 (V2.div (Box2.size dst) (Box2.size src))) @@
  M3.move2 (V2.neg (Box2.o src))

See https://www.w3.org/TR/css-color-4/#ok-lab

utop # Color.red |> Color.to_lch_uv |> Color.of_lch_uv;;
- : v4 = (1 -9.96856e-09 -1.70861e-08 1) 

Colors with negative components are not rendered as far as I tested.

It seems to be quite easy to get invalid colors, here is another example with a larger negative component.

utop # V4.v 80. 120. 2. 1. |> Color.of_lch_uv;;
- : v4 = (0.198288 0.741156 -0.0747728 1)

I even got some components bigger than 1. on some examples.

The documentation

h represents hue in degrees in the range [0.] to [2pi]

should be fixed: either it is in degrees and then in the range 0..360, or it is in radians.

Hi,

Both of the times I used Gg, I found myself wanting {V2,V3}.unit to return {V2,V3}.zero on {V2,V3}.zero.
It's kind of a special case, but I think it is common in practice, so it would be useful to have a function ({V2,V3}.normalize ?) implementing this behavior.

What's your opinion about this?

-- Armael

My understanding of the specification should ensure that the following program always returns true, but if it is executed, we will see that most of the time it returns false. I expect this is related to floating point arithmetic.

Seq.ints 0 |> Seq.take 100 |> List.of_seq
    |> List.for_all (fun _ ->
           let x = Gg.P2.v (Random.float 10.) (Random.float 10.) in
           let y = Gg.P2.v (Random.float 10.) (Random.float 10.) in
           let box = Gg.Box2.of_pts x y in
           Gg.Box2.mem x box && Gg.Box2.mem y box )

For a concrete example, one can use the following snippet:

let x =
  Gg.P2.v 1.227721875450257238426843287016
                 1.217602532403128101634592894698
in
let y =
    Gg.P2.v 3.330991420098936561799973787856
                   0.148412743612841291351855943503
in
let box = Gg.Box2.of_pts x y in
Gg.Box2.mem x box && Gg.Box2.mem y box

Not sure how to fix that. Should we provide an optional eps argument to the Gg.Box2.mem function?

Basically under each function horizontal swatches like the vertical ones generated by test/color_schemes.ml. Would be nice if odoc could eventually solve ocaml/odoc#59

I have a usecase where I use Box2.t to represent arrows pointing in 2d-space. This means that they can have sizes that are negative in the x or y dimension. This has worked well until I found that maxx and friends don't support this.

The documentation of Box2 doesn't state that negative sizes are not allowed, and I like my current usecase. Should all Box2 functions be made to support negative sizes?

This would mean that BoxN and SizeN modules would also need to support negative sizes

While this is documented in the mathematical conventions it may be easy to overlook.

/cc @raphael-proust

Maybe we should simply include Stdlib.Float in Gg.Float. Need to review if we don't have conflicting names though.

Subject says it. I don't think there is a reason to require gg.top but not gg, and adding a dependency means one #require less.

It would be nice if this library, "providing basic types for computer graphics", would have robust geometrical primitives.

# let big = Box2.v V2.zero (Size2.v 10. 10.);;
# let small = Box2.v (V2.v 100. 100.) (Size2.v 1. 1.);;
# Box2.subset small big;;
- : bool = true

(same issue with Box3.subset)

A one is missing in the last column on that line

Are you sure that the compiler does use the signature to specialize functions such as Float.is_nan? I think adding a type annotation would be better/clearer, e.g.

let is_nan x = (x: float) <> x

The comment at the beginning of the Sizes section saying "An n-dimensional {e size} [s] represents extents in n-dimensional space" seems misleading to me. Indeed, at least in Cairo's parlance, an extent is equivalent to a bounding box. Or is it ambiguous and extent should be explained rather than being used as an explanation! 😊

Maybe native English speakers could tell whether "extent" usually refers more to the "distance over which it extends" or also the location of the object?
/cc @avsm @dsheets @talex5 @yallop @amirmc