Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 06:03
    CoelacanthusHex synchronize #11980
  • 02:29
    Blacksmoke16 labeled #12532
  • 02:28
    cyangle opened #12532
  • 02:28
    cyangle labeled #12532
  • Sep 27 20:04
    analogsalad synchronize #12530
  • Sep 27 20:01
    straight-shoota labeled #12531
  • Sep 27 20:01
    straight-shoota labeled #12531
  • Sep 27 20:01
    straight-shoota labeled #12531
  • Sep 27 20:01
    straight-shoota opened #12531
  • Sep 27 15:29
    Blacksmoke16 labeled #12530
  • Sep 27 15:29
    Blacksmoke16 labeled #12530
  • Sep 27 15:23
    analogsalad edited #12530
  • Sep 27 15:20
    analogsalad opened #12530
  • Sep 27 14:17
    asterite edited #12144
  • Sep 27 11:38
    asterite synchronize #11597
  • Sep 27 11:23
    zw963 labeled #12529
  • Sep 27 11:23
    zw963 opened #12529
  • Sep 27 11:13
    asterite reopened #11597
  • Sep 27 10:50
    straight-shoota milestoned #12527
  • Sep 27 10:50
    straight-shoota milestoned #12527
mfiano
@mjfiano:matrix.org
[m]
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
mfiano
@mjfiano:matrix.org
[m]
Ah.
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.
George Dietrich
@Blacksmoke16
then why do you need generics?
yea just do that and dont use generics
mfiano
@mjfiano:matrix.org
[m]
Probably don't anymore. I only needed it before because Indexable required a type parameter.
George Dietrich
@Blacksmoke16
generic inheritance can be kinda buggy
well it would be Indexable(Float64)
mfiano
@mjfiano:matrix.org
[m]
Yeah I was only using T because a lot of function signatures became too long with Float64 everywhere
iirc anyway
George Dietrich
@Blacksmoke16
:S
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
mfiano
@mjfiano:matrix.org
[m]
I do agree.
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
George Dietrich
@Blacksmoke16
:shrug:
mfiano
@mjfiano:matrix.org
[m]
and also what opengl binding libraries expect I suppose
The Scalar module was/is bothering me, and much moreso with inheritance
George Dietrich
@Blacksmoke16
how so?
cant those 2 methods just live on the parent and not worry about it
mfiano
@mjfiano:matrix.org
[m]
It is unrelated to any of the aggregate types...it defines some functions for Float64 elements themselves
George Dietrich
@Blacksmoke16
if they're unrelated put em in a Utility namespace?
mfiano
@mjfiano:matrix.org
[m]
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
George Dietrich
@Blacksmoke16
nodoc it
wouldnt show up anywhere since you're not including/extending anything
mfiano
@mjfiano:matrix.org
[m]
Sold
George Dietrich
@Blacksmoke16
not sure im a fan of the =~ method name tho for a class method
mfiano
@mjfiano:matrix.org
[m]
For a class name?
oh
I cannot read
George Dietrich
@Blacksmoke16
works better when its between instances, but a more english name might be better
mfiano
@mjfiano:matrix.org
[m]
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
George Dietrich
@Blacksmoke16
wait
why not v1 =~ v2
or is that how it was?
mfiano
@mjfiano:matrix.org
[m]
You just said you didn't like that, and neither do I tbh
Or did I misunderstand?
George Dietrich
@Blacksmoke16
it looked like it was used as Origin::Scalar.=~ v1, v2
due to the extend self
mfiano
@mjfiano:matrix.org
[m]
It is internally, because you cannot use the method call notation without a module prefix
The extend self was needed too
George Dietrich
@Blacksmoke16
id still use nearly_equal? but have def =~ instance method use that internally
id also look into def ===