Project Euler in LOLCODE and 1.3 stable specification

[Leonardo Donelli]

Hi guys, I'm solving project euler problems in LOLCODE, using LCI as interpreter and using the 1.2 specification.
I am now at a point where it's getting really hard to solve the problems without at least an array type.
I know LCI supports BUKKIT and other parts of the "1.3 spec" but I would like to avoid that until a stable, official 1.3 spec is released. Do we have any ETA on this?

Here are my solutions: https://github.com/LeartS/loleuler

[Justin Meza]

Hi Leonardo,

Two things:

1.  Awesome job on the solutions so far!  Another guy (markjreed) was attempting some solutions and got through problem 6 (https://github.com/markjreed/eulol).  You can check out his solutions as well if you haven't already.

2.  I would recommend going ahead and using the features in the "future" branch of lci (BUKKIT and so on).  While there isn't an official spec yet, that is mainly because we haven't had a chance to draft one up and not because the feature set keeps changing (in fact, so far features have typically just been added, without being later modified).

For what it's worth, we've had some discussion about this on IRC, and if we were going to change something in a way that breaks backward compatibility at this point, it would likely be the way that external libraries are implemented (like the STRING library and SOCKS library -- see https://github.com/justinmeza/httpd.lol for an example) -- I think the community is pretty much OK with how BUKKITs and other features in the future 1.3 currently are.

- Justin

--
You received this message because you are subscribed to the Google Groups "lci-general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lci-general...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Leonardo Donelli]

Hey Justin,
Thanks for your answer. I went ahead and solved a problem using 1.3, see the solution to problem 14.
Some things to note:
 * Possible variable assignment bug: https://github.com/justinmeza/lci/issues/17
 * Is there a way to check if a BUKKIT has a slot, or some way to get a default value in case one tries to access a slot that doesn't exists? I thought the slot "omgwtf" would do that, but I couldn't assign a function to it.
 * BUKKITs are slooooooow! lines 4-7 are just an initialization of an array used to keep already computed results into memory, my idea was to do that for [0, 1kk].. turns out it takes almost a minute just to do that loop for 100k N!

[Justin Meza]

Just to follow up on this:

- Thanks for catching a couple of bugs.  For the additional features you mentioned in Github issues, you may want to also start threads on the forum (forum.lolcode.org) in case people want to add their opinions there.

- lci doesn't implement the special-purpose slots (like omgwtf).  It's not clear if these should be handled in that way or if some exception mechanism would work better.  This is something that should be discussed.

- Thanks for pointing this out.  I looked into this, and this was due to lci linearly traversing an array to lookup and update values in scopes (which is really inefficient when there are a lot of values in a scope).  I've changed the future branch of lci to store values in scopes in lexicographical order and do a lexicographic binary search to locate values.  On my system this changed initializing a 100K element array from taking 83.20s on average to taking 0.98s on average.

The downside of the last point is that since the data is still stored as an array, insertion still takes O(n) time and so for large arrays, the initialization time will be dominated by this (a 1M element array took around 63s to initialize).  Since this is typically done once, it's probably worth it to keep the faster lookup and update times, though.

Another thing that helped slightly for me was to make sure you use the -DCMAKE_BUILD_TYPE=Release flag with CMake.

I made quite a few changes to some core code and though all the unit tests still pass, you may want to re-run some of your code to make sure it works OK on the future branch.

- Justin