Coding: Fleeting Thoughts

[Xeio]

↶
To be fair, I will definitely press Ctrl-C after a while.

But you're a program too!

[The Great Hippo]

I've got a data-driven entity-component system, now; you define components you want entities to have in a file that describes their default values (or the values from which they're defined):

Code: Select all

strength = 10
str_bonus = {(entity.strength - 10) / 2}


And now you can define/add those values for certain entities:

Code: Select all

>>>player = 0
>>>component.set_components(player, "str_bonus", strength=16)
>>>component["str_bonus"][player]
3

(Keywords assign a value to the component, while just providing the component's name sets the entity's component to it's default value)

Next, I'll be adding modifiers; a special dictionary inside of the component dictionary that tracks functions which intercept the final component value for an entity (like it's strength bonus) and either return the same value or a new value.

I'm already pretty certain how modifiers will work (similar to currying); the big challenge, I think, will be making them data-driven like components now are.

EDIT: The cool part about this setup -- in case it's not obvious -- is that I don't need to maintain a list of game objects; game objects are defined by what components associate with them. Aspects (groups of components with associated code) iterate over all the entities that are associated with the components that aspect incorporates.

[ahammel]

note that the month is 0-based

Are you fucking kidding me right now?

[Thesh]

I mean, I was going to say "Someone probably just created an enum, so just use the constants" but then I clicked the link. I don't remember that from JavaScript back in my day (which was nearly a decade ago).

[Flumble]

note that the month is 0-based

Are you fucking kidding me right now?

Well, duh.
It's been like that since C's time(.h). Or possibly even before C, but that's beyond internet history.

But it's really convenient when you want to convert a month number to a name using a 0-based array.

[edit]note that all of the above is sarcasm

[phlip]

Yeah, C's "struct tm" uses a 0-based month number but a 1-based day number. And originally it used a two-digit year, but now out of backwards compatibility it uses "year - 1900". So today is 13/11/116 according to C.

It is garbage, and every language that does the same and justifies it as "well at least it's like C" is also garbage.

[EvanED]

Yeah, C's "struct tm" uses a 0-based month number but a 1-based day number. And originally it used a two-digit year, but now out of backwards compatibility it uses "year - 1900". So today is 13/11/116 according to C.

It is garbage, and every language that does the same and justifies it as "well at least it's like C" is also garbage.

I sometimes really wish I could 'upvote' or 'like' posts on this forum...

[Xanthir]

Javascript's Date, in particular, is a near-exact copy of Java's Date, with all the terrible mistakes that implies. Side-effect of its initial design being done in 10 days and needing a date object from the very beginning.

[cemper93]

Yeah, C's "struct tm" uses a 0-based month number but a 1-based day number. And originally it used a two-digit year, but now out of backwards compatibility it uses "year - 1900". So today is 13/11/116 according to C.

It is garbage, and every language that does the same and justifies it as "well at least it's like C" is also garbage.

Relevant rant read.

Also, general thing @TheGreatHippo: it's an interesting system you're building, but it is NOT an entity-component system, because the entire point of an entity-component system is that components do not contain logic! If you wanted to do your example of

Code: Select all

str_bonus = {(entity.strength - 10) / 2}

in an ECS, you would think about what component that formula is trying to express first, then create a component for that. Now, I don't play D&D, but if it was, say, a particular sword that gave you that strength bonus, then you would do

Code: Select all

component["particularsword"][player] = "instance of the particular sword

, and then add a system with

Code: Select all

def calculate_strength_system():
    for entity in entities:
        if entity in component["particularsword"] and entity in component["str"]:
            component["str_bonus"][entity] = (component["str"] - 10) / 2

So that's how you'd do it.

Or you, know, just do it your way. That works too. Just picking nits.

[ahammel]

Javascript's Date, in particular, is a near-exact copy of Java's Date, with all the terrible mistakes that implies. Side-effect of its initial design being done in 10 days and needing a date object from the very beginning.

Fortunately we have better options for both languages these days. But goddamn, zero-indexed months? Why not just make the days zero-indexed while you're at it?

[Xeio]

Sometimes the one-based indexes we use for most things at work are kinda nice.

I wonder if we would use zero-based conventions if designing from scratch nowadays if there weren't so many legacy languages that had them. There's not any reason the compiler couldn't do the address translation behind the scenes for it.

[cemper93]

Sometimes the one-based indexes we use for most things at work are kinda nice.

I wonder if we would use zero-based conventions if designing from scratch nowadays if there weren't so many legacy languages that had them. There's not any reason the compiler couldn't do the address translation behind the scenes for it.

Why numbering should start at zero.

[Xeio]

That argument seems tailored to the specific case Dijkstra chose.

So he makes the "First N numbers" subsequence case pretty:

Code: Select all

0 <= i < N

But "Starting at N length of M " becomes similarly ugly to his zero-based indices case:

Code: Select all

N-1 <= i < N+M-1

Whereas in a 1-based array the subsequence would just be:

Code: Select all

N <= i < N+M

Could be it's going over my head, but it seems like he just chose a convenient case where zero-based arrays are prettier than 1-based.

[chridd]

But "Starting at N length of M " becomes similarly ugly to his zero-based indices case:

Code: Select all

N-1 <= i < N+M-1

Whereas in a 1-based array the subsequence would just be:

Code: Select all

N <= i < N+M

No, starting at index N length of M is N <= i < N+M in both systems. It's only N-1 <= i < N+M-1 if N is 1-based and your arrays are 0-based, and if you mix 1-based and 0-based indexing then of course you're going to have extra -1's and/or +1's.

[Xenomortis]

Code: Select all

>>> 3 // 2
1
>>> 3.0 // 2
1.0


Python, do you really have to be like that? It's so close, but worse than not close.

Trying to maintain compatibility between Python 2.7 and 3 is a pain the arse when you don't have a proper environment for the latter set up.

[Flumble]

Who's that (//) guy and why do you want to obscure your divide-then-floor?
If types mean that much to the project, the project should be done in a stricter language, methinks.

[Xenomortis]

It's not me that cares about types. It's Python!

Code: Select all

>>> arr = [1, 2, 3]
>>> arr[5.0 // 2]
TypeError


Or how about:

Code: Select all

>>> (5.0 // 2) ^ 1
TypeError


[Thesh]

Easily solvable, just create your own types with their own operators whenever you want to do anything.

[Tub]

It's not me that cares about types. It's Python!

Serves you right for using one of those half-typed languages that think they know better. Wasn't the term "duck typing" coined by the python devs? If they love duck typing so much, why don't they implement it in their language?

Code: Select all

$x = array("a","b","c");
$i = 3/2;
echo "\$x[", $i, "] = ", $x[$i], "\n";'

$x[1.5] = b

There, no fuss, it just works! If it quacks like an int, it's an int. The python devs should take notes.

[Flumble]

It's not me that cares about types. It's Python!

...forget I said anything.

Really? Can't access element 2.0? Nor "2" (which is totally a number because it literally says "2")?

TIL: for some reason javascript does implicitly convert integer strings to array indices, but it treats general number strings as dictionary keys.

[chridd]

TIL: for some reason javascript does implicitly convert integer strings to array indices, but it treats general number strings as dictionary keys.

JavaScript array indices are strings (numbers are converted to strings when used as indices). Objects in general are mappings from strings to values; arrays are objects whose keys happen to include "0", "1", "2", "3", etc., and "length".

In JavaScript, a[1.5] is a valid array index, the same as a["1.5"], and distinct from a[1], though assigning to a[1.5] doesn't affect the length and won't be seen by functions designed for operating on arrays. Likewise, a[-1], a[NaN], a[Infinity], a[null], and a[undefined] are all valid array elements (which, again, don't affect the length and won't be seen by functions designed for operating on arrays), because they can all be converted into strings. a[1.0] is the same as a[1] and a["1"], because 1.0 is the same as 1; a["1.0"] and a["01"] are different elements because they're distinct strings.

[ahammel]

TIL: for some reason javascript does implicitly convert integer strings to array indices, but it treats general number strings as dictionary keys.

What's an "integer"? Nobody here but us doubles.

[Flumble]

TIL: for some reason javascript does implicitly convert integer strings to array indices, but it treats general number strings as dictionary keys.

What's an "integer"? Nobody here but us doubles.

"integer string" being "a string containing digits only". (specifically /0|[1-9][0-9]*/ )

chridd: my quibble is that integer strings are cast to offset indices, rather than staying strings. I can't think of any other instance where strings and numbers (or other types) are allowed and JS prefers casting away from a string.

Or I'm thinking in the wrong way and the Array object is actually a hack on top of a dictionary, rather than a container on its own. I.e. it's always stored in a dictionary but there's a layer on top that includes an iterator over all keys that parse as an integer. (and possibly it is an actual array under the hood as long as it only has integer indices and is densely populated)

[chridd]

Or I'm thinking in the wrong way and the Array object is actually a hack on top of a dictionary, rather than a container on its own.

Exactly.

Code: Select all

var a = ['a','b','c'];
for(var i in a) console.log(i, typeof i);
0 string
1 string
2 string

There's a special case that updates length if you assign to an integer string, and that deletes integer string keys if you assign length, but otherwise it's just a normal object. (Also I think recent versions of JavaScript have special rules for the order of for-in loops when you have integer-like keys, but earlier versions left the order completely unspecified.)

This is all assuming we're talking about normal arrays (Array objects, the kind you get when you use expressions like [1,2,3]); objects that look kind of like arrays but aren't might convert those strings into integers. I know String objects do (but only when getting a key that's not otherwise in the object), and I assume typed arrays do as well.

[EvanED]

Not to mention:

Code: Select all

> typeof []
"object"

which I guess isn't definitive but is suggestive.

[ahammel]

Here's a fun talk for the C++ geeks. It's an implementation of pong in C++17 that runs on the Commodore 64 (with the help of an x86_64 to 6502 machine code converter).

[phlip]

Not to mention:

Code: Select all

> typeof []
"object"

which I guess isn't definitive but is suggestive.

Yeah, but typeof most things in Javascript is "object", that doesn't really narrow it down much...

[PM 2Ring]

Code: Select all

>>> 3 // 2
1
>>> 3.0 // 2
1.0


Python, do you really have to be like that? It's so close, but worse than not close.

Trying to maintain compatibility between Python 2.7 and 3 is a pain the arse when you don't have a proper environment for the latter set up.

Don't think of // as integer division: it's floor division. We got plenty of warning that the behaviour of / was going to change: the docs mentioned it way back in Python 2.2, and encouraged us to use // when we wanted floor division, and I'm pretty sure that from __future__ import division was available from Python 2.2 too.

Permitting // to take float operands lets us do neat stuff like

Code: Select all

>>> a = 1.375; a // 1, a % 1
(1.0, 0.375)
 

[chridd]

Don't think of // as integer division: it's floor division.

Shouldn't floor return an integer, though (like it does in Haskell)? (At least, if you have bigints and don't have to worry about floor(1.0e308) not being representable as an int; but I'm pretty sure Python does have bigints.) I'd expect 3.0 // 2 to be acceptable (i.e., // can take float arguments) and return 1 (an integer).

[PM 2Ring]

Don't think of // as integer division: it's floor division.

Shouldn't floor return an integer, though (like it does in Haskell)? (At least, if you have bigints and don't have to worry about floor(1.0e308) not being representable as an int; but I'm pretty sure Python does have bigints.) I'd expect 3.0 // 2 to be acceptable (i.e., // can take float arguments) and return 1 (an integer).

Perhaps. Python 2's math.floor always returns a float, but the Python 3 version returns an int if you pass it an int. In C, the floor function from <math.h> returns a double.

Python 2 uses int for machine integers and long for bigints, in Python 3 they're unified into int.

[ucim]

Python 2's math.floor always returns a float,

Could somebody explain to me the logic behind this? I thought the whole point of floor() was to return the lowest integer less than or equal to the argument. If floor(almost/just_about) returns 3.999999999999999999916, do we need three boats or four? I suppose we can take floor(3.999999....), getting 3.0000000000000014 (or maybe even 2.99999999999999999999142) and leave people stranded. Maybe lots of people.

Python, I expected better.

But I suppose Manuel might have programmed that section.

Jose

[ahammel]

Python 2's math.floor always returns a float,

Could somebody explain to me the logic behind this?

It's just a thin wrapper around C's floor function.

[ucim]

It's just a thin wrapper around C's floor function.

I guess I'm not seeing it in there. But in any case, can somebody tell me why C would return a float for the integer less than or equal to whatever? It sounds so.... wrong, and I certainly didn't expect C to do this.

Jose

[ahammel]

It's just a thin wrapper around C's floor function.

I guess I'm not seeing it in there. But in any case, can somebody tell me why C would return a float for the integer less than or equal to whatever? It sounds so.... wrong, and I certainly didn't expect C to do this.

The relevant call is on line 992 (return math_1_to_int(number, floor, 0)). As far as I can tell, "math_1_to_int" is just going to apply "floor" to "number" and return the result (line 795). The rest looks like type-checking and boilerplate.

As for why C's floor returns a float, possibly because it's an implementation of the IEEE floating point floor function (AKA round towards −∞). That has to return a float because a) the spec says it returns a float, and b) it has to work on NaN, ∞, and -∞.

[ucim]

The relevant call is on line 992 (return math_1_to_int(number, floor, 0))

Yeah, I saw that, and that is just a wrapper for math_1_to_whatever().

oilerplate.

As for why C's floor returns a float, possibly because it's an implementation of the IEEE floating point floor function (AKA round towards −∞).

...and so, (I feel like a little kid asking "why?" for every answer. ) why would IEEE create a function whose ostensive purpose is to calculate which integer is less than or equal to.... and not actually return an integer?

Jose

[PM 2Ring]

[...] why would IEEE create a function whose ostensive purpose is to calculate which integer is less than or equal to.... and not actually return an integer?

Because a machine integer is not big enough to hold all possible results of floor. Of course, double can't represent very large integers exactly either, but it's good up to about 53 bits, which is rather handy when you want to do large integer calculations on a machine that can't handle ints larger than 32 bits.

The C <math.h> functions all return double, and almost all their args are double, apart from the integer exponent args of ldexp and frexp. And when you do simple arithmetic operations with a mix of integer and floating-point operands the ints have to be converted to floating-point. Conversion between int & floating-point is fairly efficient on modern hardware, but it's not a free operation, and of course it can result in loss of significance, so it's best avoided when it's not strictly necessary.

On ancient machines that had no hardware support for floating-point such conversions had to be performed by library code, so it was even more important to avoid unnecessary conversions than it is on modern machines. But even on machines with FP hardware it's much more efficient to avoid such conversions since they hamper the efficient pipe-lining of chains of FP calculations.

[Yakk]

The closest ieee floating point approximation of an integer is a floating point integer, not one with a bunch of .999...87 or .000..14 etc.

Floats are not random; they are mostly just integers with a power of two extra component.

There is no reason to store 7 as anything except 7 * 2^0 (and yes the encoding isn't exactly like that, but it is functionaly that).

[ahammel]

The relevant call is on line 992 (return math_1_to_int(number, floor, 0))

Yeah, I saw that, and that is just a wrapper for math_1_to_whatever().

oilerplate.

As for why C's floor returns a float, possibly because it's an implementation of the IEEE floating point floor function (AKA round towards −∞).

...and so, (I feel like a little kid asking "why?" for every answer. ) why would IEEE create a function whose ostensive purpose is to calculate which integer is less than or equal to.... and not actually return an integer?

Aside from the excellent reasons already mentioned:

* Because returning an integer would be inconvenient for designers of specialised floating point hardware. For that purpose, you want all the operations specified to be total functions, and to operate on floats.
* Because the purpose isn't really to calculate the nearest integer. These are rounding functions, and rounding to the nearest 0.1 is a perfectly cromulent operation.
* What integer value do you want floor(∞) to return? A programming language designer could decide to throw an exception or something, but for the purposes of the spec we want total functions, as I mentioned.

[phlip]

↶
[...] If floor(almost/just_about) returns 3.999999999999999999916 [...]

Then that would be a bug. floor(x) is always going to be exactly an integer.

For -2¹⁰²⁴ < x < 2¹⁰²⁴ (or thereabouts, I CBA to calculate the exact endpoints), every integer is exactly representable as a float, so you shouldn't get any rounding errors at all. Outside that range, every possible float value is an exact integer, so any rounding errors will take you to ints, not away from them (and in practise it just means that floor(x) == x, since x is always going to be integral).

So if you get a non-exact int from round(), that's not a rounding error, that's a bug.

I can't think of any numbers, even edge cases, where int(floor(x)), where floor returns a double, should give a better (or even a different) result than an intfloor(x) that rounds directly to an int. Ditto for ceil() or round().

I'll grant that having floor(x) return an int would be more useful (being able to use it as a list index, for instance) but that's just a convenience thing, not a precision thing.

[speising]

Maybe even more importantly, any operation on a float has to return another float, since the value may be outside the range representable by ints.

What's intfloor(2147483649.5)?