But you're a program too!Xenomortis wrote:↶
To be fair, I will definitely press Ctrl-C after a while.

Moderators: phlip, Moderators General, Prelates
But you're a program too!Xenomortis wrote:↶
To be fair, I will definitely press Ctrl-C after a while.
Code: Select all
strength = 10
str_bonus = {(entity.strength - 10) / 2}
Code: Select all
>>>player = 0
>>>component.set_components(player, "str_bonus", strength=16)
>>>component["str_bonus"][player]
3
Are you fucking kidding me right now?MDN wrote:note that the month is 0-based
ahammel wrote:Are you fucking kidding me right now?MDN wrote:note that the month is 0-based
Code: Select all
enum ಠ_ಠ {°□°╰=1, °Д°╰, ಠ益ಠ╰};
void ┻━┻︵╰(ಠ_ಠ ⚠) {exit((int)⚠);}
I sometimes really wish I could 'upvote' or 'like' posts on this forum...phlip wrote: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.
phlip wrote: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.
Code: Select all
str_bonus = {(entity.strength - 10) / 2}
Code: Select all
component["particularsword"][player] = "instance of the particular sword
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
Xanthir wrote: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.
Xeio wrote: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.
Code: Select all
0 <= i < N
Code: Select all
N-1 <= i < N+M-1
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.Xeio wrote:But "Starting at N length of M " becomes similarly ugly to his zero-based indices case:Whereas in a 1-based array the subsequence would just be:Code: Select all
N-1 <= i < N+M-1
Code: Select all
N <= i < N+M
mittfh wrote:I wish this post was very quotable...
flicky1991 wrote:In both cases the quote is "I'm being quoted too much!"
Code: Select all
>>> 3 // 2
1
>>> 3.0 // 2
1.0
Code: Select all
>>> arr = [1, 2, 3]
>>> arr[5.0 // 2]
TypeError
Code: Select all
>>> (5.0 // 2) ^ 1
TypeError
Xenomortis wrote:It's not me that cares about types. It's Python!
Code: Select all
$x = array("a","b","c");
$i = 3/2;
echo "\$x[", $i, "] = ", $x[$i], "\n";'
$x[1.5] = b
Xenomortis wrote:It's not me that cares about types. It's Python!
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".Flumble wrote:TIL: for some reason javascript does implicitly convert integer strings to array indices, but it treats general number strings as dictionary keys.
mittfh wrote:I wish this post was very quotable...
flicky1991 wrote:In both cases the quote is "I'm being quoted too much!"
What's an "integer"? Nobody here but us doubles.Flumble wrote:TIL: for some reason javascript does implicitly convert integer strings to array indices, but it treats general number strings as dictionary keys.
ahammel wrote:What's an "integer"? Nobody here but us doubles.Flumble wrote:TIL: for some reason javascript does implicitly convert integer strings to array indices, but it treats general number strings as dictionary keys.
Exactly.Flumble wrote: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.
Code: Select all
var a = ['a','b','c'];
for(var i in a) console.log(i, typeof i);
0 string
1 string
2 string
mittfh wrote:I wish this post was very quotable...
flicky1991 wrote:In both cases the quote is "I'm being quoted too much!"
EvanED wrote:Not to mention:Code: Select all
> typeof []
"object"
which I guess isn't definitive but is suggestive.
Code: Select all
enum ಠ_ಠ {°□°╰=1, °Д°╰, ಠ益ಠ╰};
void ┻━┻︵╰(ಠ_ಠ ⚠) {exit((int)⚠);}
Xenomortis wrote: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.
Code: Select all
>>> a = 1.375; a // 1, a % 1
(1.0, 0.375)
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 wrote:Don't think of // as integer division: it's floor division.
mittfh wrote:I wish this post was very quotable...
flicky1991 wrote:In both cases the quote is "I'm being quoted too much!"
chridd wrote: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 wrote:Don't think of // as integer division: it's floor division.
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.PM 2Ring wrote:Python 2's math.floor always returns a float,
It's just a thin wrapper around C's floor function.ucim wrote:Could somebody explain to me the logic behind this?PM 2Ring wrote:Python 2's math.floor always returns a float,
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.ahammel wrote:It's just a thin wrapper around C's floor function.
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.ucim wrote: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.ahammel wrote:It's just a thin wrapper around C's floor function.
Yeah, I saw that, and that is just a wrapper for math_1_to_whatever().ahammel wrote:The relevant call is on line 992 (return math_1_to_int(number, floor, 0))
...and so, (I feel like a little kid asking "why?" for every answer.ahammel wrote: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 −∞).
ucim wrote:[...] 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:ucim wrote:Yeah, I saw that, and that is just a wrapper for math_1_to_whatever().ahammel wrote:The relevant call is on line 992 (return math_1_to_int(number, floor, 0))...and so, (I feel like a little kid asking "why?" for every answer.ahammel wrote: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 −∞).) 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?
ucim wrote:↶
[...] If floor(almost/just_about) returns 3.999999999999999999916 [...]
Code: Select all
enum ಠ_ಠ {°□°╰=1, °Д°╰, ಠ益ಠ╰};
void ┻━┻︵╰(ಠ_ಠ ⚠) {exit((int)⚠);}
Users browsing this forum: No registered users and 5 guests