The Crystal programming language | http://crystal-lang.org | Fund Crystal's development: http://is.gd/X7PRtI | Docs: http://crystal-lang.org/docs/ | API: http://crystal-lang.org/api/
i dont think so?
Unsure if I will even need any mixins for the code I have so far anyway
oh i see what you mean
Yes, that's a given
The one thing I'm unsure about is how to get my
T type parameter to resolve for the topmost type....it was passed into include before
My intention is to only allow instances in this library to have Float64 for elements in the various containers, and I don't want type inference to permit anything else, so should be able to just make sure all contructors restrict their types, in addition to the above.
yea just do that and dont use generics
Probably don't anymore. I only needed it before because Indexable required a type parameter.
well it would be
Indexable(Float64)
Yeah I was only using T because a lot of function signatures became too long with Float64 everywhere
iirc anyway
i always find its better to be explicit
even tho crystal allows you to not use them, i always do
at least on publicly facing libs and APIs
It's a performance trap to use doubles on the GPU in most cases, so prob have to send them to the driver with single precision
The Scalar module was/is bothering me, and much moreso with inheritance
cant those 2 methods just live on the parent and not worry about it
It is unrelated to any of the aggregate types...it defines some functions for Float64 elements themselves
I could, but how would I make it private to users...they're sort of just an implementation detail of some of the aggregate types' methods
wouldnt show up anywhere since you're not including/extending anything
oh
I cannot read
That was suggested in this chat quite a few days ago by someone, because 99% of use cases are going to be in the form of a binary operator, not the method call syntax...and can only use a whitelisted set of symbols there
I'm not sold on it either, but
Origin::Vector3.nearly_equal? v1, v2 user code calling Origin::Util.nearly_equal? f1, f2, rel_tol, abs_tol internal code isn't too bad I suppose
why not
v1 =~ v2
or is that how it was?
Or did I misunderstand?