3 ms·
I can meet you in the middle on "considerably less attractive" :-) For what it's worth, if I wanted zero-cost then the way I'd probably write that in Common Li
by lukego 3y ago
I can meet you in the middle on "considerably less attractive" :-)
For what it's worth, if I wanted zero-cost then the way I'd probably write that in Common Lisp would be with a more spartan abstraction like:
(deftype f () 'double-float)
(deftype points () '(simple-array (2 *) f))
(-> euclidian-distance (f f f f) f)
(defun euclidian-distance (x1 y1 x2 y2)
(sqrt (+ (expt (- x2 x1) 2) (expt (- y2 y1) 2))))
(-> point@ (points integer) (values f f))
(defun point@ (points i)
(values (aref points 0 i)
(aref points 1 i)))
I'll grant you that's a kludge compared with your example. It wouldn't hold me back though. And I wouldn't consider trading in my lovely late-bound programming environment for an issue of this magnitude.
- foldr 3y agoTry extending this approach to, say, a Polygon datatype and see how far you get :)
- lukego 3y agoHard to please some people :)
- kaveh808 3y agoA design decision which needs to be made is at what level of abstraction should the data be "fixed", i.e. not to be manipulated with the full power of CL. This is often a flexibility vs. efficiency tradeoff. In my 3D CL system [0], I have so far kept all geometric data as naive CLOS classes as the intent of the system is to provide a sandbox for experimentation. I have thought of, perhaps one day, representing the geometry as a foreign library for efficient passing to the GPU. [0] https://github.com/kaveh808/kons-9 https://github.com/kaveh808/kons-9