The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Numbers in Lisp (was: macros vs HOFs)
 There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic. There was an error processing your request. Please try again. Standard view   View as tree
 Messages 201 - 225 of 295 < Older  Newer >

From:
To:
Cc:
Followup To:
Subject:
 Validation: For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon.

More options Sep 13 2002, 2:07 pm
Newsgroups: comp.lang.lisp
From: Alexander Schmolck <a.schmo...@gmx.net>
Date: 13 Sep 2002 18:57:40 +0100
Local: Fri, Sep 13 2002 1:57 pm
Subject: Numbers in Lisp (was: macros vs HOFs)

Erik Naggum <e...@naggum.no> writes:
> * 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.

Yes, but a rational number is not necessarily an integer (neither in math nor
in CL) and the result type of e.g. a division of integers in CL *can* also be
an integer:

[29]> (integerp (/ 3 1))
T
[30]> (integerp (/ 3 2))
NIL

Irrespective of the fact that all the numbers involved are subtypes of
rationals, this is still different from the behavior of most commonly used
programming languages (including dynamically typed ones) where the result type
of mathematical operations is completely determined by the types of the
parameters. That CL deviates from this common behavior would seem to make it
easier to write abstract numeric code, but one can at least imagine some
disadvantages. For example the fact that most languages will signal an error
if one attempts something like (sqrt some-negative-float) might also help to
find errors due to bugs or numerical roundoff in some cases. Other potential
issues are efficiency (e.g. due to converting back and forwards between
different internal representations), problems with different storage
requirements, and the behavior of arrays or matrices (e.g. how should division
of the elements of a matrix of integers through an integer behave?). In
addition and expression that evaluates to a float in one implementation might
return a rational in another, which could lead to compatibility problems. I
don't know what other things somebody might come up with, but I guess you get
the idea.

I'd like to know whether CL programmers who have written quite a bit of
numerical code feel that CL's number system is just better than what's on
offer in most or all other programming languages for almost any situation or
whether there sometimes are problems/bugs that wouldn't occur in say python or
whatever.

Also, CL is not completely consistent in the approach that mathematical
subsets of a certain group of numbers are just treated as special cases of
this group (e.g. reals are not a subtype of complex and #c(1.0 0.0) and 1.0
behave rather differently, so it is for example not possible to compare the
magnitude of the former to another number; but then #c(1.0 0) isn't of type
complex and eql to 1.0).

I'd be interested to know what the rationale for these decisions was.

>   Only if you think an object is of only one type could you become confused

I didn't think an object had to be of only one type.

> | 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!

Yes they are, unless we have different ideas of what promoting a number
means. (sqrt -1.0) is of type complex ( (complexp (sqrt -1.0) => t) ), but
-1.0 isn't and neither is (sqrt 1.0).

> | Also, is there one overarching reason why rationals aren't complex?

>   Huh?  This is such a confused question.  The mathematical background of the

Sorry, this was badly worded because I was in a hurry. Let me rephrase: is
there one overarching reason why in CL real (and thus also rational) isn't a
subtype of complex (i.e. (complexp 1) => nil)?

Mathematicaly (complexp 1) ==> T would seem more intuitive and in scheme which
has, I think, a similar number model (complex? 1) indeed evaluates to #t (same
for Dylan, I guess).

alex

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "macros vs HOFs (was: O'Caml)" by Erann Gat
More options Sep 13 2002, 2:55 pm
Newsgroups: comp.lang.lisp
From: g...@jpl.nasa.gov (Erann Gat)
Date: Fri, 13 Sep 2002 10:58:54 -0700
Local: Fri, Sep 13 2002 1:58 pm
Subject: Re: macros vs HOFs (was: O'Caml)
In article <MZWBPXvEDLPX18FbpDvKHxQFv...@4ax.com>, Paolo Amoroso

> On Wed, 11 Sep 2002 09:03:51 -0700, g...@jpl.nasa.gov (Erann Gat) wrote:

> > 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

> Which fielded application?

It's called SDS (State Database System).  It's part of a project called
MDS (Mission Data System).  It's pretty much a vanilla Web application.

SDS is written in MCL, and it includes a lightweight HTTP server that may
still be of interest to people.  It's designed to present a programming
abstraction of interacting with Lisp objects rather than "pages" and
"cgi-scripts."  This lets you do some fairly wizzy things in very small
amounts of code.  An old (1999) version of the server code can be found at
http://alvin.jpl.nasa.gov/gat/ftp/http.lsp.  (This version runs in CLisp.)

E.

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "Numbers in Lisp (was: macros vs HOFs)" by Erik Naggum
More options Sep 13 2002, 3:03 pm
Newsgroups: comp.lang.lisp
From: Erik Naggum <e...@naggum.no>
Date: 13 Sep 2002 19:03:21 +0000
Local: Fri, Sep 13 2002 3:03 pm
Subject: Re: Numbers in Lisp (was: macros vs HOFs)
* Alexander Schmolck
| That CL deviates from this common behavior

It does not.

| (e.g. how should division of the elements of a matrix of integers through an
| integer behave?).

Look, learn the language first, /then/ construct hypothetical problems.  If
you want a division of two integers to yield an integer always, you have the
four subtly different operators that does precisely this.  Using the general
division operator is Just Plain Wrong.  Quit whining about non-problems.

| In addition and expression that evaluates to a float in one implementation
| might return a rational in another, which could lead to compatibility
| problems.

Do you have any examples of this?

| I don't know what other things somebody might come up with, but I guess you
| get the idea.

I see that you are happy constructing hypothetical problems, but you have so
far not provided the connection from them to reality.  This is actually far
more relevant than anything you can come up with in a vacuum.

| I'd be interested to know what the rationale for these decisions was.

I believe this is part of the public record.  I have not checked this part
of the specifications sufficiently closely, and even misremembered the issue
on complex, but I believe the story on complex numbers have been covered
sufficiently well in CLtL1 and CLtL2.

--
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.

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "Python Was: LISP - When you've seen it, what else can impress?" by Thomas F. Burdick
More options Sep 13 2002, 3:25 pm
Newsgroups: comp.lang.lisp
Date: 13 Sep 2002 12:25:01 -0700
Local: Fri, Sep 13 2002 3:25 pm
Subject: Re: Python Was: LISP - When you've seen it, what else can impress?

cubicle...@mailandnews.com (Software Scavenger) writes:
> Thomas Guettler <zopestol...@thomas-guettler.de> wrote in message <news:alphsc\$c4n\$06\$1@news.t-online.com>...

> > The code is much more readable than lisp or perl. It has

> I'm curious to know what do-combinations looks like in Python.

Starting /opt/local/bin/cmucl ...
CMU Common Lisp 18d, running on tornado.OCF.Berkeley.EDU
Send questions to cmucl-h...@cons.org. and bug reports to cmucl-...@cons.org.
Python 1.0, target SPARCstation/Solaris 2
CLOS based on PCL version:  September 16 92 PCL (f)
*
* (disassemble (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))))
100DB260:       .ENTRY "DEFUN (SETF MACRO-FUNCTION)"(&rest args) ; (FUNCTION
(&REST T) ..)
280:       CMP        %NARGS, %ZERO
284:       MOV        %CSP, %NL0
288:       BEQ        L2
290:       SUBCC      %NARGS, 24, %NL1
294:       BLE        L1
298:       MOV        %CSP, %NL3
2A4:       SUBCC      4, %NL1
2AC:       LD         [%NL2], %L0
2B0:       BGT        L0
2B4:       ST         %L0, [%NL3]
2B8: L1:   SUBCC      %NARGS, 0, %NL1
2BC:       BEQ        L2
2C0:       SUBCC      4, %NL1
2C4:       ST         %A0, [%NL0]
2C8:       BEQ        L2
2CC:       SUBCC      4, %NL1
2D0:       ST         %A1, [%NL0+4]
2D4:       BEQ        L2
2D8:       SUBCC      4, %NL1
2DC:       ST         %A2, [%NL0+8]
2E0:       BEQ        L2
2E4:       SUBCC      4, %NL1
2E8:       ST         %A3, [%NL0+12]
2EC:       BEQ        L2
2F0:       SUBCC      4, %NL1
2F4:       ST         %A4, [%NL0+16]
2F8:       BEQ        L2
2FC:       SUBCC      4, %NL1
300:       ST         %A5, [%NL0+20]
304: L2:   LD         [%LEXENV+7], %A2
308:       ST         %OCFP, [%CFP]     ; :OPTIONAL entry point
30C:       ST         %LRA, [%CFP+4]    ; No-arg-parsing entry point
310:       LD         [%CODE+69], %A0   ; 'KERNEL:SIMPLE-UNDEFINED-FUNCTION
314:       LD         [%CODE+73], %A1   ; :NAME
318:       LD         [%CODE+77], %A3   ; :FORMAT-CONTROL
31C:       LD         [%CODE+81], %A4   ; "Cannot funcall macro functions."
320:       LD         [%CODE+65], %CNAME ; #<FDEFINITION object for ERROR>
324:       MOV        %CFP, %OCFP
32C:       LD         [%CNAME+5], %A5
334:       MOV        %CSP, %CFP
338:       J          %A5+23
33C:       MOV        %A5, %CODE
340:       .LRA
344:       MOV        %OCFP, %CSP
348:       NOP
350:       UNIMP      10                ; Error trap
354:       BYTE       #x04
355:       BYTE       #x19              ; INVALID-ARGUMENT-COUNT-ERROR
356:       BYTE       #xFE, #xED, #x01  ; NARGS
359:       .ALIGN     4
35C:       UNIMP      10                ; Error trap
360:       BYTE       #x04
361:       BYTE       #x01              ; OBJECT-NOT-FUNCTION-ERROR
362:       BYTE       #xFE, #x0E, #x02  ; A0
365:       .ALIGN     4
368:       UNIMP      10                ; Error trap
36C:       BYTE       #x04
36D:       BYTE       #x16              ; OBJECT-NOT-SYMBOL-ERROR
36E:       BYTE       #xFE, #x2E, #x02  ; A1
371:       .ALIGN     4

--
/|_     .-----------------------.
,'  .\  / | No to Imperialist war |
,--'    _,'   | Wage class war!       |
/       /      `-----------------------'
(   -.  |
|     ) |
(`-.  '--.)
`. )----'

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 5:23 pm
Newsgroups: comp.lang.lisp
From: Johann Hibschman <joh...@physics.berkeley.edu>
Date: 13 Sep 2002 14:23:47 -0700
Local: Fri, Sep 13 2002 5:23 pm
Subject: Re: Python Was: LISP - When you've seen it, what else can impress?

Marco Antoniotti <marc...@cs.nyu.edu> writes:
> cubicle...@mailandnews.com (Software Scavenger) writes:
> > > The code is much more readable than lisp or perl. It has

> > I'm curious to know what do-combinations looks like in Python.

> Does it look?

Well, I like Python.  I've used Python and C++ for at least one major
project that, in retrospect, I should have used Common Lisp for, but
it did teach me the language.

I'd write something like do-combinations as a generator in python:

def combinations(k, objs):
"Iterate recursively over the objects"
if k > len(objs) or k == 0:
return
elif k == 1:
for o in objs:
yield [o]
else:
items = range(k); items[0] = objs[0]
for items[1:] in combinations(k-1, objs[1:]):
yield items
for items in combinations(k, objs[1:]):
yield items

for a, b, c in combinations(3, [1, 2, 3, 4, 5]):
print "Combination is: ", a, b, c

Sure, I should probably use a more clever algorithm that doesn't eat
quite as much stack space, but that's easily done with a bit more
effort.  The important part is that I never have to cons up a list of
all the combinations.

The do-combinations example just happens to fit within the class of
macro-like problems that are solvable with generators.  I'm not trying
to argue that Python has anything like the expressive power of the CL
macro system, just that this particular example is doable.

--Johann

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "macros vs HOFs (was: O'Caml)" by Kaz Kylheku
More options Sep 13 2002, 5:23 pm
Newsgroups: comp.lang.lisp
From: k...@ashi.footprints.net (Kaz Kylheku)
Date: 13 Sep 2002 14:23:33 -0700
Local: Fri, Sep 13 2002 5:23 pm
Subject: Re: macros vs HOFs (was: O'Caml)
step...@dino.dnsalias.com (Stephen J. Bevan) wrote in message <news:m3r8fywtgu.fsf@dino.dnsalias.com>...

Holy carpal tunnel, Batman! But this isn't quite right; I wanted an
example where variables are bound for you, not where you open code it
yourself.

There is a gaping lack of abstraction here; the user knows that combs
generates the combinations in a certain form and then pattern matches
on it to do the destructuring.

I would like to see some utterance which is comprised only of the
constituents that are relevant to the user:
- the inevitable symbol which identifies the language construct;
- the list from which the combinations are drawn;
- the variables which are to be bound to the combination elements; and
- the user's list of expressions, evaluated in the scope of the
variables.

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 5:26 pm
Newsgroups: comp.lang.lisp
From: k...@ashi.footprints.net (Kaz Kylheku)
Date: 13 Sep 2002 14:26:21 -0700
Local: Fri, Sep 13 2002 5:26 pm
Subject: Re: macros vs HOFs (was: O'Caml)

k...@ashi.footprints.net (Kaz Kylheku) wrote in message <news:cf333042.0209111116.60b1815b@posting.google.com>...
> Suppose that the construct ``while true do ... done'' did not exist
> in O'Caml. How would you implement it, such that exactly the same
> syntax is supported (like the above example, for instance).
> Can you do it entirely with higher order functions? I'd like
> to see how.

Still waiting! :)

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 6:38 pm
Newsgroups: comp.lang.lisp
From: Gareth.McCaug...@pobox.com (Gareth McCaughan)
Date: Fri, 13 Sep 2002 23:38:08 +0100
Local: Fri, Sep 13 2002 6:38 pm
Subject: Re: macros vs HOFs (was: O'Caml)

Erik Naggum wrote:
> * 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 the only reason for static typing were efficiency, I'd
agree: but I think it's the obsession with efficiency, not
the static typing, that's responsible. As a supporting
data point, I observe that Haskell is strongly typed but
does int/int -> rational.

What int/int is mostly symptomatic of, I think, isn't exactly
either static typing or efficiency obsession. I think it's
symptomatic of a desire to be close to the machine, which
isn't quite the same as either. (BCPL was close to the machine
but not exactly statically typed; Haskell is statically typed
but not close to the machine. Java is close to the machine
but not efficient; Common Lisp is efficient but not close to
the machine.)

>   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.

I suspect you don't mean what I think you're saying here,
but I can't tell which end the problem is at :-). Common Lisp
has a type system; that type system does aid efficiency;
but it doesn't consider all numeric types disjoint.

It's sort of true that if you're doing static types then
you need to consider types to be disjoint, in that you
need to know *the* type of every expression in the program,
but that's perfectly compatible with having subtype relations
too. Integer can be a subtype of Rational even if everything
gets typed either as Integer or as Ratio.

> * 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.

I don't think "truncate x y" *does* express the operation
better. It expresses it *well*, but so does the alternative.
Note that in mathematics there is no special symbol for
"integer part of the quotient of", nor "nearest integer to
the quotient of", nor either of the other two. Mathematicians'
notation isn't always optimal even for mathematics, never mind
for programming, so all this is intended to show is that the
(truncate (/ x y)) notation is perfectly usable.

Of course, (truncate (/ x y)) feels inefficient. But it doesn't
take a specially smart compiler to make that feeling an illusion.

--
Gareth McCaughan  Gareth.McCaug...@pobox.com
.sig under construc

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 7:05 pm
Newsgroups: comp.lang.lisp
From: Bruce Hoult <br...@hoult.org>
Date: Sat, 14 Sep 2002 11:05:05 +1200
Local: Fri, Sep 13 2002 7:05 pm
Subject: Re: macros vs HOFs (was: O'Caml)
In article <3240918387614...@naggum.no>, Erik Naggum <e...@naggum.no>
wrote:

> * Bruce Hoult
> | BCD makes conversion to and from printed form cheaper.  Other than that,
> | what is wrong with a binary representation?

>   Let me remind you that you did not favor just "binary representation", but
>   IEEE double-precision floating point, of which the "floating-point" part is
>   The Wrong Answer, not binary representatio.  The difference lies in the
>   exactness of fractional values, as I am sure you are aware at some level,

The point is that you do *not* use fractional values.  If some quantity
is specified in 100ths of a cent or 16ths of a cent then you use *that*

I'm not sure why this is so hard to understand.

-- Bruce

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "Numbers in Lisp (was: macros vs HOFs)" by Bruce Hoult
More options Sep 13 2002, 7:14 pm
Newsgroups: comp.lang.lisp
From: Bruce Hoult <br...@hoult.org>
Date: Sat, 14 Sep 2002 11:14:04 +1200
Local: Fri, Sep 13 2002 7:14 pm
Subject: Re: Numbers in Lisp (was: macros vs HOFs)
In article <yfs3csdixgr.fsf...@black132.ex.ac.uk>,
Alexander Schmolck <a.schmo...@gmx.net> wrote:

> Sorry, this was badly worded because I was in a hurry. Let me rephrase: is
> there one overarching reason why in CL real (and thus also rational) isn't a
> subtype of complex (i.e. (complexp 1) => nil)?

> Mathematicaly (complexp 1) ==> T would seem more intuitive and in scheme which
> has, I think, a similar number model (complex? 1) indeed evaluates to #t (same
> for Dylan, I guess).

Yes, <complex> is the superclass of <real> in Dylan.

<real> is the superclass of <float> and <rational>.

<float> is the superclass of <single-float> and <double-float>

<rational> is the superclass of <integer>

-- Bruce

To post a message you must first join this group.
You do not have the permission required to post.
 Discussion subject changed to "macros vs HOFs (was: O'Caml)" by Erik Naggum
More options Sep 13 2002, 7:41 pm
Newsgroups: comp.lang.lisp
From: Erik Naggum <e...@naggum.no>
Date: 13 Sep 2002 23:41:16 +0000
Local: Fri, Sep 13 2002 7:41 pm
Subject: Re: macros vs HOFs (was: O'Caml)
* Gareth McCaughan
| It's sort of true that if you're doing static types then you need to
| consider types to be disjoint, in that you need to know *the* type of every
| expression in the program, but that's perfectly compatible with having
| subtype relations too.  Integer can be a subtype of Rational even if
| everything gets typed either as Integer or as Ratio.

One of the major problems I have with strong typing is precisely that it
flies in the face of another pretentious theory, object-orientation, which
supposedly should have a type hierarchy and run-time dispatch on the type of
the actual object.  The two theories seem to be seriously at odds.  What we
have in Common Lisp is thoroughly object-oriented approach.  This should be
good, but somehow the strongly-typed nutjobs go "eep, eep" (thanks, Tim) and
seem to ignore that their theories are all bunk if they cannot handle a type
hierarchy.  Even before I started programming in Common Lisp, I found the
desire to know /the/ (single) type of every expression to be suspect and the
theories wanting when they made that premise.  As if you could not reason
about types unless you had only one type!  As if you could not operate with
union types created on the fly!  All bunk, I say.

| Of course, (truncate (/ x y)) feels inefficient. But it doesn't take a
| specially smart compiler to make that feeling an illusion.

Not so.  Please remember the secondary return value.

--
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.

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 7:49 pm
Newsgroups: comp.lang.lisp
From: Erik Naggum <e...@naggum.no>
Date: 13 Sep 2002 23:49:58 +0000
Local: Fri, Sep 13 2002 7:49 pm
Subject: Re: macros vs HOFs (was: O'Caml)
* Bruce Hoult
| The point is that you do *not* use fractional values.

Marvellous.

| If some quantity is specified in 100ths of a cent or 16ths of a cent then
| you use *that* as your unit.

And if you multiply them, you get 1600th of a cent as the unit, then convert
to another currency with 6-digit precision and you effectively compute with
1,600,000,000th of a cent as the smallest unit.  Suddenly, you have only 22
bits left for the cent value, and a transaction worth more than USD 42,000
will no longer fit in your double-precision floating point number.  Great!

| I'm not sure why this is so hard to understand.

Because, as several times in the past, you are just plain wrong, and you are
the last person on the planet to admit it or figure it out.  So I shall do us
all a huge favor and not attempt to convince you of the errors of your ways.

--
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.

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 8:31 pm
Newsgroups: comp.lang.lisp
From: Bruce Hoult <br...@hoult.org>
Date: Sat, 14 Sep 2002 12:31:09 +1200
Local: Fri, Sep 13 2002 8:31 pm
Subject: Re: macros vs HOFs (was: O'Caml)
In article <3240949798321...@naggum.no>, Erik Naggum <e...@naggum.no>
wrote:

> * Bruce Hoult
> | The point is that you do *not* use fractional values.

>   Marvellous.

> | If some quantity is specified in 100ths of a cent or 16ths of a cent then
> | you use *that* as your unit.

>   And if you multiply them, you get 1600th of a cent as the unit,
>   then convert to another currency with 6-digit precision and you
>   effectively compute with 1,600,000,000th of a cent as the smallest
>   unit.  Suddenly, you have only 22 bits left for the cent value, and
>   a transaction worth more than USD 42,000 will no longer fit in your
>   double-precision floating point number.  Great!

I'm not sure what field you are thinking of, but numbers are *not* used
in that way in either accounting or finance.  It's simply not a problem.

Think about it in terms of dimensional analysis.  Physics uses values
with dimensions involving squared and higher powers of quantities.
Accounting *doesn't*.

> | I'm not sure why this is so hard to understand.

>   Because, as several times in the past, you are just plain wrong,
>   and you are the last person on the planet to admit it or figure it
>   out.  So I shall do us all a huge favor and not attempt to convince
>   you of the errors of your ways.

Uh huh.

I worked in stockbroking and finance companies for a decade, writing
software dealing with stock and FX and government stock calculations.  I
never had any trouble meeting specs, using FP.

You're clearly outside your area of expertise here.

-- Bruce

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 8:56 pm
Newsgroups: comp.lang.lisp
From: g...@jpl.nasa.gov (Erann Gat)
Date: Fri, 13 Sep 2002 17:11:14 -0700
Local: Fri, Sep 13 2002 8:11 pm
Subject: Re: macros vs HOFs (was: O'Caml)

In article <3240949798321...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
> * Bruce Hoult
> | The point is that you do *not* use fractional values.

>   Marvellous.

> | If some quantity is specified in 100ths of a cent or 16ths of a cent then
> | you use *that* as your unit.

>   And if you multiply them, you get 1600th of a cent as the unit,

Why would you ever need to multiply monetary quantities?

E.

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 9:24 pm
Newsgroups: comp.lang.lisp
From: Erik Naggum <e...@naggum.no>
Date: 14 Sep 2002 01:24:20 +0000
Local: Fri, Sep 13 2002 9:24 pm
Subject: Re: macros vs HOFs (was: O'Caml)
* Bruce Hoult <br...@hoult.org>
| I worked in stockbroking and finance companies for a decade, writing
| software dealing with stock and FX and government stock calculations.  I
| never had any trouble meeting specs, using FP.

I have worked with Oslo Stock Exchange and related businesses since 1990,
when I specified the protocol between the exchange and brokers' computer
systems. and I have designed and specified several protocol since then.  We
had several problems with software vendors who used floating-point to store
numeric values.  It was, even back then, a well-established fact that people
ran into problems when they chose to use floating-point for numeric values
that were not, in fact, floating point, but fix-point.

| You're clearly outside your area of expertise here.

Your competence in assessing mine is also remarkably lacking.  That you keep
on fighting is even more puzzling.  I think you should try to talk to someone
yourself when you are simply /factually/ wrong about something.

How do you know that you have been meeting specs with floating point?  I
think you are the kind of programmer who makes things work.  I am the kind
of programmer who makes sure things do not fail.  What "works" for you is
not even relevant to me.  There are sufficient problems with floating-point
that it cannot be used in software that has to be exactly right all the time.
It does not matter that you can detect when you are no longer exact, because
you have to do something when that happens to become exact, again.  You
could give up when you run out of precision in your floating-point format,
but that is generally not an acceptable option.  So you have to a Plan B
when this happens.  There may be good reasons to work with a Plan A and a
Plan B, but during my long carreer as a programmer, I have seen one thing
again and again that makes me desire not to rely on Plan B: It is almost
never debugged properly because it is not expected to be used.  This is in
sharp contrast to military-style contingency planning, where you rely on
your contingency plan to be failsafe when your primary plan may fail.  I am
not a fully trained paranoid (i.e., lawyer), but I believe that understanding
the need for and nature of contingency planning is a requirement for anyone
who teaches planning, and that is, in effect, what programmers teach their
computers.

By the way, if you want 53-bit integers with double-precision floating-point,
why not go for the full 64-bit integers that you get even on 32-bit machines
with C99's new `long long int´ type?  Or you could use the 80-bit floating-
point that is used in the Intel Architecture.  Or perhaps the MMX registers.
However, I would expect an implementation of a bignum library to make the
most of the hardware.  If the implementation is not strong on bignus, that
is, somewhat ironically, because bignums are also Plan B for most systems.

--
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.

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 9:37 pm
Newsgroups: comp.lang.lisp
From: Erik Naggum <e...@naggum.no>
Date: 14 Sep 2002 01:37:25 +0000
Local: Fri, Sep 13 2002 9:37 pm
Subject: Re: macros vs HOFs (was: O'Caml)
* Erann Gat
| Why would you ever need to multiply monetary quantities?

Units, dude.  Units.  Just /add/ two numbers with different denominators,
and you get into this problem right away.  Granted, you can make do with
400th of a cent, but then you need to get into the whole least common
denominator game, and you should have used rationals to begin with.

--
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.

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 9:57 pm
Newsgroups: comp.lang.lisp
From: g...@jpl.nasa.gov (Erann Gat)
Date: Fri, 13 Sep 2002 18:53:40 -0700
Local: Fri, Sep 13 2002 9:53 pm
Subject: Re: macros vs HOFs (was: O'Caml)

In article <3240956245803...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
> * Erann Gat
> | Why would you ever need to multiply monetary quantities?

>   Units, dude.  Units.  Just /add/ two numbers with different denominators,
>   and you get into this problem right away.  Granted, you can make do with
>   400th of a cent, but then you need to get into the whole least common
>   denominator game, and you should have used rationals to begin with.

Sorry, but that answer makes no sense to me.  "Units, dude, units" is what
caused me to pose the question in the first place.  If I multiply dollars
by dollars I get dollars-squared, which I find mighty puzzling.  (I am
reminded of when I was twelve or so and my father tried to explain to me
that the acceleration of gravity was 9.8 meters per second squared, and I
couldn't wrap my brain around what a squared second would be.)

In my experience there are only two mathematical operations that one ever
actually performs on monetary values: multiplying a monetary value by a
scalar, or adding two monetary values with the same units.  But my
financial experience is pretty much limited to balancing my checkbook so
maybe I'm missing something here.

E.

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 10:04 pm
Newsgroups: comp.lang.lisp
From: Bruce Hoult <br...@hoult.org>
Date: Sat, 14 Sep 2002 14:04:04 +1200
Local: Fri, Sep 13 2002 10:04 pm
Subject: Re: macros vs HOFs (was: O'Caml)
In article <gat-1309021854250...@192.168.1.50>,
g...@jpl.nasa.gov (Erann Gat) wrote:

No, you're not missing anything.  In fact you see the issues pretty
clearly.

-- Bruce

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 10:04 pm
Newsgroups: comp.lang.lisp
From: Erik Naggum <e...@naggum.no>
Date: 14 Sep 2002 02:04:41 +0000
Local: Fri, Sep 13 2002 10:04 pm
Subject: Re: macros vs HOFs (was: O'Caml)
* g...@jpl.nasa.gov (Erann Gat)
| If I multiply dollars
| by dollars I get dollars-squared, which I find mighty puzzling.

I conclude that you are illiterate.  Go take a remedial reading class and
when you have passed it, try to understand the very /next/ sentence from the
article you obviously stopped comprehending after the first few words and
thought you had understood enough to form your stupid response.  You will
have to fax me the graduation papers before I believe you can read and I want
to respond to you again.

--
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.

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 10:07 pm
Newsgroups: comp.lang.lisp
From: Nils Goesche <n...@cartan.de>
Date: 14 Sep 2002 04:07:03 +0200
Local: Fri, Sep 13 2002 10:07 pm
Subject: Re: macros vs HOFs (was: O'Caml)

Ray Blaak <bl...@telus.net> writes:
> Erik Naggum <e...@naggum.no> writes:
> >   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.

> The other major goal, of course, is "correctness", insofar as
> that can be shown statically for those who are interested. CL's
> numeric tower of subtypes is perfectly useful statically as
> well for this purpose.

Yes, correctness and efficiency are the goals of static typing.
The correctness part however is probably a myth (see the plist
example I posted in this thread, for instance).  So we are left
with efficiency.

> However, even for the goal of pure efficiency, the numeric
> types need not be necessarily disjoint. One would use
> "arbitrary number" as necessary (i.e. conservatively, when in
> doubt), and use the more restricted types where shown to be
> needed. In those places where the compiler/interpreter knows
> restricted types are being used, more efficient code can be
> generated.

Just as in Lisp: You add declarations narrowing the set of
possible numeric types of certain variables when needed.

One could probably try to do that in a static language, too:
Always use the most ``arbitrary'' number type available at first,
and restrict when needed for efficiency.  But... does anybody
ever do that?  All static languages I've met so far distinguish
for instance between fixnums and bignums.  And all library
functions take fixnums.  Take any static language of your choice
and try to add 42 to a bignum.  It will be awkward: You'll first
have to convert 42 to a bignum.  And if you call a library
function that takes a fixnum you'll have to explicitly convert
back every bignum argument to a fixnum, handling all kinds of
exceptions along the way.  And that is not enough: We might have
to take rationals into account, so we can do something like

CL-USER 1 > (defparameter *a* 5)
*A*

CL-USER 2 > *a*
5

CL-USER 3 > (/ *a* 3)
5/3

CL-USER 4 > (setq *a* (/ *a* 3))
5/3

CL-USER 5 > (setq *a* (* 3 *a*))
5

So, we should have calculated with rationals, and only rationals,
to begin with.  So, now, our whole program has to deal with
rationals and not with integers (otherwise we'd quickly go nuts
being forced to convert fixnums, bignums and rationals into each
other).  This means, I now have to rewrite all of my software to
compute not only with bignums but with rationals.  God beware if
only a single float shows up somewhere...

Of course, all ``correctness'' is gone anyway, now: Every number,
even 0, is an arbitrary precision rational now; I only have to
``cast'' whenever I want to call a library function -- what can
the type checker possibly catch?  And this is different from Lisp:
When I know the argument of the function FOO will always be a
fixnum and I want more efficiency, I'll declare the argument to
be a fixnum within the definition of FOO and be done with it; but
in a static language, I'd have to change /every call/ to FOO so
it casts the argument to a fixnum.

Of course, along the way, you'll forget about 37 calls to FOO,
and the type checker will stop you for every single one of them.
And when you're done with all 37 error messages, and have added
all your 37 casts, you'll think: ``Thank God for my type checker.
He just saved me the time for finding 37 bugs.''

Or maybe not?

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

PGP key ID #xD26EF2A0

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 10:11 pm
Newsgroups: comp.lang.lisp
Date: 13 Sep 2002 22:11:03 -0400
Local: Fri, Sep 13 2002 10:11 pm
Subject: Re: macros vs HOFs (was: O'Caml)

The problem isn't fractions, FP types can accurately represent many
fractions just like they can many integers.  The problem is unforseen
& difficult to detect rounding which may occur in intermediate terms
of arithmetic- when the precision demands of the results of a
particular operation exceed the capacity of the type.  You'll probably
run into rounding trouble pretty quickly if you use single precision
FP- going to double precision only decreases the likelihood of the
problem for given values of operands and operators.

I completely agree that lots of financial arithmetic can be accurately
done in FP- but the potential for unexpected rounding is always there,
and when it shows up, you're screwed because you can't trust the
results of your arithmetic.  The likely result is lots of verification
of each step which is tricky because sometimes the rounding errors of
the original equation are compensated for by different rounding errors
the wrong results.

Gregm

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 10:13 pm
Newsgroups: comp.lang.lisp
From: Bruce Hoult <br...@hoult.org>
Date: Sat, 14 Sep 2002 14:13:29 +1200
Local: Fri, Sep 13 2002 10:13 pm
Subject: Re: macros vs HOFs (was: O'Caml)
In article <3240955460519...@naggum.no>, Erik Naggum <e...@naggum.no>
wrote:

> * Bruce Hoult <br...@hoult.org>
> | I worked in stockbroking and finance companies for a decade, writing
> | software dealing with stock and FX and government stock calculations.  I
> | never had any trouble meeting specs, using FP.

>   I have worked with Oslo Stock Exchange and related businesses since
>   1990, when I specified the protocol between the exchange and
>   brokers' computer systems. and I have designed and specified
>   several protocol since then.  We had several problems with software
>   vendors who used floating-point to store numeric values.

I don't doubt it.  Thee are plenty of people out there totally ignorant
of the properties of computer arithmetic.

>  It was, even back then, a well-established fact that people ran into
>  problems when they chose to use floating-point for numeric values
>  that were not, in fact, floating point, but fix-point.

In 1990?  I guess so, since I was taught the same thing around 1980.
However, as with many things that are taught to you as an undergraduate
(or ::shudder:: at highschool), it turns out to be a half-truth or
approximation at best, designed to keep the ignorant out of trouble.

One point you are missing with your talk about Plan B's and bignums is
that financial systems have specifications for their outputs as well as
their inputs.  It is no use using bignums internally if you then have to
feed the result into e.g. a stock exchange or Reuters/Bloomburg/whatever
system that is specified with a fixed number of significant figures.

-- Bruce

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 10:32 pm
Newsgroups: comp.lang.lisp
From: Erik Naggum <e...@naggum.no>
Date: 14 Sep 2002 02:32:17 +0000
Local: Fri, Sep 13 2002 10:32 pm
Subject: Re: macros vs HOFs (was: O'Caml)
* Bruce Hoult
| However, as with many things that are taught to you as an undergraduate (or
| ::shudder:: at highschool), it turns out to be a half-truth or approximation
| at best, designed to keep the ignorant out of trouble.

If you believe this is relevant, you assume too much.  Quit being so annoying.

--
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.

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 10:36 pm
Newsgroups: comp.lang.lisp
From: m...@oscar.eng.cv.net (Marc Spitzer)
Date: Sat, 14 Sep 2002 02:36:40 GMT
Local: Fri, Sep 13 2002 10:36 pm
Subject: Re: macros vs HOFs (was: O'Caml)

here is a simple example you have an integer type that can hold
4,000,000,000 units an you have a max transaction size of \$10,000,000
no problem right?  now we need to take care of pennies also so your
new max transaction size is 1,000,000,000 cents (units) but wait there
are fractions of a cent lets say you need to keep track of 1/16 so now
have a max unit size of 16,000,000,000.  Do you see the problem now.

Or were you just deliberately not getting it?

marc

To post a message you must first join this group.
You do not have the permission required to post.
More options Sep 13 2002, 10:57 pm
Newsgroups: comp.lang.lisp
From: Christopher Browne <cbbro...@acm.org>
Date: 14 Sep 2002 02:57:23 GMT
Local: Fri, Sep 13 2002 10:57 pm
Subject: Re: macros vs HOFs (was: O'Caml)
Oops! Bruce Hoult <br...@hoult.org> was seen spray-painting on a wall:

No, I don't think that is being missed.

Using bignums and/or rationals internally that provide 'total
precision,' and well-trustable math predicates, means that you can be
quite certain that the _internal_ dealings with the values has been
handled faithfully.

If you then have to round it to three decimal places, for output
purposes, _that's fine_.

At the end of the day, what is likely to happen is that you'll have
sets of transactions that will be denominated in terms of having two
or three decimal places.

Get them right and you've got the Important Thing right.  If using
bignums and rationals makes it easier to be confident that the values
are correct, then you've made life easier by using bignums/rationals.

And at the end of the day, the ultimate transactions will involve
things like:

"Foo Paid \$750.376 for 72.378 units of Bar."

And that's _exact_, whatever the interim values whilst doing
calculations may have been.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://www.ntlug.org/~cbbrowne/rdbms.html
"The only ``intuitive'' interface is the nipple. After that, it's all
learned."  -- Bruce Ediger, bedi...@teal.csn.org on X interfaces.