Making a Game in Rust • Hacker News Board

Re: Making a Game in Rust

#121

Post by infogulch » Wed, May 10, 2017, 7:22 PM UTC

lifthrasiir wrote: post #118

infogulch wrote: post #113

Earlier quoted context omitted.

So check on construction, when doing operations with other unchecked floats, and when dividing. Any other operations that could produce a NaN? Wait, are +-Inf considered unordered? Edit: Nope. inf == inf, so you should only have to worry about NaN. https://is.gd/Xi5jdr

If you want the full list: 0/0, ±inf/±inf, 0 x ±inf, ±inf x 0, inf + (-inf), (-inf) + inf, inf - inf, (-inf) - (-inf). This list is large enough to make NaN checking inefficient.

Thanks. Yeah maybe not.

It seems like the right way is to add min/max fns to the Iterator trait for PartialOrd that ignore items where partial_ord returns None.

Re: Making a Game in Rust

#122

Post by dang » Wed, May 10, 2017, 8:24 PM UTC

jamescostian wrote: post #31

phkahler wrote: post #18

Earlier quoted context omitted.

Now I have to rewrite my arcade game emulator in rust just so I can use that to load rom images...

Not only did you completely miss the point (a systems language has a very nice thing very well built-in - yay!), but you also built a strawman (as if praising a language means is the same as telling everyone to rewrite all code in that language) and then beat it up using a poor example (why package those images into the binary?). Congratulations! You just won the internet!

Please don't comment uncivilly, regardless of what you think of someone else's comment.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

Re: Making a Game in Rust

#123

Post by BatFastard » Wed, May 10, 2017, 11:36 PM UTC

Qwertious wrote: post #106

BatFastard wrote: post #41

Earlier quoted context omitted.

As long as it is not flash! Some serious flash hating here.

Eh, AFAIK Flash's big problem is the implementation - it's horribly inefficient and insecure etc, but in theory someone could make their own clone of Flash and make a much better version that works well for all that stuff.

Just have to say Flash and its an automatic down vote. As some background, I used to program 3D engines in C++ for 20 years. So I know a little about the subject, and I hated flash back then too, but just out of ignorance.

first point - insecure

Would you rather have a safe that thousands of thieves try to break on a daily basis, or would you prefer that only casual thieves try to break it every once in a while?

I would trust my money to the safe that has been thoroughly tested. Checking for safety is pretty much all the flash team does these days.

inefficient

Its actually as or more efficient than JavaScript. Where there lots of crap flash ads and programs? Sure, but that is because Adobe made it easy to create flash apps.

I am writing a 3D engine in Flash that displays and updates millions of polygons at 60 frames per second. I can't do that in JavaScript yet.

Re: Making a Game in Rust

#124

Post by yorwba » Thu, May 11, 2017, 12:10 AM UTC

infogulch wrote: post #121

lifthrasiir wrote: post #118

Earlier quoted context omitted.

If you want the full list: 0/0, ±inf/±inf, 0 x ±inf, ±inf x 0, inf + (-inf), (-inf) + inf, inf - inf, (-inf) - (-inf). This list is large enough to make NaN checking inefficient.

Thanks. Yeah maybe not. It seems like the right way is to add min/max fns to the Iterator trait for PartialOrd that ignore items where partial_ord returns None.

Not all partial orders have well-defined min/max, though. Ideally, you would want traits for meet/join semi-lattices, but I'm not sure how much abstract algebra you can inflict on the average Rustacean. Then there is the whole problem of NaN is incomparable with everything, so you'd have to use a non-standard definition of semi-lattice to allow for that.

And do you want max(NaN, 0) to be NaN or 0? There is a case to be made for either possibility.

Re: Making a Game in Rust

#125

Post by infogulch » Thu, May 11, 2017, 2:50 PM UTC

yorwba wrote: post #124

infogulch wrote: post #121

Earlier quoted context omitted.

Thanks. Yeah maybe not. It seems like the right way is to add min/max fns to the Iterator trait for PartialOrd that ignore items where partial_ord returns None.

Not all partial orders have well-defined min/max, though. Ideally, you would want traits for meet/join semi-lattices, but I'm not sure how much abstract algebra you can inflict on the average Rustacean. Then there is the whole problem of NaN is incomparable with everything, so you'd have to use a non-standard definition of semi-lattice to allow for that. And do you want max(NaN, 0) to be NaN or 0? There is a case to…

If I'm writing a game I don't really care if one of many operations accidentally resulted in NaN I would like to treat NaN like SQL treats NULL: pretend it doesn't exist. I can't glean useful information out of it, might as well try to get something from the rest of the data.

Then again according to float semantics, sum of a list containing NaN must be NaN, so it would make sense to extend that principle to min/max.

But the naive implementation of min/max will never output NaN because NaN always compares false. (... unless NaN is the first element. ugly.)

Maybe making it explicit would be best: Make an explicit fn for float collections that filters out NaN in an Iterator, then claim that Item is totally ordered. I'm too much of a rust noob to know if this is possible. (playground here I come!)