ChanServ changed the topic of #zig to: zig programming language | | be excellent to each other | channel logs:
davr0s has left #zig ["Textual IRC Client:"]
porky11 has quit [Quit: Leaving]
steveno has joined #zig
<daurnimator> andrewrk: catching up on your stream now. will note things as I watch.
<daurnimator> - 17 digits of decimal fraction is enough for floating point.
<daurnimator> (though 14 is often used in languages for "beauty")
<tbodt> andrewrk: you should put your stream in the "science and technology" category where all the other programming streams are now
<daurnimator> - log_a(x) == log_b(x)/log_b(a)
steveno has quit [Ping timeout: 268 seconds]
<andrewrk> daurnimator, yeah I foolishly though I could wing it on that stream. ended up giving up at the end. I need to learn me some CS fundamentals before trying again
<andrewrk> tbodt, ok
<daurnimator> andrewrk: if you do attempt number parsing again I can probably suggest that you pretty much port the code in that link
<MajorLag> So does it seem off to anyone else that `std.math.maxFloat(f32) != std.math.f32_max`? Perhaps these constants should be renamed to something like `std.math.f32_finite_max`.
<andrewrk> MajorLag, I reverted the maxFloat PR
<andrewrk> I believe wink_ opened it for discussion again
<MajorLag> Yeah, now with `maxFloat(f32) == f32_inf`. That makes sense enough, but causes confusion I think because the finite constants are also called simply "max"
<MajorLag> I could have brought this up in the new PR, but it isn't an objection to that implementation, just sort of an observation about a related part of the std lib.
<andrewrk> I think those are ported from libc
<MajorLag> probably, but does that mean we shouldn't rename them to more accurately represent what they are?
<andrewrk> yes but I would argue a prerequisite to that is a full understanding of their purpose
<MajorLag> ok, fair enough
<andrewrk> which I admit I do not possess
<andrewrk> interesting, true_min has exponent 0, mantissa 1, whereas min has exponent 1, mantissa 0
<MajorLag> true_min vs min appears to involve "subnormal" float representations, which I also admit to not really understanding
<daurnimator> andrewrk: yeah subnormal
<daurnimator> andrewrk: so something you may have missed understanding (didn't see it on the stream) is that the mantissa has an implicit leading 1 bit.
<andrewrk> oh yeah I forgot about that
<daurnimator> IIRC a subnormal is where there is *no* implicit leading 1 bit.
<daurnimator> which is signified by an exponent of 0.
<daurnimator> so your "true_min" is the smallest subnormal number: the exponent is 0, and just the last bit of the mantissa is set.
<daurnimator> vs the smallest normal number, which is where the exponent is 1 (i.e. -126) and the mantissa is 0. which is 1.0 * 2 ^ (-126)
<MajorLag> ok, so they appear to exist to prevent underflow from addition and subtraction of normal float values, by linearly filling the gap between negative and positive normal floats.
<daurnimator> though calling it "true_min" is weird: it's the smallest positive (non-zero) number.
<MajorLag> a mor accurate name might be "subnormal_min". Apparently not all hardware supports subnormals.
<MajorLag> so the distinction is potentially relevant for performance reasons.
<daurnimator> MajorLag: to me "min" has no limitation on being positive.
<daurnimator> the more correct name may be "epsilon".
<MajorLag> was it positive? I guess I didn't look very closely.
<MajorLag> huh, yep, so still not an accurate name really.
<daurnimator> that's what it is usually named. can't find much on google suprisingly. however here is at least one reference:
<MajorLag> but epsilon is defined differently still.
<andrewrk> suffice to say... it's not super clear what maxFloat would do, and it's especially not clear what maxValue would do if it supported both int and float.
<andrewrk> I'm leaning towards, this doesn't belong in std
<daurnimator> andrewrk: I'm fine with maxFloat returning infinity
<daurnimator> it's a useful condition for e.g. finding the minimum
<andrewrk> then use std.math.inf
<MajorLag> I mean, if there's one thing that makes sense, it is that the maximum possible float value is infinity.
<MajorLag> but there seems to be a lot of wiggle room for what kind of max people might actually want
<daurnimator> fn findMin(somecollection) T { var smallest = maxValue(T); for (somecollection) |x| if (x < smallest) { smallest = x } } return smallest; }
<daurnimator> ^ I can imagine wanting to write something like that
<daurnimator> which would work on both ints and floats and whatever else
<andrewrk> that's something to think about
<benjikun> true that could be nice
<benjikun> that's what nim's parseFloat proc does ^
<benjikun> This guy has a lot of blog posts on parsing floats this way. Here's another:
<benjikun> Seems beneficial
<daurnimator> glibc's strtod has lots of issues, don't use it for a template...
<benjikun> The core method is reused in java and nim
<benjikun> The post only details how the algorithm itself works
<benjikun> I did look over it
<daurnimator> also, for going back the other direction, see
<andrewrk> daurnimator, for the other direction, see
<daurnimator> andrewrk: ah cool. I haven't heard of Ryu before. from their paper: > On average, Ryu is roughly three times faster than Grisu3 for 32-bit and 64-bit floating point numbers.
<andrewrk> tiehuis does excellent work
<benjikun> The qi double parsing in boost seems pretty fast compared to others
<benjikun> >One note of interest is that QI fails to parse some very long fixed-notation inputs; X3 parses these correctly, but runs significantly slower than with short scientific-notation inputs.
<benjikun> neat workaround that ryu uses
<benjikun> This seems pretty versatile actually
benjikun has quit [Quit: Lost terminal]
qazo has joined #zig
Triplefox[m] has joined #zig
<Triplefox[m]> Re: subnormal floats. Not having them is a pretty important topic for real-time DSP code, it often causes audio plugins to suddenly freeze due to processing overhead when the signal gets quiet. With some CPU instruction sets they are avoidable now but folks have come up with "anti-denormal" tricks in the past:
forgot-password has joined #zig
<forgot-password> Good morning :)
Hejsil has joined #zig
<Hejsil> Started working on a scanf like function in Zig
suirad has quit [Ping timeout: 256 seconds]
suirad_ has joined #zig
forgot-password has quit [Ping timeout: 244 seconds]
forgot-password has joined #zig
forgot-password has quit [Ping timeout: 245 seconds]
forgot-password has joined #zig
sjums has joined #zig
steveno has joined #zig
porky11 has joined #zig
steveno has quit [Ping timeout: 268 seconds]
<forgot-password> andrewrk: Hi, I was wondering which OS you built your zig-vulkan-triangle project on.
<sjums> andrew threw me in the direction of ArrayLists yesterday for dynamically sized arrays
<sjums> So now I'll have to read up on writing a memory allocator
<sjums> which is not yet in the docs
<sjums> never written such a thing before :3
<sjums> advent of code gonna be hell of a challenge this year :D
<MajorLag> Why? There are already allocators you can use in std. Not that I'm discouraging writing your own allocator, which is a good exercise.
<Hejsil> Use gc an be done with it
<Hejsil> :)
<sjums> There's a std.debug.something_allocator, right?
<Hejsil> std.debug.global_allocator (use only for prototyping(tm))
<MajorLag> more practical allocators: FixedBufferAllocator or DirectAllocator.
<MajorLag> which are in std.heap
<sjums> noted and noted.
<Hejsil> I tend to reach for Direct- and ArenaAllocator mostly
<Hejsil> and FixedBufferAllocator, for tests
<MajorLag> FixedBufferAllocator wraps a slice of u8 and is pretty naive. Mostly useful for tests or small temporary allocations. DirectAllocator calls the OS allocator.
<sjums> You are talking to someone who have never managed his own memory before. Throwing more types of allocators at me are currently like talking to a door
<sjums> :b
<MajorLag> Ok, you want DirectAllocator then, it's basically malloc
<MajorLag> which is the C std lib allocator
<MajorLag> (though the actual C std lib allocator is a completely difference allocator in zig's std lib)
<Hejsil> And malloc does a lot of magic that DirectAllocator doesn't
<MajorLag> The Windows implementation is actually fairly close. The POSIX one allocates an entire page for small allocations though.
<Hejsil> He wanted a simple answer. We didn't deliver :)
<MajorLag> Well, if you've never had to allocate your own memory before, then I can't think of a simpler option than just using DirectAllocator. You can learn the trade-offs and use cases of other allocators later.
<Hejsil> Indeed
<MajorLag> One or more of us should maybe write an intro to manual memory management we can link people to.
<sjums> I did get a satisfactory answer :)
<sjums> I'm not expecting everything new to be simple and easy
<sjums> I'm gonna read some tests (they are good examples) on using the allocators, and up my daily coffee intake by a factor of two!
allan0 has quit [Ping timeout: 240 seconds]
allan0 has joined #zig
return0e_ has joined #zig
return0e has quit [Ping timeout: 250 seconds]
qazo has quit [Ping timeout: 250 seconds]
steveno has joined #zig
forgot-password has quit [Quit: leaving]
Hejsil has quit [Quit: Page closed]
porky11 has quit [Ping timeout: 260 seconds]
sjums has quit [Quit: Page closed]
sjums has joined #zig
<andrewrk> MajorLag, that's a great idea
<andrewrk> here's a private leaderboard for zig users for advent of code 2018: 384812-f73c8aea
<andrewrk> rules: * Use Zig! * NO LIBC
sjums has quit [Ping timeout: 256 seconds]
<presiden> andrewrk: nice
Zaab1t has joined #zig
qazo has joined #zig
steveno has quit [Ping timeout: 252 seconds]
IntoxicatedHippo has quit [Ping timeout: 272 seconds]
steveno has joined #zig
steveno has quit [Ping timeout: 260 seconds]
Zaab1t has quit [Quit: bye bye friends]
<MajorLag> is something up with CI or did my push just not run it for some reason?
<andrewrk> I don't see a build queued
<MajorLag> something to do with the rebase=>force push?
<MajorLag> or perhaps I simply wasn't patient enough
<andrewrk> I'm not sure. I think that's supposed to trigger a build
robbym has joined #zig
<robbym> Hello, I just found this language and was wondering it has been tested on any embedded platforms?
<robbym> Nice! Thanks for the links.
<andrewrk> robbym, also I just recorded this, 10 minutes ago:
<suirad_> andrewrk: I was just about to post that here, nice work, congrats
<suirad_> you should post it on the sub and crosspost it to related subs
<suirad_> also, any chance of a swag shop for my irl shilling for zig?
<andrewrk> suirad_, some day
benjikun has joined #zig
benjikun has quit [Quit: Lost terminal]
bbrittain has quit [Ping timeout: 245 seconds]
bbrittain has joined #zig
<bbrittain> andrewrk: yes, travisg knows me :)
<andrewrk> bbrittain, oh, lol, you're in #osdev
<andrewrk> I'm going to try to blow the #osdev people's minds when I hook up zig's debug info parsing / panic handler up to bare metal
<andrewrk> so that you get stack traces in kernel panics
<bbrittain> they'll like that
steveno has joined #zig
suirad_ has quit [Ping timeout: 256 seconds]
suirad has joined #zig
steveno has quit [Quit: Leaving]
robbym has quit [Quit: Leaving]