in reply to Re: I prefer my indexes to start at:
in thread I prefer my indexes to start at:

Sub-poll!


🦛

Replies are listed 'Best First'.
Re^3: I prefer my indexes to start at:
by syphilis (Archbishop) on Sep 06, 2022 at 10:06 UTC
    Apparently, the totalOrder predicate from IEEE 754-2008 specifies that -NaN < -Inf < negative finite numbers < -0 < +0 < positive finite numbers < +Inf < +NaN.
    So if floating point values are allowed, then I think that "-Nan" would be the obvious starting point ... coz you can't not get no lower than that ;-)

    (Hopefully, indexes have to be real integer values.)

    Cheers,
    Rob
      "Hopefully, indexes have to be real integer values."

      I don't see that they have to be "integer" values, but it gets tricky for current hardware if they aren't limited precision rational numbers. In fact even "integer values" is a deal breaker if they aren't limited precision.

      Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
        "Integer value" is a rather abstract concept. It has nothing to do with precision or how we represent it (even on paper).
        Bill
Re^3: I prefer my indexes to start at:
by pryrt (Abbot) on Sep 06, 2022 at 13:33 UTC
    • π or e or sqrt(2)

    Close: my answer would have been the first index is Φ ≈ 1.618, second is e ≈ 2.718, third is π ≈ 3.14, and so on, picking irrational (and preferably transcendental) numbers whose integer portion is the next counting number. (I had forgotten that Φ, like √2, is irrational but algebraic, and had started to write that as "picking transcendental numbers" before having a long think about it; still, I prefer Φ since it has a predefined symbol.)

    Ooh, another fun set: ln(2) ≈ 0.693, √2 ≈ 1.414, 2**(√2) ≈ 2.665, ... I'm sure someone could come up with a whole series of those whose integer portions are increasing, but all the terms only combine operators and 2. ;-)