Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Antsan

Pages: 1 ... 16 17 [18] 19 20 ... 71
256
General Discussion / Re: if self.isCoder(): post() #Programming Thread
« on: December 08, 2015, 06:41:42 pm »
Most of the time I learn via Internet, but to learn unusual concepts I find that most of the time books are better for that purpose.
To get behind Shen's type system I read "The Book of Shen" (of course) and to achieve a deeper understanding of macros in Common Lisp "Let Over Lambda" was quite useful.

So, stick with small-scale stuff for now but if you encounter something that interests you and you want to get a little bit deeper into that specific topic, try to find a book on it.

257
General Discussion / Re: if self.isCoder(): post() #Programming Thread
« on: December 03, 2015, 08:39:55 am »
Quote from: Putnam on December 02, 2015, 04:59:17 pm
Quote from: breadman on December 02, 2015, 04:37:44 pm
As a constant, 0.1 should be translated into Rational(1, 10).  (Printed, it should be 0.1, though its repr could be 1/10.)  Two of those added together would be Rational(2, 10), which could be reduced to Rational(1, 5).
That, uh, looks almost exactly like floating point to me, with an arbitrary exponent size rather than just using two. Is that faster, somehow?
It's very much not the same as floating point. It is not faster, but you can represent any rational number exactly, which is impossible with floating point numbers. The idea is to use rationals for any exact, rational and use floating point for irrational and imprecise numbers.

Quote from: Skyrunner on December 02, 2015, 09:34:33 pm
IMO breadman created rational numbers :v

Kinda like arbitrary precision. The main problem with this is that it'd be slower, because floating point numbers are supported by CPU operator codes while the Rational object would have to find the correct GCD every time it does Reduce()
Some languages contain rational numbers in their standard. One of those is Common Lisp and dividing two non-floats (of whatever precision) always yields a rational number there (the integer type is a subtype of the rational type).

258
General Discussion / Re: Internet habits which annoy you.
« on: November 30, 2015, 03:51:21 pm »
Quote from: Graknorke on November 30, 2015, 03:38:25 pm
Quote from: Ispil on November 30, 2015, 12:24:19 pm
My point is, not every discussion needs to turn into a victory or failure.
Surely that only stands if you thinking that every position is right and wrong at the same time. Otherwise there would be a right side and a wrong side.
No, it only assumes that right and wrong aren't always determinable. Only because there is a right and wrong side it doesn't mean that we have a meaningful way of finding out which is what.

Also in a lot of cases what Ispil said is important. Some things are just subjective and many things discussed depend on subjective things.

259
General Discussion / Re: Gunnerkrigg Court: Confusion, confusion everywhere!
« on: November 30, 2015, 02:12:16 pm »
I think it's this:
Spoiler (click to show/hide)

260
Creative Projects / Re: Programming Language: Poslin
« on: November 28, 2015, 12:32:29 pm »
Yesterday I implemented `env-lookup` on paper and discovered a fatal flaw: The implementation of it depends on the operations `drop-here` and `dup-here` who, in turn, depend on `env-lookup`. This leads to an endless recursion. As far as I know, as the system currently stands, there is no way around this.

But!
I thought about environments a bit and then a bit more.

First: Using environments on the path seems to be completely superfluous. In the whole standard library I have not a single case of pushing a more complex environment onto the path – I always just used a completely shallow environment whose slots had been modified. That is completely equivalent to just using a map instead of an environment.
So I can make the Path a stack of maps instead of a stack of environments. This way the problem of the endless recursion in `env-lookup` goes away.

Second: I don't think environments are actually useful. Well, they will be useful for implementing packages, but that's about it. Anything else can be achieved by just making a new binding – everything works the same outwards, unless you want to change the parent environment, which never came up anywhere at all (well, unless we're talking about packages, where changing the parent environment is like fiddling with imports).

So, I guess I'll remove all the environment stuff from the interpreter altogether. They'll probably have a comeback as packages some time in the future, though. And then there will need to be an operation to flatten a package into a map, but that shouldn't be too hard, right? ::)

261
Creative Projects / Re: Programming Language: Poslin
« on: November 25, 2015, 11:44:39 am »
I am currently in the middle of the rewrite to get rid of environments.
The interpreter already has been changed – the `OP` slot now contains a stack of maps while the `IMM` and `FEATURES` slots contain stacks of sets. The primary
operations for manipulating sets and maps have been added while the primary operations for environments have been removed. That was harder than expected.
A side effect of the change is that environments now except anything as keys and values, when before only symbols were valid as keys and bindings valid as values. Of course you can try to take advantage of this, but the interpreter will choke on non-binding values in the operation environment.
Unless there's some hidden bugs or strange edge cases the rewrite of the interpreter should be done for now, although I think it might be a bit… chaotic at this point. Lots of duplicated code and insufficient abstraction, which bit me multiple times through this rewrite.

The standard library now needs to be rewritten – at least partly.
Because sets are now in as data structure, having operation names like `map-set`, `env-set` or `set-set` seemed really strange. That's why `env-set` and all similar operations now instead are named `env-insert` and the like. `path-set` is an exception – it still is called `path-set`, as the operation is conceptually considerably different from what is done to maps or sets.
The added operations are:
Code: [Select]
.empty-set
set-lookup
set-insert
set-drop

.empty-map
map-lookup
map-insert
map-drop
map-domain
`.empty-map` and `.empty-set` always return the same object, although I guess using `map-drop`/`set-drop` to make a map/set empty won't leave you with the same object at all. This is only of interest for usage of the operation `same?`, not for `compare`.

Implementing `env-lookup` proves to be surprisingly hard. Fortunately I don't need it for the conditional creation of operations in the standard library because I know that I only need to operate on the top map in the operation environment at the points where I had used an environment lookup before. Still, every operation defined on `env-lookup` will move quite a bit to the back in the standard library.
Also there will need to be operations corresponding to the stacks of sets. I'm not quite sure what to call these yet.

262
Creative Projects / Re: Draw Fortress
« on: November 22, 2015, 05:38:52 pm »
PTW
Same for me. The first few pages are devoid of images and there are some missing throughout, too.

263
Creative Projects / Re: Furniture/Room/House Appreciation Thread (No, really).
« on: November 22, 2015, 05:18:34 pm »
2.) Yeah, impressive technology it is. I prefer the non-motorized version – we're using enough power as it is and this doesn't seem like something where there is much gained by not doing it by yourself.

3.) That sliding wall seems like an accident waiting to happen – I didn't see anything to lock it in place.
Impressive, though.

264
Creative Projects / Re: Programming Language: Poslin
« on: November 22, 2015, 01:13:20 pm »
I didn't really do anything new, but I discovered that the startup scripts provided in the last three distributions were erroneous. As such there's now the final release for 0.3.0 for linux-x86. I also finally managed to put together a distribution for OS X on x86_64.
They're available at the usual place.

The next version will hopefully be 0.4.0, where I get rid of environments. That only means that everything regarding environments will be moved to the standard library, so hopefully code that relies on the standard library (as if there was any ::)) should be unaffected by that change.

265
General Discussion / Re: Gunnerkrigg Court: Confusion, confusion everywhere!
« on: November 16, 2015, 01:12:22 pm »
Seems like artificial life forms.

266
Other Games / Re: Games you wish existed
« on: November 15, 2015, 06:35:19 am »
Quote from: scrdest on November 15, 2015, 06:05:49 am
Reading Prequel, I've been reminiscing about playing Oblivion and its ridiculously tiny CAPITAL OF THE GODDAMN EVERYTHING.

So, an idea came to me: a TES(-style) RPG that is pretty much the same as the rest in playstyle, but its setting is a single city that spans the entire world map. Kinda like TES meets older GTAs, set in something like the City from Thief.

Fantasy-ier than GTA, more open-ended gameplay-wise than Thief, more focused in setting than TES.
Yeah, something like that would be awesome.

267
Life Advice / Re: The Generic Computer Advice Thread
« on: November 05, 2015, 04:16:47 am »
Quote from: Bauglir on November 04, 2015, 09:52:52 pm
Quote from: Antsan on November 03, 2015, 04:05:35 pm
That would be Bauglir, I think.
Oh, my, no. I'm mostly useless. Flattered that you thought so, though. Good thing I checked this thread at random today!
Oh. Bauglir, Baughn…
This is embarrassing.

268
Life Advice / Re: The Generic Computer Advice Thread
« on: November 03, 2015, 04:05:35 pm »
That would be Bauglir, I think.

269
Creative Projects / Re: Random Things you drew/shopped/made/etc.
« on: October 31, 2015, 11:26:24 am »
I see what they mean: Not bent in the way it should be, but slightly bent sideways, that is, upwards if you assume one of the sides points up.
Put another way: The handle seems to be at 30-45°, the tip is almost pointing upwards.

270
Creative Projects / Re: Programming Language: Poslin
« on: October 27, 2015, 10:14:07 am »
I've been doing some work on packages and I hit a wall pretty fast.
I was writing an operation to import one package into another. As a package is only an environment containing all of the slots required for an environment on the path safe for `STACK` that basically consists of merging all the slots in the two packages in the correct order.
This merging process is easy for slots which contain an environment: Split the environment of the importing package into the parent and the environment without the parent, make that parent the… uhm… root ancestor of the environment of the imported package and then make the resulting environment the parent of the environment of the importing package. Safe for the pretty awful description I just gave that is a really straightforward process.
It's not so easy for something like the FEATURES slot, which contains a stack. Should the stacks just be appended? Hm…
Strangely enough, the IMM slot contains an environment, although it is structurally kind of similar to FEATURES – it either contains an object or it doesn't. So, those two should actually contain stacks of sets.

The idea is to get rid of environments and replace them with stacks of maps. The interpreter can deal with that easily (it's just a fold) and operations like `env-lookup` can be implemented in the standard library.
At the same time IMM and FEATURES would now contain stacks of sets.
That means maps and sets would need to become primary types with the associated primary operations, while environments would vanish.

Any thoughts on this? Is anyone actually still reading, or are all of you just taking a look whether finally something interesting happens?

Pages: 1 ... 16 17 [18] 19 20 ... 71