<discocaml>
<mwzm> Here's my current implementation of the high-level API. Any ideas how to elegantly hide away `magnitude` `angle` `real_part` and `imag_part` in a different module?
<discocaml>
<mwzm> ```ocaml
<discocaml>
<mwzm> module R = Rect
<discocaml>
<mwzm> module P = Polar
<discocaml>
<mwzm>
<discocaml>
<mwzm> type t = Rect of R.t | Polar of P.t
<discocaml>
<mwzm>
<discocaml>
<mwzm> let make_from_ang_mag ang mag = Polar (P.make ang mag)
<discocaml>
<mwzm> let make_from_real_imag real imag = Rect (R.make real imag)
<discocaml>
<mwzm>
<discocaml>
<mwzm> let magnitude z =
<discocaml>
<mwzm> match z with Rect x -> R.magnitude x | Polar x -> P.magnitude x
<discocaml>
<mwzm>
<discocaml>
<mwzm> let angle z = match z with Rect x -> R.angle x | Polar x -> P.angle x
<discocaml>
<mwzm>
<discocaml>
<mwzm> let real_part z =
<discocaml>
<mwzm> match z with Rect x -> R.real_part x | Polar x -> P.real_part x
<discocaml>
<mwzm>
<discocaml>
<mwzm> let imag_part z =
<discocaml>
<mwzm> match z with Rect x -> R.imag_part x | Polar x -> P.imag_part x
<discocaml>
<mwzm>
<discocaml>
<mwzm> let add z1 z2 =
<discocaml>
<mwzm> let re = real_part z1 +. real_part z2 in
<discocaml>
<mwzm> let im = imag_part z1 +. imag_part z2 in
<discocaml>
<mwzm> Rect (R.make re im)
<discocaml>
<mwzm>
<discocaml>
<mwzm> let sub z1 z2 =
<discocaml>
<mwzm> let re = real_part z1 -. real_part z2 in
<discocaml>
<mwzm> let im = imag_part z1 -. imag_part z2 in
<discocaml>
<mwzm> Rect (R.make re im)
<discocaml>
<mwzm>
<discocaml>
<mwzm> Here's my current implementation of the high-level API. Any ideas how to elegantly hide away `magnitude` `angle` `real_part` and `imag_part` in a different module?
<discocaml>
<mwzm> ```ocaml
<discocaml>
<mwzm> module R = Rect
<discocaml>
<mwzm> module P = Polar
<discocaml>
<mwzm>
<discocaml>
<mwzm> type t = Rect of R.t | Polar of P.t
<discocaml>
<mwzm>
<discocaml>
<mwzm> let make_from_ang_mag ang mag = Polar (P.make ang mag)
<discocaml>
<mwzm> let make_from_real_imag real imag = Rect (R.make real imag)
<discocaml>
<mwzm>
<discocaml>
<mwzm> let magnitude z =
<discocaml>
<mwzm> match z with Rect x -> R.magnitude x | Polar x -> P.magnitude x
<discocaml>
<mwzm>
<discocaml>
<mwzm> let angle z = match z with Rect x -> R.angle x | Polar x -> P.angle x
<discocaml>
<mwzm>
<discocaml>
<mwzm> let real_part z =
<discocaml>
<mwzm> match z with Rect x -> R.real_part x | Polar x -> P.real_part x
<discocaml>
<mwzm>
<discocaml>
<mwzm> let imag_part z =
<discocaml>
<mwzm> match z with Rect x -> R.imag_part x | Polar x -> P.imag_part x
<discocaml>
<mwzm>
<discocaml>
<mwzm> let add z1 z2 =
<discocaml>
<mwzm> let re = real_part z1 +. real_part z2 in
<discocaml>
<mwzm> let im = imag_part z1 +. imag_part z2 in
<discocaml>
<mwzm> Rect (R.make re im)
<discocaml>
<mwzm>
<discocaml>
<mwzm> let sub z1 z2 =
<discocaml>
<mwzm> let re = real_part z1 -. real_part z2 in
<discocaml>
<mwzm> let im = imag_part z1 -. imag_part z2 in
<discocaml>
<mwzm> Rect (R.make re im)
<discocaml>
<mwzm>
<discocaml>
<octachron> You should link to your code in #general to avoid flooding the irc bridge.
<discocaml>
<mwzm> apologies
<discocaml>
<octachron> Overall, the design sounds like a not-so-great idea since the polar representation and the cartesian one have different time complexity and precision
<discocaml>
<octachron> I generally prefer the functor-based solution (which also avoids the issue of switching between representations in the same algorithm).
<discocaml>
<mwzm> do you mind point me to an example of a functor-based solution to this?
<discocaml>
<mwzm> do you mind point me to an example of a functor-based solution to something like this?
<discocaml>
<octachron> I mean just that by using `module F(C:Complex) = struct ... end`, one doesn't need to specialize the code to the `Complex` implementation.
<discocaml>
<mwzm> Ah I see what you mean
myrkraverk__ has joined #ocaml
myrkraverk_ has quit [Read error: Connection reset by peer]
jabuxas has joined #ocaml
nickiminjaj has joined #ocaml
nickiminjaj has joined #ocaml
nickiminjaj has quit [Changing host]
nickiminjaj has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
fererrorocher has joined #ocaml
emilknievel has joined #ocaml
kurfen has quit [Ping timeout: 246 seconds]
kurfen_ has joined #ocaml
jabuxas has quit [Ping timeout: 268 seconds]
bartholin has quit [Quit: Leaving]
nickiminjaj has joined #ocaml
nickiminjaj has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<discocaml>
<contextfreebeer> Are arrays not really designed to be used for many small collections of items? I am noticing a very dramatic performance decrease (humanly perceptible) by only changing from a set to an array and changing nothing else, but you can't conclude anything from that per se. Seems like array should always be better
<discocaml>
<contextfreebeer> lookup is irrelevant, the collections are not indexed directly, only iterated on, folded, etc.
<discocaml>
<contextfreebeer> one would think array is a better choice for that, since the size is frozen, no insertions or removals
<discocaml>
<contextfreebeer> I suspect it's just a red herring, very curious to know what the real cause is
<discocaml>
<contextfreebeer> probably having to do with sets being sorted and arrays not
<discocaml>
<contextfreebeer> Yeah, that's it, sorting the arrays makes the performance issues go away, at least in those cases where it was affecting performance, the impact on the order of elements on performance is unpredictable though, maintaining a sorted order isn't necessarily the right thing to do, but now I know the cause at least
Tuplanolla has joined #ocaml
<companion_cube>
Are you maybe reallocating the full array every time you add an item?