>> >> >> I'm surprised people are surprised that Lisp isn't used at JPL [1]. >> >> >> It wouldn't even prevent you from dividing an int by a string in >> >> >> some branch of code!
>> >> > Lisp was used at JPL for decades (and it's actually still in use in >> >> > at least one fielded application, though there's currently no active >> >> > Lisp >> >> > development to my knowledge). The reason it fell out of favor had >> >> > absolutely nothing to do with typing, or any other techincal reason; >> >> > it was purely political.
>> >> Did you "lose your faith" for political reasons too?
>> >> Oleg
>> > Hm, seems Nils was right about you. You really are just a troll.
>> Don't like it when people point out holes in your story? Stop being a >> baby.
> I have no problems with someone pointing out holes in my story, but that's > not what you did. You didn't point anything out. You asked a question, > which was at once ad-hominem and non-sequitur. (And then you followed up > with another ad-hominem attack.) That's what trolls do.
> If you want to point out a "hole in my story" I welcome that, but there > aren't any holes because what I said is true. In fact I can document my > claim in excruciating detail. Unlike many political processes, this one > actually played itself out in public view. There were numerous witnesses > to all the key events.
1) you stated that JPL ditched Lisp for political reasons 2) you stated that you "lost your faith" in Lisp [for technical reasons, it seemed]
I reminded you of "2" and you got sensitive like a little boy and started "calling names".
If you "lost your faith" for reasons other than technical or political, then I'd like to know how you _classify_ them (without going into long-winded Noggum-style diatribes please)
Oleg
P.S. Not that JPL is worth looking up to. After all, they hired Mr. Tisdale http://groups.google.com/groups?q=tisdale+troll&btnG=Search&meta=site... The man was trolling C++ groups for decades trying to push his C++ linear algebra standard onto people who, unlike him actually KNOW linear algebra, and asking childish questions in sci.astro.
* Alexander Schmolck | As an aside: although what I know about CL's way of dealing with numbers seems | rather sensible to me (promoting to a more general type iff necessary), many | people are apparently uneasy about the idea that the result type can depend on | the parameter values (rather than type).
What do you mean, the type depends on the parameters? The result type of a division of integers is a rational number. Now, remember your mathematics: an integer is a rational number. Only if you think an object is of only one type could you become confused about this. The beauty of the Common Lisp numeric tower is that numbers satisfy several type predicates.
| I'd be interested to hear from the experience of lisp users whether lisp's | way of promoting numbers actually causes problems in practice.
But they are /not/ promoted! An integer is a specialized form of a rational. I mean, you can even evaluate (denominator 11) and get 1.
| Also, is there one overarching reason why rationals aren't complex?
Huh? This is such a confused question. The mathematical background of the Common Lisp numeric tower is reason enough. If you want complex numbers with a rational number for the real and imaginary part, you got it. I do not understand what the question would otherwise mean.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Centuries ago, Nostradamus foresaw when Erik Naggum <e...@naggum.no> would write:
> * Greg Menke > | Try to do some accounting software in C.
> * Bruce Hoult > | IEEE double precision floating point is perfectly fine for that purpose
> Wrong answer. I cannot /believe/ that people still think floating point is > usable for accounting purposes. Nothing really beats binary coded decimal > for this kind of tasks. Realizing that should be part of your education as > a programmer.
.. And this is why COBOL persists, to this day, despite how much people despise it.
COBOL has, as the essential numeric data type, what amounts to BCD.
Is it fabulously efficient? Well, consider that IBM has been tuning hardware to do BCD stuff for probably 40 years. And that the old Z-80 CPU had BCD instructions. As did M68K and 80x86.
It's doubtless a LOT simpler to get a verified-to-be-correct BCD arithmetic unit than is the case for FP, and I'd be willing to bet that BCD takes up a _whopping_ lot less hardware than does FP.
You don't need to do a lot of numerical analysis to be _certain_ that BCD ops are doing the right thing.
Hmm. I wonder if anyone has ever implemented BIGNUMs in Lisp using BCD. (The evident fly in the ointment would be base conversions.)
In a "BCD world," instead of having DSP-like instructions do do funky and/or/xor/... operations, you might wind up with instructions specifically intended to do arbitrary-precision BCD ops with parameterized lengths... -- (concatenate 'string "cbbrowne" "@ntlug.org") http://www.ntlug.org/~cbbrowne/nonrdbms.html To quote from a friend's conference talk: "they told me that their network was physically secure, so I asked them `then what's with all these do-not-leave-valuables-in-your-desk signs?'". -- Henry Spencer
Erik Naggum <e...@naggum.no> writes: > * Alexander Schmolck > | Also, is there one overarching reason why rationals aren't complex?
> Huh? This is such a confused question. The mathematical background of the > Common Lisp numeric tower is reason enough. If you want complex numbers > with a rational number for the real and imaginary part, you got it. I do not > understand what the question would otherwise mean.
My interpretation of the question was "why does (TYPEP 1/2 'COMPLEX) not return T?", coming from the view of the real numbers as a line in the complex plane.
It's not a priori obvious why this decision was taken, I think, as it blurs the distinction slightly between existence and representation; that's not to say that I think the wrong decision was taken, of course.
* Christophe Rhodes | It's not a priori obvious why this decision was taken, I think, as it blurs | the distinction slightly between existence and representation; that's not to | say that I think the wrong decision was taken, of course.
The decision was not taken by Common Lisp, but by mathematicians long before there were programming languages and representations. If you plan to work with complex numbers, knowing their history seems like a very good idea to me.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Christopher Browne <cbbro...@acm.org> writes: > Hmm. I wonder if anyone has ever implemented BIGNUMs in Lisp using > BCD. (The evident fly in the ointment would be base conversions.)
I once implemented FIXNUMs in a toy lisp this way. FIXNUMs were 12 BCD digits, six to the left of the decimal point, six to the right.
> > (defmacro do-combinations (syms list &rest body) > > (labels ((work (syms x) > > (let ((y (gensym))) > > (if (cdr syms) > > `(loop as (,(car syms) . ,y) on ,x > > do ,(work (cdr syms) y)) > > `(loop as ,(car syms) in ,x do ,@body))))) > > (work syms list)))
> I'm sorry, this only rivals /usr/include/g++-3/stl_function.h in > readability. No it's worse. I don't even know which tokens are variables > and which ones are keywords. Perhaps it's a good thing there are no > templates, err... I mean macros, in O'Caml.
Well, if you will delete all the indentation, you should expect to get unreadable code. You'll find that deleting all the inessential whitespace and running it all together in a single line works even better.
Obviously Lisp code is hard to read if you aren't familiar with Lisp. And C++ code is hard to read if you aren't familiar with C++. And both can be hard to read even if you *are* familiar with the language, because both languages (C++ more rarely than CL) allow you to pack a lot of meaning into a small volume of code.
But your comparison is quite an appropriate one. Macro definitions are allowed to be ugly, just as the headers for the C++ standard library are allowed to be ugly. They are ugly so that your code can be beautiful. As it happens, I think the DO-COMBINATIONS macro is not difficult to read at all, but it wouldn't matter all that much if it were as ugly and unreadable as you say it is.
-- Gareth McCaughan Gareth.McCaug...@pobox.com .sig under construc
* Gareth McCaughan | They are ugly so that your code can be beautiful.
This is a frequently misunderstood point. A lot of programmers who get transfixed by some blinding elegance never understand that what they have to work with is elegant because a lot of the dirty details have been wiped under the carpet. They sort of get this requirement that from this point onward, /all/ code must be "elegant". I have come to believe that elegance, to be achieved where it did not previously exist, you must do a lot of hard, dirty work. The simpler and more elegant you want the abstraction to be, the more time and effort you must expend on its fundamentals and its implementation.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
* oleg inconnu wrote: > If it doesn't take any arguments, than it's not a function. You > should have stayed in school, kid.
If its type is a subtype of FUNCTION then it's a function. This is a Lisp newsgroup, not a mathematics one, or for that matter an ML one. It's also far from the only Lisp function that takes no arguments.
[Erik, writing about the int/int->int problem some languages have:]
> > > This kind of bug is a consequence of strong typing and thus > > > must be caught by the strongly-typed system that introduced it.
[me:]
> > I think "consequence" is a bit strong. The Python language[1] > > is dynamically typed, but it has the int/int -> int "feature".
> > It's probably true that only a static typing system can > > *excuse* -- as opposed to *explain* -- making integer > > division yield integers.
[Ray:]
> This has nothing to do with static typing per se.
> The issue is that the languages that give only int/int->int simply do not also > have int/int->real. That is, they have the "wrong" set of built-in functions, > as opposed to the fact the function usage is statically checked.
I agree that static typing doesn't cause the problem. (That was my point.) What I meant by "only a static typing system can excuse, etc" was that if you must have int/int -> int, then you'd better also have static typing, because at least then you can pretend that you just have two different "/" operators and the language does something a bit like type inference to work out which one you want. Whereas, in a dynamically typed language, what happens is that you get two completely different behaviours selected between at runtime, arbitrarily unpredictably. That feels really wrong.
Even in statically typed languages, I'd be happier if "/" didn't mean "divide and convert to integer". But that usage sits more comfortably in C than it does in Python; more comfortably in ML than it would in CL.
> A language that had the equivalent of CL's numeric tower could still be > readily statically typed. There would be nothing stopping one from using the > equivalent of "arbitrary number" all over the place, and using explicit > truncates at those places where one is sure an int is needed.
Of course.
> In particular int/int->int need not exist, allowing static typing to actually > prevent these accidental errors. I.e. you would have to do it on purpose:
> (truncate (/ x y))
Of course.
At this point, I typed: "But if you do that, you should in fact do what CL does, providing one division-yielding-integer function for each form of real->integer conversion." But, on reflection, maybe that's wrong. It doesn't take an especially smart compiler to avoid consing up a rational when the next thing it's going to do is truncate it or turn it into a float, writing the expression out fully only costs a few extra characters, and -- as the Python folks like to put it -- "Explicit is better than implicit". (That maxim can be an excuse for clunkiness, but I don't think there's anything very clunky about *not* conflating division and real->int conversion.)
-- Gareth McCaughan Gareth.McCaug...@pobox.com .sig under construc
In article <alqpi9$ft...@newsmaster.cc.columbia.edu>, Oleg
<oleg_inco...@myrealbox.com> wrote: > 1) you stated that JPL ditched Lisp for political reasons
Yes.
> 2) you stated that you "lost your faith" in Lisp [for technical reasons, it > seemed]
Not in this discussion I didn't. You are apparently making an oblique reference to an article I posted here a very long time ago, but which you apparently only read the title and not the body. The "faith" to which I was referring to in that article has nothing to do with the topic at hand. (There are many reasons for this, but the most glaringly obvious one is that at the time that I "lost my faith" I wasn't working at JPL. Duh!)
> I reminded you of "2" and you got sensitive like a little boy and started > "calling names".
I'm laughing too hard to frame a response to that.
> If you "lost your faith" for reasons other than technical or political, > then I'd like to know how you _classify_ them (without going into > long-winded Noggum-style diatribes please)
These questions are answered at length in the article to which you allude and I see no reason to repeat myself, particularly since my personal views are absolutely irrelevant what is under disucssion here.
Let's review. You wrote:
> I'm surprised people are surprised that Lisp isn't used at JPL [1]. > It wouldn't even prevent you from dividing an int by a string in > some branch of code!
Once you dig through the double negatives one infers that you believe 1) JPL doesn't use Lisp, 2) people are surprised by this and 3) they should not be.
(This leaves open to interpretation the question of whether you believe JPL is a good example or a bad one, though you do clarify this in your most recent post:
> P.S. Not that JPL is worth looking up to. After all, they hired Mr. Tisdale
How the hiring of a single person ought to reflect on an institution with more than six thousand employees is open to dispute, but be that as it may...)
All I am saying is that you are factually incorrect in your first implied statement: JPL *does* use Lisp (or did), so whether people are surprised by the "fact" that JPL doesn't is irrelevant, because JPL does.
E.
P.S. Your claim that Lisp "wouldn't even prevent you from dividing an int by a string in some branch of code" is also wrong.
>> Hmm. I wonder if anyone has ever implemented BIGNUMs in Lisp using >> BCD. (The evident fly in the ointment would be base conversions.) > I once implemented FIXNUMs in a toy lisp this way. FIXNUMs were 12 > BCD digits, six to the left of the decimal point, six to the right.
Interesting...
That has the feeling of not being totally ANSI compliant, and it's certainly not what people would usually _expect_... :-)
How was performance? / Was this coded using native BCD operators? -- (concatenate 'string "aa454" "@freenet.carleton.ca") http://cbbrowne.com/info/languages.html "The problem might possibly be to do with the fact that asm code written for the x86 environment is, on other platforms, about as much use as a pork pie at a Jewish wedding."- Andrew Gierth in comp.unix.programmer
Erann Gat wrote: >> I'm surprised people are surprised that Lisp isn't used at JPL [1]. >> It wouldn't even prevent you from dividing an int by a string in >> some branch of code!
> Once you dig through the double negatives one infers that you believe 1) > JPL doesn't use Lisp, 2) people are surprised by this and 3) they should > not be.
There are no double negatives there. Learn to count.
>>>>>>>I'm surprised people are surprised that Lisp isn't used at JPL [1]. >>>>>>>It wouldn't even prevent you from dividing an int by a string in >>>>>>>some branch of code!
>>>>>>Lisp was used at JPL for decades (and it's actually still in use in >>>>>>at least one fielded application, though there's currently no active >>>>>>Lisp >>>>>>development to my knowledge). The reason it fell out of favor had >>>>>>absolutely nothing to do with typing, or any other techincal reason; >>>>>>it was purely political.
>>>>>Did you "lose your faith" for political reasons too?
>>>>>Oleg
>>>>Hm, seems Nils was right about you. You really are just a troll.
>>>Don't like it when people point out holes in your story? Stop being a >>>baby.
>>I have no problems with someone pointing out holes in my story, but that's >>not what you did. You didn't point anything out. You asked a question, >>which was at once ad-hominem and non-sequitur. (And then you followed up >>with another ad-hominem attack.) That's what trolls do.
>>If you want to point out a "hole in my story" I welcome that, but there >>aren't any holes because what I said is true. In fact I can document my >>claim in excruciating detail. Unlike many political processes, this one >>actually played itself out in public view. There were numerous witnesses >>to all the key events.
> 1) you stated that JPL ditched Lisp for political reasons > 2) you stated that you "lost your faith" in Lisp [for technical reasons, it > seemed]
This might be hard for you to understand and I am probably just wasting bandwidth on you. JPL ditching Lisp and Erann Gat Loosing faith in Lisp does not necessarily have anything to do with each other.
It is you who get defensive as a little child, by bringing up bygones and irrelevant material.
* Gareth McCaughan | I agree that static typing doesn't cause the problem. (That was my point.)
I think my point has been muddled. When I said that this (/ int int) -> int is /a consequence of/ static typing, that does not mean that it is not also a consequence of more factors. It means that if you choose static typing, you will also make this kind of design choice. In particular, if you choose types that are close to the machine, (/ int int) -> int is the obvious choice because the hardware that you have chosen to model does precisely that.
If, however, you think in mathematical terms, you do not have (/ int int) to begin with, you have (/ number number), and the result is of type number, but this would not aid efficiency at all! Since better efficiency is a goal of the application of most type theories, a type systems that do not consider all (numeric) types disjoint are basically worthless.
* Ray Blaak | (truncate (/ x y))
* Gareth McCaughan | Of course.
Pardon me, but (truncate (/ x y)) is stupid when (truncate x y) expresses the operation better and even returns the two values that machine division instructions routinely produce instead of having to compute a new, second return value. Note the alternatives `floor´, `ceiling´, and `round´, as well.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
Oleg <oleg_inco...@myrealbox.com> writes: > Marco Antoniotti wrote:
> > let foo (x) = 3 + 3.14 + x;
> what if you wanted
> let foo x y = x / y
> How would you expect your "ideal compiler" for an "ideal language" to infer > type for this thing if operator overloading was allowed?
The behavior of Common Lisp is good enough for me. They are both numbers and the generic addition routine should be applied. If I need efficiency I add declarations. If I call foo with a string CMUCL/Python will type infer that that is not kosher and will tel me.
> When I started using O'Caml, I was annoyed by this at first too, but later > on, I realized that the similarity between "/" and and "/." is purely > ad-hoc and that these operations are fundamentally different. I'd rather be > reminded to clarify my code than have the compiler assume things and do > implicit conversions.
That is your right. I have the right to be wanting the opposite.
Cheers
-- Marco Antoniotti ======================================================== NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th Floor fax +1 - 212 - 995 4122 New York, NY 10003, USA http://bioinformatics.cat.nyu.edu "Hello New York! We'll do what we can!" Bill Murray in `Ghostbusters'.
"Christopher Browne" <cbbro...@acm.org> wrote in message news:alr0dv$cvfl$1@ID-125932.news.dfncis.de... > In the last exciting episode, Joe Marshall <j...@ccs.neu.edu> wrote:: > > Christopher Browne <cbbro...@acm.org> writes:
> >> Hmm. I wonder if anyone has ever implemented BIGNUMs in Lisp using > >> BCD. (The evident fly in the ointment would be base conversions.)
> > I once implemented FIXNUMs in a toy lisp this way. FIXNUMs were 12 > > BCD digits, six to the left of the decimal point, six to the right.
> Interesting...
> That has the feeling of not being totally ANSI compliant, and it's > certainly not what people would usually _expect_... :-)
Fortunately, I didn't have to worry about ANSI compliance because I wrote it before X3J13.
> How was performance?
Not too bad, but nothing to write home about. The important thing was that a useful range of integers and fractions were representable without having to use floating point (which was hard to come by).
> Was this coded using native BCD operators?
Yes. The amusing thing was discovering that some odd and apparently useless opcodes were just the ticket for writing BCD code. I think one was `rotate nybble indirect and subtract' which would do a four bit shift between the accumulator and a memory location with a conditional decrement. For the life of me I couldn't understand why such an instruction existed until I implemented my BCD division routine.
On Wed, Sep 11, 2002 at 08:34:37PM +0200, o...@sivos.rl.no wrote: > Matthew Danish: > > Brittle materials are relatively strong, but when a force is applied > > from particular directions (or an unusually strong force is applied) > > they tend to experience extreme plastic deformation and failure. > > Ductile materials, on the other hand, tend to accept far more abuse > > while only deforming elastically (they return to their original > > shape).
> Hmm, I am very surprised.
> I once learned that a ductile material can take a lot of _plastic_ > deformation before fracturing. Plastic deformation does of course mean > that it does not at all return to its original shape once its ductile > property has been exploited. Gold is a very ductile material, it can > be squeezed leaf thin without fracturing.
I was thinking so much of failure that I neglected to mention the plastic deformation stage of ductile materials! Anyway, you are correct, though the main point of this paragraph was that brittle materials fracture quickly after excessive strain and ductile ones do not.
> Brittle materials fracture with no or very little plastic flow. Their > main characteristic is that they respond to increasing load with an > elastic deformation and then fracture. In contrast, ductile materials > respond with an elastic deformation, then plastic deformation and then > finally, fracture. In general; the more plastic deformation prior to > fracture, the more ductile. (This is a bit simplified, cross sectional > area reduction during the plastic flow plays a role here)
This is a better explanation.
> Brittle materials being releatively strong, may be a little > far fetched. They often show relative low tensile strength. The > compressive strength may however, be an order of magnitude higher.
This disparity is what I meant to express using the phrase "forces applied from particular directions".
> Brittle materials are often counted among the "hard" materials, > but hardness is a different and quite complex animal.
> > In small structures, where tight specifications are needed, the > > unyielding rigidity of brittle materials may prove useful.
> Rigidity (stiffness) is often a combination of elasticity and > geometry. Geometry may be more important than the material. In any > case, the Young's modulus is likely to be more important than the > ductility.
OTOH, many materials with large Young's modulus are also brittle. I'm no expert, but it would seem that a large jump in stress per unit strain would indicate a material that is not going to experience plastic deformation gracefully.
> > But for large structures, or structures expected to experience > > unpredictably applied forces, choosing a brittle material is > > disasterous.
> Quite a few large structures, bridges included, built in the 1800s > still stand, even those built from ordinary cast iron parts. Cast iron > (gray iron) is, as you know, not very ductile. I absolutely agree on > ductility being an important property when it comes to preventing > cracks from advancing. The key factor is high energy absorption during > plastic deformation in the front area of a propagating crack. Plastic > deformation that is, the material does not return to its original > shape.
But if one of those cast-iron bridges were to experience, say, an extremely overweight truck, the bridge would be more likely to fracture than to bend (even plastically). Though, now that we are talking about a more complicated structure, that is probably an oversimplification.
> > Did you know that all tall buildings and large bridges sway? Or that > > airplane wings flex, and the skin of the fuselage can tolerate a 3 foot > > crack without catastrophic failure?
> Flexing is not (at least not directly) related to ductility. Rubber, > as in rubber tires, is flexible but not very ductile. In the mid 1950s
Aiee, I just threw that example in there without thinking about it.
> brittle fractures in aluminium caused the loss of at least two (Comet)
They use a particular alloy of aluminum nowadays, though I cannot recall what it is.
> aircrafts. Brittle fractures also sent early steel ships to the sea > bed, even though they were built in mild, and supposedly ductile, > steel. Also, quite a few naval ships were lost during world war two > due to brittle fractures.
Temperature changes, I presume.
I've attempted comparisons between the mechanical and the computer worlds a couple times, since I was taking mechanical engineering courses for a year and a half before switching out. But, I'd better get my terms straight first! Thanks for the input.
-- ; Matthew Danish <mdan...@andrew.cmu.edu> ; OpenPGP public key: C24B6010 on keyring.debian.org ; Signed or encrypted mail welcome. ; "There is no dark side of the moon really; matter of fact, it's all dark."
>> (defmacro do-combinations (syms list &rest body) >> (labels ((work (syms x) >> (let ((y (gensym))) >> (if (cdr syms) >> `(loop as (,(car syms) . ,y) on ,x >> do ,(work (cdr syms) y)) >> `(loop as ,(car syms) in ,x do ,@body))))) >> (work syms list)))
> I'm sorry, this only rivals /usr/include/g++-3/stl_function.h in > readability. No it's worse. I don't even know which tokens are variables > and which ones are keywords. Perhaps it's a good thing there are no > templates, err... I mean macros, in O'Caml.
did you edit the code sample intentionally to make it look unreadable so that you can complain about unreadability or was it simply a stupid mistake?
hs
--
don't use malice as an explanation when stupidity suffices
> > > Whenever you write a function now that gets a variable of type > > > blark, you have to handle all cases, like
> > > let some_fun = fun Foo s -> <do something with the string s> > > > | Bar n -> <do something with the integer n> > > > | Nil -> <do something else>;;
> > > You don't have to handle all cases; typically you do
> > Make that: ``all cases explicitly''.
> Thanks for explaining. I do not want to judge, but at least it looks > awkward to me.
Having see why simulating dynamic-typing is clumsy in a static system (and not possible when redefinition is involved) I would like to point out that pattern-matching is actually one of the neater features of *ML languages.
For example:
(* non-destructive reverse of a list *) fun list_reverse nil = nil | list_reverse (first::rest) = (list_reverse rest) @ [first]
with the additional note that the Lisp function can handle lists with elements of varying types and the ML function, as shown by Nils, can only handle lists of a single type (which can be a union type).
The ML notation is definitely more convenient for these sorts of things. On the other hand, a macro can be defined in Lisp which gives most of the same convenience, and could also potentially handle different types (the ML function is restricted to 'a list -> 'a list). Also the ML notation tends to get a bit messy when function pattern-match clauses are mixed together with case pattern-match clauses and exception handling pattern-match clauses. Not knowing where parenthesis were needed caused a great deal of trouble for me when I was learning SML.
-- ; Matthew Danish <mdan...@andrew.cmu.edu> ; OpenPGP public key: C24B6010 on keyring.debian.org ; Signed or encrypted mail welcome. ; "There is no dark side of the moon really; matter of fact, it's all dark."
