Andrzej Lewandowski <lewandoREM...@attglobal.net> writes: > > On Sun, 11 Nov 2001 20:43:31 GMT, Gabe Garza <g_ga...@ix.netcom.com> wrote:
> > Have you looked at LispWorks from Xanalys (www.xanalys.com)? Their > >"Enterprise Edition" comes with an embedded prolog interpreter that can > >use either a Lisp'ish or traditional prolog syntax. Might give you the > >best of both worlds. > This is not what I am looking for. I would like to replace Prolog by > LISP, but not bring one more language to the organization. Moreover, > I am not using just-a-Prolog. I am using Prolog that has built-in > constraint solver (CLP(fd), strictly speaking), and currently there > are 5 such Prologs on the market. This what Xanalys has doesn't > belong to this category.
Unless you want a transitional solution instead of an overnight one.
Honestly, you say in another post that you don't want to pay more than for another language. A language is a packaged commodity tool, it is not a custom tool to a specific business need.
Yet you have a very specific list of constraints that are your personal business constraints and that don't match the constraints of anyone else I've heard post here, nor met in real life.
The commercial world does not work this way generally. It packages things in a way it thinks will sell well to a lot of people. When people don't like those configurations, they pay more. When they insist on both getting more and paying less, they get nothing.
I hope if you finally get the constriant solver and you plug this query into it, it will help you to understand why people are sounding snippy. The problem sounds overconstrained to me, and they are expressing what I consider to be frustration at that after having each (myself included) volunteered a bit of their personal time to hearing you and trying to make good-faith suggestions. Personally, I'm not going to beat my head against the wall further on it. I've read the other posts on this thread and can see I'm not going to be able to make you happy, so I will decline to trouble you further by trying. I do wish you luck though.
>| Expert systems, yes. What regards constraint solvers, there is >| one named Screamer, but it is academic project abandoned in 1994
>Perhaps you should tell that to the authors, too; they might not be >aware that they have abandoned the project. The latest version >(which I got from the other author (Siskind) about two months ago) >I have mentions 1997 and I don't recall him mentioning that it is >abandoned.
>| (and it seems, never finished). I am looking for commercially >| supported stuff.
>I take it that asking whether the authors might be willing to sell >you commercial support is out of the question? On second thought, >if you ask them, I'd advice you not to tell your silly assumptions >about their "abandoned project" to them as truths.
>*plonk*
All links about Screamer lead to the following page
that was updated last time June 7, 1994. This is the official Screamer distribution, with manual that is partially completed with some sections consisting only of section headers. This is version 3.20. After close inspection of the code you will find long list of bugs and "things to do". This fits my definition of "abandoned" project.
If you know about any other distribution/publications that are after the above date, please let me know.
>| Expert systems, yes. What regards constraint solvers, there is >| one named Screamer, but it is academic project abandoned in 1994
>Perhaps you should tell that to the authors, too; they might not be >aware that they have abandoned the project. The latest version >(which I got from the other author (Siskind) about two months ago) >I have mentions 1997 and I don't recall him mentioning that it is >abandoned.
Ach... By the way, if you go to mark Siskind's web page
go to Software section, then you will find link (on the very bottom) to the "Screamer resource page" dated June 7, 1994. It is also possible to click on link "Screamer", download the stuff, unzip, and read the following lines:
;;; Screamer ;;; A portable efficient implementation of nondeterministic CommonLisp ;;; Version 3.20
In article <sfw668h3wsy....@shell01.TheWorld.com>, Kent M Pitman wrote: > The immortal spirit of Jack the Ripper gets into the computer, and > Spock tells the computer to "compute to the last digit, the value of > pi"... He made it a class 1 priority directive to assure that the > the computer would turn bank after bank to the problem, squeezing out > the bad guy, who is presumably not smart enough to hide in the area > that has life support and will (hopefully) be last to go.
Thanks for refreshing my memory. Yes, it makes plots much easier to manipulate if characters don't always act "reasonably."
I understand that Lisp can support arbitrary precision. My initial post about lack of infinite precision irrational functions was sparked in the gap be evaluation (zerop (1+ (exp (complex 0 pi)))) and getting NIL and then me realizing precision limitations.
Kevin Rosenberg <ke...@rosenberg.net> writes: > Thanks for refreshing my memory. Yes, it makes plots much easier to > manipulate if characters don't always act "reasonably."
> I understand that Lisp can support arbitrary precision. My initial post about > lack of infinite precision irrational functions was sparked in the gap be > evaluation > (zerop (1+ (exp (complex 0 pi)))) > and getting NIL and then me realizing precision limitations.
I believe Macsyma and other such systems employ some sort of fuzz parameter that is used for fixing this according to advice from users. MACLISP for the PDP10 (but not Multics, sigh--typical of MACLISP) even did some of this (not for complexes, but for floats) primitively through a variable called ZFUZZ (default NIL) defined as: "If this variable's value is not NIL, then PLUS and DIFFERENCE perform a special fuzz check on floating point numbers. If x and y are the numbers to be added (possibly after contagious conversion to floating point), then if x + y < y * ZFUZZ then the result is forced to zero." I'm not sure what the success rate was with this; perhaps the fact that it got left behind in MACLISP and not moved along into CL says it was a failure. (JonL White's not out there lurking is he? He'd probably know.)
* Andrzej Lewandowski <lewandoREM...@attglobal.net> | What do you know about my experience?...
What you told me, of course, which was more than sufficient to comment on your statement, but if you _really_ want to quibble and defend yourself, instead of supporting your claims, which at least could be interesting, please do it elsewhere, OK?
/// -- Norway is now run by a priest from the fundamentalist Christian People's Party, the fifth largest party representing one eighth of the electorate. -- Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
Thanks for the replies everyone. I will look into all that. I wish "On Lisp" was still in print! I really want to read that. A book with some philosophical and historical depth would be good right about now.
In article <sfw7kswu2n4....@shell01.TheWorld.com>, Kent M Pitman wrote: > I believe Macsyma and other such systems employ some sort of fuzz > parameter that is used for fixing this according to advice from users. > MACLISP for the PDP10 (but not Multics, sigh--typical of MACLISP) even > did some of this (not for complexes, but for floats) primitively > through a variable called ZFUZZ (default NIL) defined as: "If this > variable's value is not NIL, then PLUS and DIFFERENCE perform a > special fuzz check on floating point numbers. If x and y are the > numbers to be added (possibly after contagious conversion to floating > point), then if x + y < y * ZFUZZ then the result is forced to zero." > I'm not sure what the success rate was with this; perhaps the fact that > it got left behind in MACLISP and not moved along into CL says it > was a failure. (JonL White's not out there lurking is he? He'd > probably know.)
As always, I appreciate your insight steeped with experience and history.
For a persistent Lisp database that I am writing under contract, I need to compare two double-floats for equality. In a testing section, I compare a double-float after storage in a 8-byte floating point SQL field with the original Lisp double-float.
I found that (< (/ (abs (- f1 f2)) f1) (* 10 double-float-epsilon)) as test of equality works well in this application.
In article <sfwpu6pcvea....@shell01.TheWorld.com>, "Kent M Pitman"
<pit...@world.std.com> wrote: > Kevin Rosenberg <ke...@rosenberg.net> writes:
>> In article <slrn9urrnn.53h.ke...@boa.b9.com>, Kevin Rosenberg wrote: >> > Unfortunately, besides leaving out if* (sorry!), the ANSI standard >> > forgot to require infinite precision real arithmetic ;-)
>> Oops, I need to retract that thought. If the standard did require >> infinite precision arithmetic, implementations of ANSI CL may fit the >> myth of Lisp being "slow".
> Don't forget arbitrary-precision rationals. Once you're not in a > machine word any more, the only difference between rationals and floats > is that floats have gaps in their space and rationals don't...
Yeah like that rational that you can square to equal 2.
Andrzej Lewandowski <lewandoREM...@attglobal.net> wrote: > Finally, maybe somebody would give me at least one good reason (other > than "because I like it") why LISP should be used instead of one of > the above mentioned languages.
Emacs is a very good reason. I work in the telecom field, populated by network elements that spits files of different formats that are customized to suit the services provided by the operators. To view what's inside these files, rather than write a nice tool with Java/C/C++ to display the stuff, I use Emacs to parse and display the contents.
What's great is that people can customize the output according to their needs without touching the core program and, better, I didn't even have to think about how to let people customize the stuff because they can overwrite functions and variables at will.
Now, all people in my department use Emacs to view these files and don't have too much trouble customizing it to suit their needs, without knowing Lisp ! Even better, our customers use it as well... I mean, when they see things like:
they don't have too much trouble figuring how to customize it...
With C or whatever, I'd have to set up a whole framework (with issues such as: "parse the configuration file with ultra strict syntax otherwise coredump", "I need some new functionalities, could you please add it in your program?", "oh, I didn't know there should be no space after the = sign !", etc...) to have something like this and it would not as flexible as with Lisp (if yes, then congratulations, you have implemented a new Lisp).
Also, as it's Emacs, when people want to display one file, they use dired-mode, where a key is bound to do the parse/display thing and when displayed, they can do copy/paste, search, ..., whatever, without extra work for me. And yes, no horrible things such as:
$ parse-cdr cdr-file1 > cdr-output1 $ vi cdr-output1
(quit vi)
$ parse-cdr cdr-file2 > cdr-output2 $ vi cdr-output2
For batch processing, I use the same approach with Common Lisp and the configuration file is populated by CLOS individual methods such as:
(defmethod output ((tag (eql 50004)) list) ... )
If I wanted, I could use Common Lisp for both (viewer and batch), where Emacs would use the CL program in the background. Then, there would be 2 generic functions: output-batch and output-view, or maybe one (output) with an extra parameter that would be either 'batch or 'view. -- Georges Ko (Taipei, Taiwan) 2001-11-12 g...@gko.net / ICQ: 8719684 Lundi 12 novembre 2001
Andrzej Lewandowski <lewandoREM...@attglobal.net> writes:
> Technical decision in the industry are not based on "trust" or personal opinions of > this-or-that developer. Developers don't decide about programming languages unless this > is single person, basement-type operation.
That statement is, quite simply, false. Demonstrably so, by counter example.
-- It would be difficult to construe Larry Wall, in article this as a feature. <1995May29.062427.3...@netlabs.com>
> Andrzej Lewandowski <lewandoREM...@attglobal.net> writes:
> > We are currently using Prolog, but Prolog (despite its obvious > > advantages) has obvious disadvantages. One is that it is pretty hard > > (well... inconvenient) to write parts of the algorithm that have > > purely procedural character. Since we are extending the product > > lines, one obvious question is whether it would be reasonable and > > justified to use something else instead of Prolog. LISP definitely > > is the alternative, but... I have posted a qeustion about constraint > > solver for LISP - it seems that nothing is available.
> Harlequin (now Xanalys) used to have an integrated Lisp/Prolog > environment, I think. I don't know if it still does.
Just for the record. It is still there.
> I'm sure there are expert system shells and constraint solvers written in > Lisp.
> Anyway, I want to make regular user apps with windows, dialogs, > animation, the whole bit. My question is, is there a certain > GUI library/Lisp environment that I should be looking into that > would be good for cross-platform programming, esp. for future > OS's, like when 64-bit becomes mainstream?
Well I'm biased, so take it with some pounds of salt. Every commercial Lisp comes with support for that kind of programming. As I understand the quasi standard for that GUI stuff is CLIM. Well it was told me from the Xanalys side that most of their customers do use CAPI. In my opinion LispWorks offers a very good environment and I'm using it.
>I don't want to > write software that will become obsolete in 10 or 20 years, if > I can avoid it.
Well I guess the "kernel" will be still around. But I guess a lot of software is "re-written" at some point. That is a guess!
> IOW, is there a library that is considered by the Lisp community > as the standard with which to program GUI apps?
> Anyway, I'm excited about Lisp. It is fascinating how it maps > computer language so cleanly with the English language. Even > if it doesn't fulfill my every requirement, I will probably > learn it anyway.
I sugget looking at LispWorks it runs on Windows as it does on Linux. You can try out there personal edition visit http://www.xanalys.com
"Daniel Lakeland" <dlake...@sil-no.spam-con.com> writes: > In article <sfwpu6pcvea....@shell01.TheWorld.com>, "Kent M Pitman" > <pit...@world.std.com> wrote:
> > Don't forget arbitrary-precision rationals. Once you're not in a > > machine word any more, the only difference between rationals and floats > > is that floats have gaps in their space and rationals don't...
> Yeah like that rational that you can square to equal 2. ;-)
I know this was said with a smiley, but...
Arbitrary precision floats are going to fix this?
The secret truth is that floats ARE rationals. They are not reals. They have a numerator and a denominator (sort of) but the number of bits of precision in the numerator is irregular, leading to an oddly shaped space. The real rational space, by which I mean the authentic rational space, is better than this irregularly shaped space where the FLOAT type doesn't have room to represent something. Floats' primary value is for machine word computations, as I understand it, and their value goes down a lot after that.
Macsyma has something called bigfloats that are similar to bignums, except they are maintained to a specified precision (rather than growing to different precision as computations progress). They're represented by some integers that include numerator/denominator information plus hidden bits and also some explicit precision information.
I remember about 20 years ago, at some Symbolic Algebra conference I went to, back when I did that kind of thing, the guys at the Soft Warehouse (Al Rich, who did MuLisp and David Stoutemeyer, who did MuMath) were talking about making an actual "real" datatype, different from rationals, for use in MuMath, their symbolic algebra tool. I don't know if they ever did this, but it might be fun for someone to find out. (Not me, I'm too busy with other things...)
>>>>> On 12 Nov 2001 18:27:37 +1100, Alain Picard ("Alain") writes:
Alain> Andrzej Lewandowski <lewandoREM...@attglobal.net> writes: >> Technical decision in the industry are not based on "trust" or personal opinions of >> this-or-that developer. Developers don't decide about programming languages unless this >> is single person, basement-type operation.
Alain> That statement is, quite simply, false. Demonstrably so, by counter example.
At most companies I've been at (whether 10 person or 10,000 person), for substantial projects, the decision about programming languages (and other technologies, such as which quarter-million-dollar database to use, which platforms to deliver on, etc.) is usually made by a high-level manager, perhaps the vice president of technology. This person is usually not the developer who will write the software. The three equal major factors are: (1) is this a reliable technology we can bet the future of the company on, (2) are there multiple vendors of this technology, from companies that are at least as stable as we are, and (3) will we be able to hire programmers to develop and maintain this system. Different people in different situations with different backgrounds and information will have different evaluations,
> The secret truth is that floats ARE rationals. They are not reals. > They have a numerator and a denominator (sort of) but the number of bits > of precision in the numerator is irregular, leading to an oddly shaped > space.
..not to mention that the denominator is always a power of a fixed base (usually 2 these days...) - resulting in another set of holes wrt the full space of rational numbers.
Matt Gregory <msgreg...@nospam.com> writes: > Thanks for the replies everyone. I will look into all that. I wish > "On Lisp" was still in print! I really want to read that. A book > with some philosophical and historical depth would be good right > about now.
Then get PAIP, i.e. Norvig's "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp". I've never understood the fuss about On Lisp; PAIP seems to be similar in scope and better (and still in print, I think).
Cheers, M.
-- Q: What are 1000 lawyers at the bottom of the ocean? A: A good start. (A lawyer told me this joke.) -- Michael Ströder, comp.lang.python
>> Harlequin (now Xanalys) used to have an integrated Lisp/Prolog >> environment, I think. I don't know if it still does. >Just for the record. It is still there.
>> I'm sure there are expert system shells and constraint solvers written in >> Lisp.
On Mon, 12 Nov 2001 03:07:46 GMT, Erik Naggum <e...@naggum.net> wrote: >* Andrzej Lewandowski <lewandoREM...@attglobal.net> >| What do you know about my experience?...
> What you told me, of course, which was more than sufficient to comment on > your statement, but if you _really_ want to quibble and defend yourself, > instead of supporting your claims, which at least could be interesting, > please do it elsewhere, OK?
It instead technical argument you prefer personal ones, then please, do this elsewhere.
Gabe Garza <g_ga...@ix.netcom.com> writes: > If you have the time, could you explain the differences between > updating a running Erlang program and updating a Lisp system? I'd > be very interested...
In Erlang it works as follows. Threads typically keep themselves alive by making tail calls, so a simple process f will basically look like
f(A,B,C) :- do_something f(NewA, NewB, NewC)
where NewA, NewB and NewC are the new values for the state variables A, B and C. If f resides in module m, one can write the tail call alternatively as
m:f(NewA, NewB, NewC)
This will call f as defined in the latest version of m. One can thus update a server by loading in a new version of the module where it is defined. If memory serves right, there can be two versions of a module at any given time, the "old" and the "new" version, and the old one can be purged once it is no longer being executed. -- Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
> The secret truth is that floats ARE rationals. They are not reals. > They have a numerator and a denominator (sort of) but the number of bits > of precision in the numerator is irregular, leading to an oddly shaped > space. The real rational space, by which I mean the authentic > rational space, is better than this irregularly shaped space > where the FLOAT type doesn't have room to represent something. Floats' > primary value is for machine word computations, as I understand it, and > their value goes down a lot after that.
This is an interesting thread. Could you explain what you mean by machine word computations?
> > The secret truth is that floats ARE rationals. They are not reals. > > They have a numerator and a denominator (sort of) but the number of bits > > of precision in the numerator is irregular, leading to an oddly shaped > > space.
> ..not to mention that the denominator is always a power of a fixed > base (usually 2 these days...) - resulting in another set of holes > wrt the full space of rational numbers.
It's ironic, isn't it, that US stock markets now use decimals because we're in the computer age, and decimals are more accurate than those silly old 1/8's. Oops.
