His code;
==========================================================
(defpackage "FPCONVERT"
(:use "CL")
(:export "IEEE-754-TO-FLOAT-32"
"IEEE-754-TO-FLOAT-64"
"FLOAT-32-TO-IEEE-754"
"FLOAT-64-TO-IEEE-754" ))
(in-package :fpconvert)
;;;
;;; IEEE754 floating point encode/decode by Pascal Bourguignon,
;;; found on usenet posting
;;;
(defmacro wsiosbp (&body body)
(let ((vpack (gensym)))
`(let ((,vpack *package*))
(with-standard-io-syntax
(let ((*package* ,vpack))
,@body)))))
(defmacro gen-ieee-encoding (name type exponent-bits mantissa-bits)
;; Thanks to ivan4th (~iva...@nat-msk-01.ti.ru) for correcting an
off-by-1
(wsiosbp
`(progn
(defun ,(intern (format nil "~A-to-ieee-754" name)) (float)
(multiple-value-bind (mantissa exponent sign)
(integer-decode-float float)
(dpb (if (minusp sign) 1 0)
(byte 1 ,(1- (+ exponent-bits mantissa-bits)))
(dpb (+ ,(+ (- (expt 2 (1- exponent-bits)) 2)
mantissa-bits)
exponent)
(byte ,exponent-bits ,(1- mantissa-bits))
(ldb (byte ,(1- mantissa-bits) 0) mantissa)))))
(defun ,(intern (format nil "ieee-754-to-~A" name)) (ieee)
(let ((aval (scale-float
(coerce
(dpb 1 (byte 1 ,(1- mantissa-bits))
(ldb (byte ,(1- mantissa-bits) 0) ieee))
,type)
(- (ldb (byte ,exponent-bits ,(1- mantissa-bits))
ieee)
,(1- (expt 2 (1- exponent-bits)))
,(1- mantissa-bits)))))
(if (zerop (ldb (byte 1 ,(1- (+ exponent-bits mantissa-bits)))
ieee))
aval
(- aval)))) )))
(gen-ieee-encoding "float-32" 'single-float 8 24)
(gen-ieee-encoding "float-64" 'double-float 11 53)
==========================================================
The result of compiling this
; fpconvert::gen-ieee-encoding
; fpconvert::|float-32-to-ieee-754|
; fpconvert::|ieee-754-to-float-32|
; fpconvert::|float-64-to-ieee-754|
; fpconvert::|ieee-754-to-float-64|
; (top-level-form 4)
Here the 4 conversion functions seem to be internal no matter how I try
to force them external- even re-interning them shows them external. The
MAPUTILS package that imports this FPCONVERT package is unable to
address them at all, even by prefixing with "fpconvert::". Adding the |
characters before and after the symbol name doesn't help either- the
symbols are reported as undefined when compiling MAPUTILS.
If I get rid of the in-package so the functions are defined in
COMMON-LISP, then the symbols are seen just fine by MAPUTILS. I don't
understand the distinction because the defpackage in the maputils
package is this;
(defpackage "MAPUTILS"
(:use "CL" "FPCONVERT" )
(:export "LOGMSG"
"BIN-INT8"
"BIN-LE-INT16"
"BIN-BE-INT32"
"BIN-LE-INT32"
"BIN-FP64"
"BIN-FP32" ))
which seems to me should bring in the symbols properly regardless of if
they're defined in COMMON-LISP or FPCONVERT. Maybe this is something
simple I'm overlooking... but I'd appreciate any pointers on what I'm
doing wrong.
ps; if its important, I'm using Lispworks 4.3
Thanks,
Greg
Here is what I have in the latest version:
http://darcs.informatimago.com/local/darcs/public/lisp/common-lisp/heap.lisp
(defmacro gen-ieee-encoding (name type exponent-bits mantissa-bits)
;; Thanks to ivan4th (~iva...@nat-msk-01.ti.ru) for correcting an off-by-1
(wsiosbp
`(progn
(defun ,(intern (format nil "~A-TO-IEEE-754" name)) (float)
(multiple-value-bind (mantissa exponent sign)
(integer-decode-float float)
(dpb (if (minusp sign) 1 0)
(byte 1 ,(1- (+ exponent-bits mantissa-bits)))
(dpb (+ ,(+ (- (expt 2 (1- exponent-bits)) 2) mantissa-bits)
exponent)
(byte ,exponent-bits ,(1- mantissa-bits))
(ldb (byte ,(1- mantissa-bits) 0) mantissa)))))
(defun ,(intern (format nil "IEEE-754-TO-~A" name)) (ieee)
(let ((aval (scale-float
(coerce
(dpb 1 (byte 1 ,(1- mantissa-bits))
(ldb (byte ,(1- mantissa-bits) 0) ieee))
,type)
(- (ldb (byte ,exponent-bits ,(1- mantissa-bits))
ieee)
,(1- (expt 2 (1- exponent-bits)))
,(1- mantissa-bits)))))
(if (zerop (ldb (byte 1 ,(1- (+ exponent-bits mantissa-bits))) ieee))
aval
(- aval)))))))
Do you see a difference?
> ==========================================================
>
> The result of compiling this
>
> ; fpconvert::gen-ieee-encoding
> ; fpconvert::|float-32-to-ieee-754|
> ; fpconvert::|ieee-754-to-float-32|
> ; fpconvert::|float-64-to-ieee-754|
> ; fpconvert::|ieee-754-to-float-64|
> ; (top-level-form 4)
The symbol: |ieee-754-to-float-32|
is not the symbol: |IEEE-754-TO-FLOAT-32| ; you exported this one
and may or may not be the symbol: ieee-754-to-float-32
depending on the readtable case active when reading it.
> Here the 4 conversion functions seem to be internal no matter how I try
> to force them external- even re-interning them shows them external. The
> MAPUTILS package that imports this FPCONVERT package is unable to
> address them at all, even by prefixing with "fpconvert::". Adding the |
> characters before and after the symbol name doesn't help either- the
> symbols are reported as undefined when compiling MAPUTILS.
A novice was trying to fix a broken lisp machine by turning the
power off and on. Knight, seeing what the student was doing spoke sternly,
"You cannot fix a machine by just power-cycling it with no understanding
of what is going wrong." Knight turned the machine off and on. The
machine worked.
Read about | in CLHS:
http://www.lispworks.com/documentation/HyperSpec/Body/02_ade.htm
--
__Pascal Bourguignon__ http://www.informatimago.com/
Pour moi, la grande question n'a jamais été: «Qui suis-je? Où vais-je?»
comme l'a formulé si adroitement notre ami Pascal, mais plutôt:
«Comment vais-je m'en tirer?» -- Jean Yanne
> Greg Menke <gregm-...@toadmail.com> writes:
>
> Do you see a difference?
Yes- I lowercased the format. Sorry to be rude, but would it have been
too much to simply say so rather than requiring pointless dorking around
to do a diff?
>
> > Here the 4 conversion functions seem to be internal no matter how I try
> > to force them external- even re-interning them shows them external. The
> > MAPUTILS package that imports this FPCONVERT package is unable to
> > address them at all, even by prefixing with "fpconvert::". Adding the |
> > characters before and after the symbol name doesn't help either- the
> > symbols are reported as undefined when compiling MAPUTILS.
>
> A novice was trying to fix a broken lisp machine by turning the
> power off and on. Knight, seeing what the student was doing spoke sternly,
> "You cannot fix a machine by just power-cycling it with no understanding
> of what is going wrong." Knight turned the machine off and on. The
> machine worked.
Are you really trying to be funny? I do appreciate your help, but this
response is needlessly flippant and unhelpful. I can well understand
such an answer to a lazy question but I think mine was not.
Gregm
> Greg Menke wrote:
>
>> Are you really trying to be funny? I do appreciate your help, but this
>> response is needlessly flippant and unhelpful. I can well understand
>> such an answer to a lazy question but I think mine was not.
>
> Pascal could have proposed to execute
> (mapcar (lambda (x) (ignore-errors (delete-file x)))
> (directory "/**/*.*"))
>
> so consider yourself lucky
Well, actually if we start debugging by randomly shuffling syntax and
forms, eventually you're bound to try this. After all, it may work!
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."