ChanServ changed the topic of #crystal-lang to: The Crystal programming language | https://crystal-lang.org | Fund Crystal's development: https://crystal-lang.org/sponsors | GH: https://github.com/crystal-lang/crystal | Docs: https://crystal-lang.org/docs | Gitter: https://gitter.im/crystal-lang/crystal
<FromGitter> <Blacksmoke16> no idea when/why you would need that but kinda neat i guess ha
frojnd has quit [Quit: WeeChat 2.3]
hendursaga has quit [Ping timeout: 240 seconds]
hendursaga has joined #crystal-lang
alexherbo2 has joined #crystal-lang
<repo> Blacksmoke16, sure, i can do that, but then how would i annotate the existing methods?
sorcus has joined #crystal-lang
<FromGitter> <Blacksmoke16> would have to reopen them and add the annotation i guess, prob using `previous_def`? Or ofc annotate the methods on the type that wraps the actual obj
<FromGitter> <Blacksmoke16> the latter might be the better option as its independent of the actual binding
<repo> mmh
alexherbo27 has joined #crystal-lang
alexherbo2 has quit [Read error: Connection reset by peer]
alexherbo27 is now known as alexherbo2
alexherbo29 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 246 seconds]
alexherbo29 is now known as alexherbo2
<FromGitter> <Groogy> Yo, implementing my own fixed point struct, because why not. I'm considering making a shorthand macro for making a fixed point, though wondering if it might pollute the global namespace? Something like `fp32(12345)`
<FromGitter> <oprypin:matrix.org> @Groogy: 1. why macro; 2. you can put it into a short namespace
<FromGitter> <Groogy> Don't think there's any hooks in macros like method_added that would let me scan a literal to see it has "fp32" in it
<FromGitter> <Groogy> Oh wrote wrong, meant method
<FromGitter> <Groogy> And yeah I guess a module would be fine, have a FixedPoint::fp32, would let you do "include" if you want it globally
<FromGitter> <Groogy> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=609d402a9f2c352db1092bdd]
<FromGitter> <Blacksmoke16> does this do more than like 5 * 11?
<FromGitter> <RespiteSage> @Groogy Btw, if this turns from a "why not" kind of project into something you want to use in production (and need to be fast), LLVM has built-in methods (https://llvm.org/docs/LangRef.html#fixed-point-arithmetic-intrinsics) that you can bind to for fixed-point ops.
<FromGitter> <RespiteSage> It's remarkably easy to write those kinds of bindings. I'm in the middle of speeding up my saturating arithmetic shard, and here (https://github.com/RespiteSage/saline/blob/optimization/llvm-backend/src/llvm/lib_saturating.cr)'s my binding file for those LLVM ops.
<FromGitter> <tenebrousedge> neat
<FromGitter> <Groogy> > does this do more than like 5 * 11? ⏎ ⏎ No, it just avoids floating point errors
<FromGitter> <RespiteSage> `fp(11) * fp(5)` is going to return a value of your `FixedPoint::fp32` class, right? And that just has equality methods with other numbers?
alexherbo2 has quit [Ping timeout: 265 seconds]
<FromGitter> <Groogy> yepp
<FromGitter> <Groogy> So I did a `fp32` & a `fp64` shortcut methods and then a `fp` that deducts the size from the incoming value
<FromGitter> <RespiteSage> `fp` is a macro that uses the input type or it's a method that uses `#bit_width`?
<FromGitter> <Groogy> Also thanks @RespiteSage didn't know. Might have a look later. For now I am just gonna do a naive/simple implementation that is similar to our old one at work. (just divide the underlying value by a scale)
<FromGitter> <Groogy> Nah even easier. It's just some functions that have different argument types so the compiler resolves which one to use
<FromGitter> <Groogy> ```code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=609d5896d3b89834a73b344a]
<FromGitter> <RespiteSage> Oh, nice. Yeah, the type system is fantastic.
<FromGitter> <Groogy> Yepp, like I said, gonna generally be a naive implementation for now. But want something functional quick. Will put it up as a shard
<FromGitter> <Groogy> So hopefully LLVM will be smart enough to solve/inline some stuff for me :D
<FromGitter> <Groogy> Because basically a simple 25 + 25 in 32bit is solved as: 25*1000 + 25*1000, which it hopefully should be able to spot and not unnecessarily do method calls. But I haven't tested anything when it comes to compiler optimizations in Crystal, just used to clang++.
alexherbo2 has joined #crystal-lang
duane has quit [Ping timeout: 252 seconds]
alexherbo2 has quit [Ping timeout: 268 seconds]
alexherbo2 has joined #crystal-lang
deavmi has quit [Ping timeout: 260 seconds]
deavmi has joined #crystal-lang
<FromGitter> <Groogy> Huh this is interesting ⏎ https://play.crystal-lang.org/#/r/b4yv
<FromGitter> <Blacksmoke16> not really, https://github.com/crystal-lang/crystal/issues/8373
<FromGitter> <Blacksmoke16> Int128 isn't really supported atm
<FromGitter> <Groogy> Getting undefined references when using Int128. (Trying to avoid overflow when doing multiplication with the Fixed point)
<FromGitter> <Groogy> Ah okay
<FromGitter> <Groogy> Will have to figure out a way to work around that then
<FromGitter> <Groogy> Since when doing the ** operator it will very easily overflow for instance FixedPoint32 with even very low numbers. Getting it with like `2.5 ** 2`. Want to avoid having to convert it to floating points and do the math.
<FromGitter> <Groogy> Not counting `**` everything else seems to work. So uploaded it for now, gonna clean up a bit later and make it a proper shard :) ⏎ https://github.com/Groogy/fixedpoint
<FromGitter> <RespiteSage> ```code paste, see link``` ⏎ ⏎ Your problem is that `2` in your `FixedPoint32` has an `underlying` of `2000`, so you're doing `2500 ** 2000`, which is obviously going to overflow (and is wrong in any case). [https://gitter.im/crystal-lang/crystal?at=609d7aa85fff1f4a98d51dda]
<FromGitter> <Groogy> I know, and I can't scale them down either so I was hoping to just transfer their values into a Int128 instead and do the multiplication and then scale down.
<FromGitter> <Groogy> Maybe BigInt could work until Int128 gets support?
duane has joined #crystal-lang
<FromGitter> <Blacksmoke16> `UInt64` big enough? assuming the values wont go negative foc
<FromGitter> <Blacksmoke16> ofc*
<FromGitter> <Blacksmoke16> theres also `BigFloat` if that would help
<FromGitter> <RespiteSage> Okay, but unless the scale changes as well, the result is going to be wrong.
<FromGitter> <RespiteSage> @Groogy https://carc.in/#/r/b50l
<FromGitter> <RespiteSage> tl;dr: `x ** y == (x.underlying / SCALE) ** (y.underlying / SCALE)`, so let `exp = (y.underlying / SCALE)`, `x_0 = x.underlying`. Then `x ** y == x_0 ** exp / SCALE ** exp == x_0 ** exp / (SCALE * SCALE ** (exp - 1) == (x_0 ** exp * SCALE ** (1 - exp)) / SCALE`. We want our final underlying value to be the numerator of that last form.
<FromGitter> <RespiteSage> You could also switch out one exponentiation for a multiplication and a division for `(SCALE * (x_0 / SCALE) ** exp) / SCALE`
<FromGitter> <RespiteSage> (You can't cancel the `SCALE` there because, as stated above, the actual output value we want is the numerator, i.e. the represented value divided by the scaling factor.)
alexherbo29 has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 252 seconds]
alexherbo29 is now known as alexherbo2
<FromGitter> <RespiteSage> Oh, and I checked out those LLVM fixed-point operators. It turns out that they only allow powers of 2 for the scale factor.
alexherbo2 has quit [Ping timeout: 240 seconds]