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/
generics might solve this but :shrug:
Yeah it'll all be a learning experience. Been using my over-engineered Lisp math library for about a decade, and I'm always annoyed at how difficult it is to read tabular matrix data when debugging stuff.
But in Lisp it looks like this, which is readable only because the PRNG seed made mostly the same digits to the left of the point:
[428.206840, 641.180912, 529.714861, 466.054420
449.058745, 849.850763, 606.009279, 977.445823
242.486631, 25.559494, 67.856057, 165.478953
597.418470, 179.321626, 859.131128, 479.821710]
If I use inheritance, and stick those in an abstract parent struct, that isn't going to cause issues with eg;
.new being undefined for the abstract type?
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.
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 may be that I have to support Float32 in the future, I'm not sure. It depends how FFI works in Crystal
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