development version newLISP 8.7.8

[Lutz]

This is the first version of newLISP with built-in support for Bayesian Reasoning. Both modes, Chain Bayesian and compounding probabilities with R.A Fisher's Chi2 method, are supported.



See also the CHANGES notes at the bottom for version 8.7.8 for a change affecting the functions 'eval-string' and 'sym' when used inside contexts. Changes may affect exisiting code.



For changes notes and downloads see: http://newlisp.org/downloads/development/">http://newlisp.org/downloads/development/



Lutz

[pjot]

Compiling on Tru64 delivers a problem:

make -f makefile_tru64

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET newlisp.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-symbol.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-math.c

cc: Warning: nl-math.c, line 2186: In this statement, underflow occurs in evaluating the expression "1e-308". (underflow)

                Qchi2[idx] += log(1e-308) * -2.0;

----------------------------------^

cc: Warning: nl-math.c, line 2191: In this statement, underflow occurs in evaluating the expression "1e-308". (underflow)

                Pchi2[idx] += log(1e-308) * -2.0;

----------------------------------^

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-list.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-liststr.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-string.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-filesys.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-sock.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-import.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-xml.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-web.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-matrix.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET nl-debug.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET tru64.c

cc -ieee -xtaso -pedantic -c -O2 -DSOLARIS -DTRU64 -D_POSIX_PII_SOCKET pcre.c

cc newlisp.o nl-symbol.o nl-math.o nl-list.o nl-liststr.o nl-string.o nl-filesys.o  nl-sock.o nl-import.o nl-xml.o nl-web.o nl-matrix.o nl-debug.o tru64.o pcre.o -taso -lm -lrt -ldb -lbsd -Lffi-tru64-4.0 -lffi -o newlisp

strip newlisp

Of course it's in the new Bayes functions. I'll see if I can workaround this some way (compilerflags?). Maybe you have any ideas?



Peter

[Lutz]

1e-308 would be the smallest 'double float' value on a 32bit system, just replace it with the value applicable for your system.



Lutz

[pjot]

Thanks!



Indeed, if I change to '1e-307' then compilation is successfull.



I'll try to find some proof in the Unix documentation on the smallest double float for Tru64Unix and report back to you.



Peter

[Lutz]

I was looking for some kind of constant for this in the GCC documentation but couldn't find it. There should be something somewhere. In any case it doesn't matter much, as long as it is really small ;)



Lutz

[pjot]

OK.... still I found documentation in the Compaq C-compiler docs about floats:



http://h30097.www3.hp.com/dtk/misc_docs/prog_gd/index.html">http://h30097.www3.hp.com/dtk/misc_docs ... index.html">http://h30097.www3.hp.com/dtk/misc_docs/prog_gd/index.html



Quoting the range for V4 systems:

2.2.2    Floating-Point Range and Processing



The C compiler supports IEEE single-precision (32-bit float), double-precision (64-bit double) floating-point data, as defined by the IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985).



Floating-point numbers have the following ranges:



* float: 1.17549435e-38f to 3.40282347e+38f

* double: 2.2250738585072014e-308 to 1.79769313486231570e+308

So maybe I can add a macro to your 'nl-math.c' file, just for Tru64? Or maybe you like to use these values yourself?



Peter

[Lutz]

The GCC says too it is using IEE 754.  2.2250738585072014e-308 is bigger than 1e-308 which explains the underflow error message. I was looking in /usr/include/platform/xxxx/math.h but couldn't find anything suitable for a constant.



I comes down to (log 1e-308) versus (log 1e-307). I could just plug in a constant for (log 1e-308) and avoid the log() operation this way.



Lutz

[pjot]

OK thanks, if I need to test something, please let me know.



Cheers,

Peter

[Dmi]

calling into a context now changes the current run-time context

I'm agree, this is more intuitive.

But is there a way to figure out the old-style run-time context?

Is it possible to have some system symbol/function such as 'MAIN:calling-context which will hold the name of the context in the old manner?



For example, for context functions, that can implicitly extract/create/modify symbols in the context, from which they was called. Potentially, this can be a trick for a sort of OO polymorphism.

[Lutz]

The caller could pass it's context:

Code Select Expand


(context 'FOO)

(define (func ctx)
    (println "have been called from: " ctx))

(context 'MAIN)

(context 'BAR)

(define (func)
    (FOO:func BAR))

(define (foo)
    (FOO:func (context)))  ;; this works since on 8.7.8

(context MAIN)


this will produce the following:

Code Select Expand


(BAR:func) => have been called from: BAR
(BAR:foo) => have been called from: BAR  ; MAIN before 8.7.8
(FOO:func MAIN) => have been called from: MAIN


Lutz

[Dmi]

This is possible workaround. But this looks like if in OO solution I'll wrote:



MY-CONTEXT> (FOO:func property1 property2)



instead of simply



MY-CONTEXT> (FOO:func)



With the second way we'll be able to write not only objects themselves, but something like "the contexts of methods".



Yes, I don't know the language where the called object can implicitly to know and to reference the calling object, but it's sometimes useful, and newlisp seems not to be a "yet another language" ;-)

[Dmi]

Hmm... I found that my reference to "context of methods" isn't fully right, because old-style run-time context isn't the near parent's context...

But the contexts are not real objects too :-)

[Dmi]

Lutz!

I found some interesting issue:

Code Select Expand

newLISP v.8.7.8 on linux, execute 'newlisp -h' for more info.

> (context 'Z)
Z
Z> (define (test ctx) (println ctx))
(lambda (ctx) (println ctx))
Z> (test MAIN)
MAIN
MAIN
Z> (context MAIN)
MAIN
> (Z:test (context))
Z
Z
> (let (c (context)) (Z:test c))
MAIN
MAIN
>

The same is about define-macro.

I feel, my intuitive expectations are different: imho, the evaluation of parameters must not be affected by the context of the function, _to_which_ they are passed.



Btw, about my previous request: I found, that (eval '(context)) is sufficient for me.

[Lutz]

Yes, function parameters in 8.7.8 are evaluated in the context of the function after it is entered. It could be the other way around too, perhaps it should?



Eddie, what do you think? Perhaps it would be more consistent with otherwise applicative order of evaluation in user defined functions?



Lutz



... the more I think about it, I think DMI is right the args should be evaluated in the context of the caller. I will change this for 8.7.9.

[Dmi]

Hmm... Just tested:

Code Select Expand

newLISP v.8.7.8 on linux, execute 'newlisp -h' for more info.

> (define (sum x1 x2) (+ x1 x2))
(lambda (x1 x2) (+ x1 x2))
> (context 'Z)
Z> (define-macro (t) (println (args)))
(lambda-macro () (println (args)))
Z> (context 'MAIN)
MAIN
> (Z:t (sum a b))
((MAIN:sum MAIN:a MAIN:b))
((sum a b))
>
So, my trouble was that (context) is the function, sensitive to to function's context.



Now it's clear. Sorry for "buzz" :-)