Vaporware: metaduel simulator
Kenneth 'Bessarion' Boyd
model. (Basically, high AC [damage reduction] is flaky even with heavy armor,
and it is very much not to be relied on for light-armor characters. EV
corresponds to *band AC.)
So...time to write a metaduel simulator that I can use to try to balance both
SSCrawl and *bands. But...which language? C++ is out this time (don't have the
exact classes I need already developed).
The current candidates: Perl, Python (familiar), Lua (zero-knowledge, but had no
trouble installing) and Haskell (zero-knowledge; HUGS prebuilt binary, as
neither HUGS nor nhc98 install from C sources unmodified on my system. This is
expected for nhc98.)
The ideal implementation language would
* let me define the game-specific functions in a file included/required/whatever
into the file defining the actual emulator
* have a clean emulation of 2-d arrays (or arrays of arrays) that has
reasonable behavior when updated. (Neither Perl nor Python does, otherwise I'd
have already started. Perl loses on syntax, Python on internal implementation.)
Krice
wrote:
> But...which language? C++ is out this time (don't have the
> exact classes I need already developed).
What the heck are you talking about? You make classes
by what we developers call 'programming'.
> The ideal implementation language would
> * let me define the game-specific functions in a file included/required/whatever
> into the file defining the actual emulator
> * have a clean emulation of 2-d arrays (or arrays of arrays) that has
> reasonable behavior when updated.
Did you ate bad mushroom?
Antoine
LOL - Nice post Krice
A.
Kenneth 'Bessarion' Boyd
> On 27 maalis, 08:37, Kenneth 'Bessarion' Boyd
> wrote:
> > But...which language? C++ is out this time (don't have the
> > exact classes I need already developed).
>
> What the heck are you talking about? You make classes
> by what we developers call 'programming'.
I like my non-library C++ to have the expressiveness of Haskell, LISP, and
related languages. This takes some work.
It's only an educated guess that a 4th-generation language is going to take less
time to bootstrap for this case.
Krice
wrote:
> It's only an educated guess that a 4th-generation language is going
> to take less time to bootstrap for this case.
Well good luck with Haskell or Lisp. Those languages just rule
and everyone is making roguelikes with them.
jrar...@gmail.com
> reasonable behavior when updated. (Neither Perl nor Python does, otherwise I'd
> have already started. Perl loses on syntax, Python on internal implementation.)
Would you like to elaborate on what you mean with 'clean emulation of
2-d arrays'?
Martin Read
Krice, meet point. Point, meet Krice. I know you've never met each
other before, but I'm sure you'll get along just fine.
On this particular thread, he isn't talking about writing a roguelike;
he's talking about writing a tool for analysing the combat systems of
roguelikes.
--
\_\/_/ some girls wander by mistake into the mess that scalpels make
\ / are you the teachers of my heart? we teach old hearts to break
\/ --- Leonard Cohen, "Teachers"
jot...@hotmail.com
encapsulates 2D arrays with a nice syntax is easy enough, do you need
help with that? I'd only try a project like that on an unknown
language as a learning experience, never expecting to actually finish
it with all of the features I wanted.
Jotaf
Kenneth 'Bessarion' Boyd
> > * have a clean emulation of 2-d arrays =A0(or arrays of arrays) that has
> > reasonable behavior when updated. (Neither Perl nor Python does, otherwise=
> I'd
> > have already started. =A0Perl loses on syntax, Python on internal implemen=
> tation.)
>
> Would you like to elaborate on what you mean with 'clean emulation of
> 2-d arrays'?
I want:
* no worse than log-n access time in each dimension
* merely accessing doesn't cause unwarranted garbage collection
* assignment by value doesn't cause unwarranted garbage collection
* an access syntax that looks like one of point-value or dereferencing an array
twice.
If it only fully instantiates elements I actually access, that's even better but
not critical.
The basic acceptable approaches are a hash keyed by 2-d points (the hitpoints of
the player and the monster in the duel) or an array of arrays.
Perl:
* requires all elements of either an array, or a hash, to be scalars.
** A hash keyed by 2-d points would have to go through string concatenation to
both create and parse the keys. (Barely acceptable as string operations are
cheap in Perl, but keep in mind that Perl has two layers of memory allocation.)
** A Perl array of arrays is actually an array of references to arrays, and the
syntax for this is in your face when coding.
Python:
* By design, cannot update an immutable sequence in place: the *whole* prior
sequence must be garbage collected. The only mutable sequence (Python 2.5,
although generally true for earlier versions) is the list, which would be
expected to have some sort of linear access time. This strongly biases
against a sequence of sequences (array of arrays) implementation.
* has a reasonable tuple for representing n-d points, favoring a dictionary
(hash) implementation. [A 2-element list is even better as the temporary could
be updated in-place, but lists are not allowed as dictionary keys.] Tuples are
immutable objects, with the obvious consequences for garbage collection.
Lua:
* I have almost no clue about this language. This would be an intentional
learning exercise.
* I think tables correspond to hashes (and arrays). I suspect a table of tables
implementation may be cleaner than a table mapping some representation of
points, but don't have a good idea what a clean direct point representation
would be. I expect actual element updates to be reasonably efficient.
Haskell:
* I have almost no clue about this language. This would be an intentional
learning exercise.
* I don't see any data structure correponding to hashes, and have little idea
what the backend does in updating an array of arrays.
Chris Morris
Kaya's arrays fit this one, I think.
Kenneth 'Bessarion' Boyd <zai...@zaimoni.com> writes:
> * no worse than log-n access time in each dimension
> * merely accessing doesn't cause unwarranted garbage collection
> * assignment by value doesn't cause unwarranted garbage collection
> * an access syntax that looks like one of point-value or
> dereferencing an array twice.
arr[x][y]
> If it only fully instantiates elements I actually access, that's
> even better but not critical.
In most cases this is true.
> * I have almost no clue about this language. This would be an intentional
> learning exercise.
This would probably still apply, of course.
The implementation is array of arrays (you can do a hash keyed on a
pair of ints instead if you want, but the syntax is nowhere near as
nice).
--
Chris
Kenneth 'Bessarion' Boyd
> It seems that the classes you want are trivial.
Agreed.
> A class that
> encapsulates 2D arrays with a nice syntax is easy enough, do you need
> help with that?
No.
I need help understanding which language is not going to actively fight me when
actually coding this. See other reply for what kind of analysis I'm doing. I
have to be at least non-fluent in the language to do it right, so I only trust
my own analyses for Perl and Python. Both Perl and Python are going to actively
fight me when implementing this.
I have already ruled out Oz (algorithm does not have a reasonable
non-deterministic rewrite), LISP (only lists as data structure) and ML
(prejudiced against modules rather than varying source files). I'm willing to
consider any other fourth-generation language that both
* can handle at least one of hashes or arrays of arrays
* either knows natively what a loop data structure is, or supports
constant-space arbitrary depth recursion.
I prefer languages that have at least one implementation that should bootstrap
from one of C or C++, but this is not a requirement.
> I'd only try a project like that on an unknown
> language as a learning experience, never expecting to actually finish
> it with all of the features I wanted.
This is a feature-complete mini-project. If this were C/C++, I would consider
this stage of project completed with a well-defined main() [the per-duel
configuration would be handled by an included header.] A later stage would
involve programmatically generating that included header; that is as open-ended
as you suggest.
awhite
[snip]
> I have already ruled out Oz (algorithm does not have a reasonable
> non-deterministic rewrite), LISP (only lists as data structure) and ML
> (prejudiced against modules rather than varying source files).
Lisp hasn't just had lists as data structure for literally decades!
It has a very nice implementation of true multi-dimensional arrays
CL-USER> (defparameter *a* (make-array '(3 4)))
*A*
CL-USER> *A*
#2A((NIL NIL NIL NIL)
(NIL NIL NIL NIL)
(NIL NIL NIL NIL))
CL-USER> (setf (aref *a* 2 3) 1)
1
CL-USER> (setf (aref *a* 1 2) 2)
2
CL-USER> *a*
#2A((NIL NIL NIL NIL)
(NIL NIL 2 NIL)
(NIL NIL NIL 1))
I'd check it out for your simulator - it's not just a purely functional
language, it's (like C++ is in its own niche) a multi-paradigm language.
Adam
Paul Donnelly
> On 2008-03-27 19:41:50, "jrar...@gmail.com" <jrar...@gmail.com> wrote:
>
>>> * have a clean emulation of 2-d arrays (or arrays of arrays) that
>>> has reasonable behavior when updated. (Neither Perl nor Python
>>> does, otherwise I'd have already started. Perl loses on syntax,
>>> Python on internal implementation.)
>>
>> Would you like to elaborate on what you mean with 'clean emulation of
>> 2-d arrays'?
>
> I want:
> * no worse than log-n access time in each dimension
> * merely accessing doesn't cause unwarranted garbage collection
> * assignment by value doesn't cause unwarranted garbage collection
> * an access syntax that looks like one of point-value or dereferencing
> an array twice.
>
> If it only fully instantiates elements I actually access, that's even
> better but not critical.
>
> The basic acceptable approaches are a hash keyed by 2-d points (the
> hitpoints of the player and the monster in the duel) or an array of
> arrays.
>
> Perl:
>
> Python:
>
> Lua:
>
> Haskell:
I don't really understand what you're going for. From your requirements,
it looks like you're after high performance, but you don't seem to be
considering any high performance languges (except possibly
Haskell... not sure how it stacks up to the others).
Personally, I'd do it in Common Lisp (because it's my go-to language) or
in Factor, since I'm interested in learning it better.
P.S. CL's array access syntax is:
(aref array subscript-1 ... subscript-n)
to read and
(setf (aref array subscript-1 ... subscript-n) new-value)
for writes. You can also have a hash table keyed with whatever.
Factor doesn't seem to have 2d arrays, but it does have hash tables and
tuples (it's stack-based, like Forth):
USE: hashtables ! Hashtable functions live here.
TUPLE: duel @hp mhp ; ! A tuple for a key.
3 ! Push a value on the stack.
3 2 duel construct-boa ! Push a key on the stack with boa-constructor.
associate ! Push a hash table holding the above key/value.
Paul Donnelly
> On 2008-03-27 20:29:27, jot...@hotmail.com wrote:
>
>> It seems that the classes you want are trivial.
>
> Agreed.
>
>> A class that encapsulates 2D arrays with a nice syntax is easy
>> enough, do you need help with that?
>
> No.
>
> I need help understanding which language is not going to actively
> fight me when actually coding this. See other reply for what kind of
> analysis I'm doing. I have to be at least non-fluent in the language
> to do it right, so I only trust my own analyses for Perl and Python.
> Both Perl and Python are going to actively fight me when implementing
> this.
>
> I have already ruled out Oz (algorithm does not have a reasonable
> non-deterministic rewrite), LISP (only lists as data structure)
WHOA WHOA WHOA HOLD IT RIGHT THERE
:P
I don't want to push you at Lisp (although as I said in my other post
it's what I personally would choose), but if this is your reason for
discounting Lisp you may want to reconsider when I introduce you to my
friends MAKE-ARRAY, MAKE-HASH, and DEFSTRUCT too*.
I guess maybe you picked up on the above in my other post, but since I
typed this before realizing that, here it is. And since Common Lisp fits
all your requirements and your bootstrapping preference too, I figured
it would be worthwhile to suggest you reconsider it. CL has the data
structures you need as well as several iteration facilities including
the pseudo-English LOOP, its Lispier cousin ITERATE (well-known but not
built in), some simpler looping functions, and even goto (TAGBODY),
should you want that.
Common Lisp is pretty much my definition of a tractable language, and
the phrase "doesn't fight with me" has crossed through my mind on more
than one occasion. I wouldn't normally try to convince someone to use
it, but since you're basically describing CL to us, I figured I'd take
the time.
* No, you don't have to write Lisp code in all caps. It's just customary
to capitalize symbol names in prose to make them identifiable.
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd writes:
I don't need an astronomically low constant multiplier on the O() figure [that
would be C or C++]. I do need to conserve fluent-developer time
(fourth-generation), and want a decent O() on the algorithm -- *including the
garbage collector*. C/C++ is lousy for flygrams, so I'm willing to eat
learning curve so I have more options when I need to develop other flygrams for
work quickly.
Python is basically out of the picture because how it handles immutable
sequences is causing a bad O() on garbage collection. [The same design choices
make it almost C-equivalent in machine performance for text processing
problems.]
Building an array out of a list is "easy", but the O(n) access-by-index time is
will be disastrous when balancing Morgoth; it's still a list even if the
notation is an array.
Kenneth 'Bessarion' Boyd
> Kaya's arrays fit this one, I think.
Yes.
The binary install procedure for Windows is scary (I already have a moderately
unconventional MingW32 install). As for build from source -- I see that it
requires GHC, which I ignored on the Haskell implementations because its C
bootstrap process is very complicated, and it does not have a current binary
Windows release.
GHC's devteam broke C bootstrap when going from 5.6.x to 5.8.0. To bootstrap
GHC 5.8.x from C, you first have to install GHC 5.6.x, bootstrap that, then use
GHC 5.6.x to build GHC 5.8.x . (This is on their fix list, but IMO their
quality control critically failed; this is not the sort of thing you fix once
you break it intentionally.)
Ray Dillinger
> I have already ruled out Oz (algorithm does not have a reasonable
> non-deterministic rewrite), LISP (only lists as data structure)
Dude. Been under a rock for thirty years? Not only does Lisp
have all the data structures you want (strings, arrays, hash
tables, objects, records, etc....), it has full compilation to
machine code in most of the major implementations and runs faster
than anything else you've mentioned.
Bear
Chris Morris
> > Kaya's arrays fit this one, I think.
>
> Yes.
>
> The binary install procedure for Windows is scary (I already have a
> moderately unconventional MingW32 install).
Not that it would be all that convenient, but you could probably
unpack a separate MinGW/MSys system if you were worried about some of
the pre-compiled libs in the binary distribution messing with your
existing ones.
Getting off-topic, I suppose, but can you think of any ways to make it
less scary?
> As for build from source -- I see that it requires GHC, which I
> ignored on the Haskell implementations because its C bootstrap
> process is very complicated, and it does not have a current binary
> Windows release.
I got my GHC windows build from
http://haskell.org/ghc/download_ghc_682.html#windows
Kaya is definitely not the easiest thing to build from source on Windows,
though.
--
Chris
Christophe
> Python:
> * By design, cannot update an immutable sequence in place: the *whole* prior
> sequence must be garbage collected. The only mutable sequence (Python 2.5,
> although generally true for earlier versions) is the list, which would be
> expected to have some sort of linear access time. This strongly biases
> against a sequence of sequences (array of arrays) implementation.
> * has a reasonable tuple for representing n-d points, favoring a dictionary
> (hash) implementation. [A 2-element list is even better as the temporary could
> be updated in-place, but lists are not allowed as dictionary keys.] Tuples are
> immutable objects, with the obvious consequences for garbage collection.
The only difference between tuple and list in Python is that you cannot
change a tuple. list has O(1) element access time as you should know if
you had take the time to look for it. A simple google search for Python
list performance would have shown it to you with the first result.
One has to wonder how it would be even possible to write performant code
in Python with the "limitations" you though it had.
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd a écrit :
> > Python:
> > * By design, cannot update an immutable sequence in place: the *whole* prior
> > sequence must be garbage collected. The only mutable sequence (Python 2.5,
> > although generally true for earlier versions) is the list, which would be
> > expected to have some sort of linear access time. This strongly biases
> > against a sequence of sequences (array of arrays) implementation.
> > * has a reasonable tuple for representing n-d points, favoring a dictionary
> > (hash) implementation. [A 2-element list is even better as the temporary could
> > be updated in-place, but lists are not allowed as dictionary keys.] Tuples are
> > immutable objects, with the obvious consequences for garbage collection.
>
> The only difference between tuple and list in Python is that you cannot
> change a tuple. list has O(1) element access time as you should know if
> you had take the time to look for it. A simple google search for Python
> list performance would have shown it to you with the first result.
That claims the Python devteam is openly lying by calling an array a list: not
something I would expect from a language advocate.
I need authoritative sources to believe that. Python source, Python
documentation, or something hosted on the official website Python.org by a
known-good user all count.
> list performance would have shown it to you with the first result.
I see non-authoritative sources. No authoritative sources come up on the google
query I'm using. The *one* non-authoritative source claiming this in the top 30
for "Python list access time", actively refutes the claim with its own quoted
timing test: http://norvig.com/python-lisp.html . This is the 9th result at
time of posting.
The same performance time documents that a LISP adjustable array actually *is*
an array. So I'll take a closer look, as that language committee has revised in
arrays since the early 1990's.
> One has to wonder how it would be even possible to write performant code
> in Python with the "limitations" you though it had.
The area-averaging image rescaler I wrote in Python (to avoid having to learn
the Windows GUI at the time) is *not* performant; it is about 10,000x slower
than C. The non-performance is mostly from the immutability of tuples (which
are required from the Python interface to Tk/Tcl)
Python is performant when the programs intentionally avoid the garbage collector
and assignment by value.
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd a écrit :
> > Python:
> > * By design, cannot update an immutable sequence in place: the *whole* prior
> > sequence must be garbage collected. The only mutable sequence (Python 2.5,
> > although generally true for earlier versions) is the list, which would be
> > expected to have some sort of linear access time. This strongly biases
> > against a sequence of sequences (array of arrays) implementation.
> > * has a reasonable tuple for representing n-d points, favoring a dictionary
> > (hash) implementation. [A 2-element list is even better as the temporary could
> > be updated in-place, but lists are not allowed as dictionary keys.] Tuples are
> > immutable objects, with the obvious consequences for garbage collection.
>
> The only difference between tuple and list in Python is that you cannot
> change a tuple. list has O(1) element access time as you should know if
> you had take the time to look for it. A simple google search for Python
> list performance would have shown it to you with the first result.
A simple search from the *Python* website gets it via the rejected PEP3128 :
http://www.python.org/dev/peps/pep-3128/ .
The proven-dishonest naming of the list type is annoying.
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd writes:
> > On 2008-03-27 21:45:27, Chris Morris wrote:
> > > Kaya's arrays fit this one, I think.
> >
> > Yes.
> >
> > The binary install procedure for Windows is scary (I already have a
> > moderately unconventional MingW32 install).
>
> Not that it would be all that convenient, but you could probably
> unpack a separate MinGW/MSys system if you were worried about some of
> the pre-compiled libs in the binary distribution messing with your
> existing ones.
What I actually tried was unpacking the ZIP archive to a separate directory,
then try moving the files to their correct location on my system with a complete
audit trail.
This did not work: kayac was built to require a DLL that wasn't shipped in the
archive. No doubt the DLL would have been there if I used the standard *.EXE
installers for MingW32 and MSYS, but both are broken when trying to
clean-install on Win95. (I maintain comparable installs on all of Win95,
Win2000, and Vista; if one updates, all must update the same way.)
The Vista install of MingW32 relies on /bin being c:bin, etc. The W2K install
is a similar design, but is rooted on g: drive. Win95 is rooted in the
c:MingW32 directory for historical reasons (I only figured out where it should
be rooted in late 2007, it was installed back in 2001).
I have GCC/C,C++,FORTRAN and binutils installed, as well as a selection of
utilities from bzipped tarballs. A few holes are covered using tarballs from
the CygWin distribution. Perl and Python are the usual Windows releases
(ActiveState and official, respectively). Perl doesn't make it easy to
build-from-source to use bash rather than cmd on windows, which I think is
needed to fix some issues I currently have.
Ray Dillinger
> That claims the Python devteam is openly lying by calling an array a list:
> not something I would expect from a language advocate.
No... the people who named those lists were speaking mathematics
or theory, and called them lists because they match the formal
semantics of a list (That is to say, an ordered sequence of
elements). They're not lying, they're just using a more
general meaning of the word "list" than the one in your head.
You're speaking engineering and you're treating the general word
"list" as a contraction of the engineering term "linked list."
But a linked list is only one of many possible implementation
strategies for lists; storing the elements in contiguous memory
(what you call "arrays") is another.
You have to remember that implementation strategies have nothing to
do with formal semantics. If something provably produces the same
answers, then it has the same formal semantics, whether it produces
the answers in exponential or constant time.
The mathematicians and theorists own the term "list" when it's used
with no qualifiers; use it more specifically only if you're willing
to risk misinterpretation. Engineering only owns qualified versions
of it, like "linked list" and "doubly linked list" and so on.
Bear
Krice
wrote:
> (I maintain comparable installs on all of Win95,
> Win2000, and Vista; if one updates, all must update the same way.)
Do you mean you use all those at the same time? Why? Are
you a space alien or something? If so, don't abduct me, I'm
not against space aliens in earth, you are welcome here.
But try to act more like humans!
Kenneth 'Bessarion' Boyd
> On 28 maalis, 18:00, Kenneth 'Bessarion' Boyd
> wrote:
> > (I maintain comparable installs on all of Win95,
> > Win2000, and Vista; if one updates, all must update the same way.)
>
> Do you mean you use all those at the same time? Why?
Not quite, as the Win95 and Win2000 installs are on a dual-boot machine. As a
side issue, I do have a reference game (for game design) that only runs on
Win95/Win98.
Mainly, it's a small part of business continuity planning. Both machines have
to go completely down before I can't work because of worm programs or similar
goo.
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd wrote:
>
> > That claims the Python devteam is openly lying by calling an array a list:
> > not something I would expect from a language advocate.
>
> No... the people who named those lists were speaking mathematics
> or theory, and called them lists because they match the formal
> semantics of a list (That is to say, an ordered sequence of
> elements). They're not lying, they're just using a more
> general meaning of the word "list" than the one in your head.
On 2008-03-28 18:00:05, Ray Dillinger <be...@sonic.net> wrote:
> Kenneth 'Bessarion' Boyd wrote:
>
> > That claims the Python devteam is openly lying by calling an array a list:
> > not something I would expect from a language advocate.
>
> No... the people who named those lists were speaking mathematics
> or theory, and called them lists because they match the formal
> semantics of a list (That is to say, an ordered sequence of
> elements).
They do *not* match the formal semantics of a list, as those formal semantics
specify which operations must be O(1) [up to memory manager overhead], just as
the formal semantics for an array specific which operations on an array must be
O(1).
The formal semantics is documented as an array (as random-access is O(1) while
insertion is O(n) with amortized O(1)). The reported overhead is simply
awesome.
> You're speaking engineering and you're treating the general word
> "list" as a contraction of the engineering term "linked list."
Well, we are discussing software engineering.
> But a linked list is only one of many possible implementation
> strategies for lists; storing the elements in contiguous memory
> (what you call "arrays") is another.
Only in the *very* general sense that both approaches support iterating from
begin to end of the data structure. One could just as well include the various
kinds of trees at this level of abstraction.
> You have to remember that implementation strategies have nothing to
> do with formal semantics.T
The formal semantics of data structures specify O() bounds, not just
interfaces.
As a matter of interfaces, you are correct.
> The mathematicians and theorists own the term "list" when it's used
> with no qualifiers;
The mathematicians do *not* own the term "list" when it is used without
qualifiers: there is no field of higher mathematics (considered as
specializations of analysis, algebra, and topology) where "list" has a generally
accepted meaningful definition. They own the term "sequence" (and have made
sure one definition works everywhere, up to the choice of how to index the
elements of the sequence and where the elements in the sequence come from).
As for language theorists: what I have read about the theory behind Forth, C,
C++, LISP, etc. doesn't suggest they own the term "list" either. So software
engineering does own the term "list", as a contraction of various kinds of
linked list.
Paul Donnelly
> The same performance time documents that a LISP adjustable array
> actually *is* an array. So I'll take a closer look, as that language
> committee has revised in arrays since the early 1990's.
Maybe I'm misreading you, but Lisp has had arrays since the mid-1960s at
least. They're documented in the Lisp 1.5 manual.
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd writes:
>
> > The same performance time documents that a LISP adjustable array
> > actually *is* an array. So I'll take a closer look, as that language
> > committee has revised in arrays since the early 1990's.
>
> Maybe I'm misreading you, but Lisp has had arrays since the mid-1960s at
> least. They're documented in the Lisp 1.5 manual.
I just know that when I last looked at LISP (early 1990's), all of the LISP
tutorials available were emphatic that LISP's only data structure was the list.
No mention of arrays at all.
Said manual was *not* available at the time, obviously. There's a reason why I
like to have full language specifications when self-teaching programming
languages; the real textbooks have way too much misinformation.
Krice
wrote:
> Maybe I'm misreading you, but Lisp has had arrays since the mid-1960s at
> least. They're documented in the Lisp 1.5 manual.
Transmissions through long distances in space are slow.
They have outdated information. Also looks like he doesn't
know that we have invented software like antivirus and
firewall to keep out worms. He must be somewhat confused,
at least now when he's so obviously a space alien and
can't fool us think he is a human.
Anyway, I welcome him to earth!
Antoine
Heh heh, keep 'em coming Krice
A.
Kenneth 'Bessarion' Boyd
> A couple of days ago, I finally managed to understand SSCrawl' 0.3.4's combat
> model. (Basically, high AC [damage reduction] is flaky even with heavy armor,
> and it is very much not to be relied on for light-armor characters. EV
> corresponds to *band AC.)
>
> So...time to write a metaduel simulator that I can use to try to balance both
> SSCrawl and *bands. But...which language? C++ is out this time (don't have the
> exact classes I need already developed).
>
> The current candidates: Perl, Python (familiar), Lua (zero-knowledge, but had no
> trouble installing) and Haskell (zero-knowledge; HUGS prebuilt binary, as
> neither HUGS nor nhc98 install from C sources unmodified on my system. This is
> expected for nhc98.)
Haskell gets the first chance. Per recommendations elsewhere, Kaya, Common
LISP, and Factor are all in the candidacy as well should the Haskell
implementation run into trouble.
The Haskell implementation of the main computational framework is finished
(remember that specific examples are configured elsewhere). Getting meaningful
information summaries out is what's blocking release. I'll know more about
whether this is "performant" later.
R. Dan Henry
<zai...@zaimoni.com> wrote:
>A couple of days ago, I finally managed to understand SSCrawl' 0.3.4's combat
>model. (Basically, high AC [damage reduction] is flaky even with heavy armor,
>and it is very much not to be relied on for light-armor characters. EV
>corresponds to *band AC.)
>
>So...time to write a metaduel simulator that I can use to try to balance both
>SSCrawl and *bands. But...which language? C++ is out this time (don't have the
>exact classes I need already developed).
Okay, this thread has turned into a rambling set of technical arguments,
but I have a more basic question: What exactly are you trying to
accomplish? And how do you imagine that cross-system comparisons will be
useful to balance either Crawl or *bands internally? Or are you trying
to balance them against each other (how would that even make sense)? Or
are you just trying to write one program to test both combat systems? In
which case, wouldn't it make more sense to just focus on the *multiple*
combat systems in *bands?
--
R. Dan Henry = danh...@inreach.com
If you wish to put anything I post on your website,
please be polite enough to ask first.
Krice
> Or are you just trying to write one program to test both
> combat systems?
I think their ship was damaged when they landed earth and they
has to repair the strategic combat AI system of it. For that they
need the highest level and most complex language we have: Haskell.
Kenneth 'Bessarion' Boyd
> On Thu, 27 Mar 2008 06:37:46 +0000 (UTC), Kenneth 'Bessarion' Boyd
> wrote:
>
> >A couple of days ago, I finally managed to understand SSCrawl' 0.3.4's combat
> >model. (Basically, high AC [damage reduction] is flaky even with heavy armor,
> >and it is very much not to be relied on for light-armor characters. EV
> >corresponds to *band AC.)
> >
> >So...time to write a metaduel simulator that I can use to try to balance both
> >SSCrawl and *bands. But...which language? C++ is out this time (don't have the
> >exact classes I need already developed).
>
> Okay, this thread has turned into a rambling set of technical arguments,
> but I have a more basic question: What exactly are you trying to
> accomplish? And how do you imagine that cross-system comparisons will be
> useful to balance either Crawl or *bands internally?
Long-term plans for Zaiband include "Crawlification".
V is simply *too easy* in the early game. Aside from trap detection issues and
the flaky store stocking, a properly built character is pretty much completely
safe on DL1. With Stealthy Dwarf movement and careful attention to
projectability, once the @ has a Death Bow and a detect traps method there are
almost no non-vault real threats through DL20 that actually require using
escapes (Teleport or Teleport Level).
Basically, minor tactical mistakes should be dangerous even on DL1. They
point-blank aren't in V, and fixing that doesn't belong in V.
> ... Or are you just trying to write one program to test both combat systems?
One family of programs, that share a single main.
Keith H Duggar
LOL ... I was not going to say anything but the urge became
irresistible once Krice wrote exactly what I too was thinking.
This guy /is/ from outer space. I've been reading his posts
for several months now and they rarely make sense and they
almost always rampage with misused vocabulary. And in this
thread he added "flygrams" (WTF?) to his language.
Which brings me to a bone I need to pick with Ray:
Ray Dillinger wrote:
> You're speaking engineering and you're treating the general word
As an engineer I find that insulting. What the OP is speaking
can only legitimately be termed "gibberish". Ie what one gets
from one trying to employ vocabulary (and buzzwords) beyond
their understanding.
I've found that for me to make any sense of the OPs postings
I have to step back, ignore the wanna-be technical prose, defocus
my brain and allow a blurry "feeling" to form of what he wants.
In this thread what he wants is to write a simulator but he is
not sure how and does not want to work very much to achieve his
goal. Therefore, he is searching for a magical language (called
"4th Generation") that will do most of the work for him.
You know, something like what the next-generation starships on his
home planet have? You simply speak commands such as "Computer, run
a meta-duel-hyper-parametric-configurable simulator for SSCrawl and
the *bands and pipe the analysis to my quarters."
What I still haven't figured out is why he doesn't want to use C++
("flygrams" not withstanding). Because were I so inclined I could
whip up from scratch a matrix class that would meet his needs in
45 minutes or less. But then ... I'm from Earth (mostly).
KHD
PS: Kenneth, if you decide C++ is what you want let me know and I
would be happy to help you write this simulator. But you will need
to spec more clearly what you want in plain Earth language.
Paul Donnelly
> On 2008-03-28 21:37:31, Paul Donnelly <paul-d...@sbcglobal.net> wrote:
>
>> Kenneth 'Bessarion' Boyd writes:
>>
>> > The same performance time documents that a LISP adjustable array
>> > actually *is* an array. So I'll take a closer look, as that language
>> > committee has revised in arrays since the early 1990's.
>>
>> Maybe I'm misreading you, but Lisp has had arrays since the mid-1960s at
>> least. They're documented in the Lisp 1.5 manual.
>
> I just know that when I last looked at LISP (early 1990's), all of the
> LISP tutorials available were emphatic that LISP's only data structure
> was the list. No mention of arrays at all.
I can believe that. Lisp teaching seems to be a little lacking sometimes.
> Said manual was *not* available at the time, obviously. There's a
> reason why I like to have full language specifications when
> self-teaching programming languages; the real textbooks have way too
> much misinformation.
True, true. Just stating my source.
Ray Dillinger
> They do *not* match the formal semantics of a list, as those formal
> semantics specify which operations must be O(1) [up to memory manager
> overhead], just as the formal semantics for an array specific which
> operations on an array must be O(1).
No. They don't. Nowhere in formal semantics as a field does one
find specifications of time complexity. In fact, one of the most
common operations in FS is to demonstrate Turing-machine equivalency,
using methods which often turn linear algorithms into exponential
or worse algorithms.
Formal semantics cares only about one property related to time,
and that is whether a computation will or will not finish in finite
time. Not constant, linear, or exponential. Merely finite.
>> You're speaking engineering and you're treating the general word
>> "list" as a contraction of the engineering term "linked list."
>
> Well, we are discussing software engineering.
My point was that the people who named Haskell's Lists were from
the camp that uses the language to discuss mathematics. It is you,
and not they, who are discussing software engineering; that does
not imply that they use the terms in exactly the same way as you.
>> But a linked list is only one of many possible implementation
>> strategies for lists; storing the elements in contiguous memory
>> (what you call "arrays") is another.
>
> Only in the *very* general sense that both approaches support iterating
> from
> begin to end of the data structure. One could just as well include the
> various kinds of trees at this level of abstraction.
Absolutely. And in Formal Semantics, one *does* include the various
kinds of trees at this level of abstraction. Because it's all about
speaking in the most general possible terms.
> The formal semantics of data structures specify O() bounds, not just
> interfaces.
False. Formal semantics are about results, provability, and finiteness.
Time and space bounds are not part of it. They are strictly engineering
considerations. Check out a book on Operational or Denotational Formal
semantics from the library. If you find *anything* in there that requires
a particular time complexity for any operation, I will _eat_ that book with
soy sauce, and pay to replace it.
Bear
Ray Dillinger
> Which brings me to a bone I need to pick with Ray:
> Ray Dillinger wrote:
>> You're speaking engineering and you're treating the general word
> As an engineer I find that insulting. What the OP is speaking
> can only legitimately be termed "gibberish". Ie what one gets
> from one trying to employ vocabulary (and buzzwords) beyond
> their understanding.
You're right, sorry. I was taking the OP too seriously. I
wind up having this discussion (formal semantics vs.
engineering terminology) several times an academic year
with serious engineering students, and was too quick
to respond to that point by itself, even though it was
in the middle of a bunch of other problems.
Bear
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd wrote:
> >> You're speaking engineering and you're treating the general word
> >> "list" as a contraction of the engineering term "linked list."
> >
> > Well, we are discussing software engineering.
>
> My point was that the people who named Haskell's Lists
The language that triggered this flamey rant is Python.
Haskell does it right (a list indeed is a list to the extent it actually exists
in memory, and arrays indeed are arrays), as do almost all other programming
languages.
Among the popular non-esoteric programming languages, Python uniquely uses
misleading denotation.
> were from
> the camp that uses the language to discuss mathematics. It is you,
> and not they, who are discussing software engineering; that does
> not imply that they use the terms in exactly the same way as you.
It's the other way around: they are discussing computational theory and computer
language design, *not* theoretical mathematics. I'm a mathematician who dabbles
in software engineering and compiler design.
Considering that:
* both LISP and Haskell have been around much longer, and have more substantial
theoretical credentials behind their development
* no other popular non-esoteric programming language makes this mistake
The argument from authority goes straight the other way.
> >> But a linked list is only one of many possible implementation
> >> strategies for lists; storing the elements in contiguous memory
> >> (what you call "arrays") is another.
> >
> > Only in the *very* general sense that both approaches support iterating
> > from
> > begin to end of the data structure. One could just as well include the
> > various kinds of trees at this level of abstraction.
>
> Absolutely. And in Formal Semantics, one *does* include the various
> kinds of trees at this level of abstraction. Because it's all about
> speaking in the most general possible terms.
One level of generality above where all of (linked) lists, arrays, and trees
exist.
> > The formal semantics of data structures specify O() bounds, not just
> > interfaces.
>
> False. Formal semantics are about results, provability, and finiteness.
> Time and space bounds are not part of it. They are strictly engineering
> considerations.
As a field, yes. [Strictly speaking, a concrete application of the
abstract-algebraic specialization category theory.]
*Not* when it comes to denotating (linked) lists, arrays, and trees : the formal
definition (and thereby *applied mathematical* formal semantics) is part of the
received art of software engineering.
Kenneth 'Bessarion' Boyd
> On Thu, 27 Mar 2008 06:37:46 +0000 (UTC), Kenneth 'Bessarion' Boyd
> wrote:
>
> >A couple of days ago, I finally managed to understand SSCrawl' 0.3.4's combat
> >model. (Basically, high AC [damage reduction] is flaky even with heavy armor,
> >and it is very much not to be relied on for light-armor characters. EV
> >corresponds to *band AC.)
> >
> >So...time to write a metaduel simulator that I can use to try to balance both
> >SSCrawl and *bands. But...which language? C++ is out this time (don't have the
> >exact classes I need already developed).
>
> Okay, this thread has turned into a rambling set of technical arguments,
> but I have a more basic question: What exactly are you trying to
> accomplish?
I doubt that the almost-undocumented source code for V0.01 of "Yet Another
Dungeon Simulator", linked from http://www.zaimoni.com/zaiband/yads.htm , will
be illuminating.
The next stage will be making the application relatively rapidly configurable
for specific games (starting with Angband), and formatting the calculated
results to be readable.
Currently displayed: a cross-check that the final probability matrix numerically
is a probability matrix; the epsilon used fo the run; the combat round on which
the probability the duel is still going is less than epsilon; probability of PC
winning (if pyrrhically), probability of monster winning, and probability of
duel still going on.
Kenneth 'Bessarion' Boyd
> On 2008-03-29 07:32:40, R. Dan Henry wrote:
> > Okay, this thread has turned into a rambling set of technical arguments,
> > but I have a more basic question: What exactly are you trying to
> > accomplish?
>
> I doubt that the almost-undocumented source code for V0.01 of "Yet Another
> Dungeon Simulator", linked from http://www.zaimoni.com/zaiband/yads.htm , will
> be illuminating.
That should read "Yet Another Duel Simulator" (webpage has it right).
The Wicked Flea
> Kenneth 'Bessarion' Boyd <zaim...@zaimoni.com> writes:
> > I just know that when I last looked at LISP (early 1990's), all of the
> > LISP tutorials available were emphatic that LISP's only data structure
> > was the list. No mention of arrays at all.
>
> I can believe that. Lisp teaching seems to be a little lacking sometimes.
evaluating the language. Though I prefer Object Pascal to other
languages,
_Practical Common Lisp_ by Peter Siebel is one of the better
programming
books I've ever read. For one thing, he cites everything, shows the
REPL,
and manages to get you to understand it all at once. And he doesn't
have
that horrible style in books like the "head first" stuff from
O'Reilly.
As to your questions about arrays and lists, Kenneth, chapter 11
covers
collections. So you can make your "(make-array 5 :initial-element
nil)"
whenever you want.
If you would prefer to read the book online, as opposed to buying it,
the
author has kindly made it available for free online in its entirety.
I
hope this helps you make your decision and to facilitate your learning
of
LISP, if that is your choice.
Practical Common Lisp: http://www.gigamonkeys.com/book/
Chapter 11, Collections: http://www.gigamonkeys.com/book/collections.html
- Flea
Chris Morris
> directory, then try moving the files to their correct location on my
> system with a complete audit trail.
>
> This did not work: kayac was built to require a DLL that wasn't
> shipped in the archive. No doubt the DLL would have been there if I
> used the standard *.EXE installers for MingW32 and MSYS, but both
> are broken when trying to clean-install on Win95. (I maintain
> comparable installs on all of Win95, Win2000, and Vista; if one
> updates, all must update the same way.)
I have no idea if kayac would work on Win95 at all. The only Windows
OS I have development access to is XP. Which DLL, incidentally?
--
Chris
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd writes:
> > What I actually tried was unpacking the ZIP archive to a separate
> > directory, then try moving the files to their correct location on my
> > system with a complete audit trail.
> >
> > This did not work: kayac was built to require a DLL that wasn't
> > shipped in the archive. No doubt the DLL would have been there if I
> > used the standard *.EXE installers for MingW32 and MSYS, but both
> > are broken when trying to clean-install on Win95. (I maintain
> > comparable installs on all of Win95, Win2000, and Vista; if one
> > updates, all must update the same way.)
>
> I have no idea if kayac would work on Win95 at all. The only Windows
> OS I have development access to is XP.
I'm pretty sure it would if built from source. MingW32-built executables tend
to run on all versions of 32-bit Windows equally well, as long as you're careful
to avoid using constants not defined in in Win95. The failure of Vista to print
some unprintable code points (127/ESC), which complicates *band development, is
the exception rather than the rule.
[E.g., if you wanted to use the OS function for loading BMPs to load JPEGs or
PNGs, then you'd have a dependency.] I generally statically link everything I
build that's legal to, as I'm willing to pay in executable size for
convenience.
> Which DLL, incidentally?
I merely verified that the install instructions cannot be stripped down;
suggesting that the binary distribution be revised is inappropriate. The
reported missing DLL is readline-5.dll . I wouldn't assume this is the only one
missing (windows stops the program on the first missing DLL), and there is no
suggestion the binary release needs fixing; I merely verified that the
instructions cannot be stripped down.
I'm pretty sure this does ship with the full executable installers, so the
problem is my exotic setup.
Chris Morris
>
> I'm pretty sure this does ship with the full executable installers, so the
> problem is my exotic setup.
I thought it did, but I just re-ran the install in an empty directory
and it wasn't there. It seems to have come from the mingwPORT readline
package.
> I merely verified that the install instructions cannot be stripped
> down; suggesting that the binary distribution be revised is
> inappropriate. The reported missing DLL is readline-5.dll .
Looking at it, it does seem like the basic MinGW/MSys packages don't
include it, so the distribution must. Thanks for your help with this -
it looks like I need to find a cleaner system to test the distribution
on.
--
Chris
Paul Donnelly
> On Mar 29, 7:39 pm, Paul Donnelly <paul-donne...@sbcglobal.net> wrote:
>> Kenneth 'Bessarion' Boyd <zaim...@zaimoni.com> writes:
>> > I just know that when I last looked at LISP (early 1990's), all of the
>> > LISP tutorials available were emphatic that LISP's only data structure
>> > was the list. No mention of arrays at all.
>>
>> I can believe that. Lisp teaching seems to be a little lacking sometimes.
> Let me refer the two of you to the Lisp book I bought when initially
> evaluating the language. Though I prefer Object Pascal to other
> languages, _Practical Common Lisp_ by Peter Siebel is one of the
> better programming books I've ever read. For one thing, he cites
> everything, shows the REPL, and manages to get you to understand it
> all at once. And he doesn't have that horrible style in books like
> the "head first" stuff from O'Reilly.
PCL is a good book. I recommend it too.
Gerry Quinn
Best just to stay away from both and learn the language naturally :-)
- Gerry Quinn
Paul Donnelly
> In article <fsjmju$1oa6$1...@news.vol.cz>, zai...@zaimoni.com says...
> Kenneth 'Bessarion' Boyd writes:
>>
>> Said manual was *not* available at the time, obviously. There's a
>> reason why I like to have full language specifications when
>> self-teaching programming languages; the real textbooks have way too
>> much misinformation.
>
> Best just to stay away from both and learn the language naturally :-)
So *you're* the reason newbies show up on comp.lang.lisp asking
questions about things that are clearly expressed in the Hyperspec. ;)