floats and range
const std = @import("std");
const it = @import("ziter.zig");
fn add(a: f32, b: f32) f32 { return a + b; }
test "f32, 0, 1, 0.1" {
const result = it.range_ex(f32, 0, 1, 0.1)
.call(it.fold, .{@as(f32, 0), add});
std.debug.print("result = {}\n", .{result});
}
test "f32, 0, 1, 0.3" {
const result = it.range_ex(f32, 0, 1, 0.3)
.call(it.fold, .{@as(f32, 0), add});
std.debug.print("result = {}\n", .{result});
}
test "f32, 0, 1, 0.1"... result = 4.5e+00 //correct
test "f32, 0, 1, 0.3"... result = 1.80000007e+00 //incorrect
Ops, looked at this but forgot to respond. Isn't this just quirk of floating point numbers. Not really much this lib can do about that.
Is it possible to: not provide len_hint if a given type is some float?
And the related proposal: make range inclusive, like C++ std::iota.
Is it possible to: not provide
len_hintif a given type is some float?
Not sure what you mean. Do you mean that range should not provide len_hint for floats?
And the related proposal: make
rangeinclusive, likeC++ std::iota.
I made it exclusive as it follows how slicing works in zig, so zig programmers are familiar with it.
Do you mean that range should not provide len_hint for floats?
Yes.
I made it exclusive as it follows how slicing works in zig
Ok. What about new pub fn range_i? (or similar name)
I see. Yea, both of these sounds good to be :+1:
Or to add new parameter to range_ex: comptime inclusive: bool?
Hmmmmm. How about:
pub fn range(comptime T: type, start: T, end: T, opts: struct { inclusive: bool = false, step: T = 1 }) Range(T) {
return .{ .start = start, .end = end + (opt.step * @boolToInt(opt.inclusive)), .step = opt.step };
}
...
range(u8, 0, 6, .{});
range(u8, 0, 6, .{ .step = 2 });
Basically, having and options argument with all fields having default values.
How about:
Looks good! :+1:
range(u8, 0, 6, .{ .step = 2 });
What will happen for range(u8, 0, 255, .{ .step = 2 });?
What will happen for
range(u8, 0, 255, .{ .step = 2 });?
Well, that would overflow with the current behavior. We could have an implementation that handles this, which might be nice, but it probably has a cost.
As of 0c2a668c31b20ffefcaa8e59f70f85b8df94eccb, ziter.range no longer supports floats and step has been removed in favor of:
ziter.range(u8, 0, 10)
.step_by(2)