ChanServ changed the topic of #zig to: zig programming language | ziglang.org | be excellent to each other | channel logs: https://irclog.whitequark.org/zig/
<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.
<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.
<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
<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.
<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: http://ldesoras.free.fr/doc/articles/denormal-en.pdf
<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