how to use Natural type?

I see that style guide, though I’m not sure what to use instead. How would you rewrite e.g. the signature of the `setLen` function `proc setLen[T](s: var seq[T]; newlen: Natural)`?

how to use Natural type?

@Hlaaftana yeah it makes sense that this was something that was just “good enough” at some point and could use better design. > In my scripting language I've been trying to do something like this, where > refinement types are "properties" over concrete types … Very cool to see how you’re approa

how to use Natural type?

As per my examples, Nim doesn’t even check them all at runtime! And the halting problem is a cop-out in this case. You can’t automatically detect all unsafe code, but you _can_ enforce “trivial semantic properties” (a la Rice’s theorem) like type-safety and provide conspicuous escape hatches so

how to use Natural type?

@xigoi > Yeah, and `1e-1000` shouldn't be `0.0`. Unfortunately, computers have > finitely many bits. Point taken. I'm not saying `Natural` should be arbitrary precision; just that `low` is a logical restriction from the `Natural` concept, `high` is a physical restriction of the representation.

how to use Natural type?

I wouldn't call it stupid, but there are some definite rough edges: * `Natural.high` and `Positive.high` shouldn't really exist. * `Natural.succ` should always succeed by definition (`Natural.high.succ` throws an error) * `n in Natural` doesn't work - afaict, to turn a `range` into a `Slice

Math library for renderers and GUIs

That makes sense, and I don’t think you really want a rotor class at all - just a “rotation” class that has methods to e.g. rotate a vector or return the axis of rotation or return the angle of rotation. It’s very much a design decision what to put at the _type_ level and what to put at the _va

Math library for renderers and GUIs

> The definition of a Rotor is identical to a geometric product > (scalar+bivector) so returning one as something like geometric(v1, v2) is not > inherently wrong but it does seem like it could be misleading because it > would mean the Rotor becomes the general object used to store any geometric

Math library for renderers and GUIs

The Hadamard product is not geometrically meaningful! While it's great for data processing, it doesn't really make sense to compute the Hadamard product of two _spatial vectors_ (i.e. two relative positions in space) The geometric product makes sense as a product, and so do the inner product and

Math library for renderers and GUIs

There's another issue of mathematical correctness. The `*` and `/` operators operate elementwise, which does not seem a geometrically meaningful operation. These _do_ have meaningful definitions in geometric algebra, but... There's a fundamental tension between linear algebra and geometric algeb

Math library for renderers and GUIs

I love this and I'm interested in contributing! I have a branch here: I'm not familiar with this site so I don't know how to submit a pull request, but here's my first commit: BTW, I'm not sure I'm comfortable

Heterogeneous strongly typed records

I've made some great progress on my records library! In particular, I've added [Table/Map-like operations](https://github.com/rotu/nim-records/blob/2723af78862b3cfa12131b4225b33a7cdcca45f0/src/records/lenientTuple.nim#L27-L65) and an implementation of [Relational Algebra](https://github.com/rot

Heterogeneous strongly typed records

Thank you for your words of encouragement! I keep thinking when writing this code “surely someone must have written this already.” So much of the “vertical” operations of relational programming has made it into the mainstream (filter, reduce, fold), probably because they have nice recursive def