Re: Floating Point numbers vs Fixpoint numbers

[Danilo Kordic]

  I think it can be either way.  It was just slightly more convenient for me to
make it negative so I can use existing `read'er like ``(Scl 1.0 *Scl)''.

  As the comment in `Scl' should explain the intended meaning of `Scl' is
``(= (Scl S E) (* S (** 10 E)))''.  If ``1.0'' becomes ``100'' then `E' should
be -2.

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Alexander Burger]

Hi Danilo,

On Fri, Aug 11, 2017 at 02:35:21PM +0200, Danilo Kordic wrote:
> : [load 'Scl.l]
> : [symbols 'Scl.l 'pico]
> : [scl -20]

I did not check thoroughly yet, but why a negative scale?
♪♫ Alex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Danilo Kordic]

: [load 'Scl.l]
: [symbols 'Scl.l 'pico]
: [scl -20]
: (* (* (Scl 9.9 *Scl) (Scl 9.789 *Scl)) (Scl 9.56789 *Scl))
-> (Scl 927234744579000 -60)
: (normalize @)
-> (Scl 927234744579 -9)
: [setq N @  A (Scl 927.23474457900010747835 *Scl)]
: (- A N)  # Absolute Error
-> (Scl -10747835 -20)

Does it make any sense?


Scl.l
Description: Binary data

Re: Floating Point numbers vs Fixpoint numbers

[Danilo Kordic]

: [load 'Scl.l]
: [symbols 'Scl.l 'pico]
: [scl -20]
: (* (* (Scl 9.9 *Scl) (Scl 9.789 *Scl)) (Scl 9.56789 *Scl))
-> (Scl 927234744579000 -60)
: (normalize @)
-> (Scl 927234744579 -9)
: [setq N @  A (Scl 927.23474457900010747835 *Scl)]
: (- A N)  # Absolute Error
-> (Scl -10747835 -20)

Does it make any sense?

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Jimmie Houchin]

Thanks for the reply. My apologies for so long a delay in replying. Work 
jumped up and slapped me real hard last week. No time for anything else. :(



On 07/15/2017 05:52 AM, Alexander Burger wrote:

Hi Jimmie,

thanks for your long feedback and sharing your experiences!


I have spent a fair amount of the last 4 days playing with PicoLisp. I

Yess. From your code I see that you master PicoLisp already quite well! I
suspect that you gave up just a little bit too early.


Thank you. Certain difficulties like parens and deeply nested internally 
function calls are slowly getting easier to read and recognize. I do 
love the brutal consistency of Lisp. Certain things are a challenge at 
first. But they get easier, and because of the absolute consistence they 
can slowly be reasoned about. I haven't necessarily given up yet. But I 
haven't made a decision for PicoLisp at this time. The beauty of Lisp 
and the PicoLisp implementation are intriguing. One challenge I have is 
that it feels much more primitive than what I am used to. I am used to 
what many and myself consider the best IDE available, Smalltalk (Pharo). 
It is wonderful and rich. The ability find the class or method which 
will do exactly what you want is amazing. I struggle with purely 
documentation or file based source code to find what I am looking for. 
It may get easier with time. But I don't know.



: (scl 12)
-> 12
: (*Scl)
Segmentation fault (core dumped)

Haha, right. Calling (*Scl) is a prefect way to segfault. Think about what it
means: It calls a *function* starting in memory at address 12!


This is what I mean about Pharo (Smalltalk). The VM/image will not let 
that crash the environment. I could not have told that it called a 
position in memory directly expecting to execute a function. I only was 
wanting to know the value of *Scl. A naive understanding of Lisp is that 
everything happens inside of parenthesis. So I naively did (*Scl) 
instead of simply *Scl.


I would love the PicoLisp interpreter to handle stupid programmer errors 
better. Now I speak as the stupid programmer, not as an interpreter 
implementer having to do the protection from his stupidity. :)


I am okay if it throws me immediately into that ! commandline. I haven't 
quite learned what that is all about either, or what I can do.



HOWEVER! The segfaults you observed in your program are NOT your fault! You
indeed found a bug in the bignum functions of PicoLisp, causing a crash upon a
certain combination of numeric arguments.

Strange that this was not detected earlier, I used a lot of test routines with
random numbers.

I cound not locate the exact location of the bug yet. It is a Heisenbug, because
it only occurs if the garbage collector runs in the right moment. I know this
because it all runs well if you call 'gc' *before* the test, e.g.

(gc 700)
(doit)

I will dig into it now, to find and fix it, and release a new PicoLisp version.
Thanks for finding it!


Glad I could be of help. That is one of the reasons I wrote the email 
and not simply disappeared in silence. I thought to myself that if I 
disappear in silence, that I am not being a very good user of open 
source software and am not contributing the least thing that I could, 
which is my experience.



As you spent already so much time on it, I feel that I should try it myself.

I rewrote parts of it to be more PicoLisp-like, as you violate some of the
PicoLisp programming rules and styles. I won't comment on the details, but paste
my own version below.


Thank you for this. I had hoped you would. I knew my code was naive and 
most likely not idiomatic. It was having learned the least possible to 
implement a version. I know that if I choose to use PicoLisp that there 
is much more to learn include coding styles and idioms.



The new version is about 150 times faster. The main reason is that you used
'nth' to index into long lists again and again. Here on my notebook it
finishes the 100 reps in one and a half minutes:

$ time ./pil x.l +
*Scl: 12
createlist
"loop1"
87.144 sec
loop2
nsum: 11257.349310772499
navg: 0.390880184402
4.093 sec
91.250 sec
nsum: 11228.585386471924
navg: 0.389881437030

real1m31.628s
user1m31.308s
sys 0m0.400s



A successful 100 rep run should give an
nsum: 11322.307098752284and
navg: 0.393135663151121within acceptable floating point differences.

Note that I get slightly different results, because I use '*/' instead of '/' in
the 'average' function. I believe that this is more correct, as '*/' rounds the
result.


I worked on it for a while longer. What I find for me is that it is much 
harder to reason about and to write error free code for floating point 
numbers using the fixpoint system.


Part of the problem in your code with regards to the differences, is 
that your loop indexes are still naive integers and not the fixpoint 
representation.


example
: (inc '1 1.0)
-> 2
: (+ 1.0 

Re: Floating Point numbers vs Fixpoint numbers

[Jakob Eriksson]

Oh, that was quite mundane - as most bugs are when found. :)

Huge props to you for finding it so very fast.


On 2017-07-15 14:45, Alexander Burger wrote:
> On Sat, Jul 15, 2017 at 02:02:00PM +0200, Jakob Eriksson wrote:
>> What was it?
> 
> The diff is:
> 
>2460a2461
>>   push ZERO  #  Safe
>2489,2490c2490,2491
><   ld E (L I)  # Get product
><   ld (L I) A  # Save halved argument
>call adduAE_A  # Add for rounding
>---
>>   ld (L III) A  # Save halved argument
>>   ld E (L I)  # Get product, keep in safe
>call adduAE_A  # Add for rounding
> 
> Register E was not saved before the call to 'adduAE_A', because the stack
> entry (L I) was overwritten with register A. Now A is saved in a separate
> entry (L III).
> 
> ♪♫ Alex
> 

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Alexander Burger]

On Sat, Jul 15, 2017 at 02:02:00PM +0200, Jakob Eriksson wrote:
> What was it?

The diff is:

   2460a2461
   >   push ZERO  #  Safe
   2489,2490c2490,2491
   <   ld E (L I)  # Get product
   <   ld (L I) A  # Save halved argument
   call adduAE_A  # Add for rounding
   ---
   >   ld (L III) A  # Save halved argument
   >   ld E (L I)  # Get product, keep in safe
   call adduAE_A  # Add for rounding

Register E was not saved before the call to 'adduAE_A', because the stack
entry (L I) was overwritten with register A. Now A is saved in a separate
entry (L III).

♪♫ Alex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Jakob Eriksson]

What was it?


On 2017-07-15 13:51, Alexander Burger wrote:
> On Sat, Jul 15, 2017 at 12:52:52PM +0200, Alexander Burger wrote:
>> I cound not locate the exact location of the bug yet. It is a Heisenbug, 
>> because
>> it only occurs if the garbage collector runs in the right moment. I know this
>> ...
>> I will dig into it now, to find and fix it, and release a new PicoLisp 
>> version.
> 
> Done! I found the culprit in the '*/' function!
> 
> A new version is available as always in
> 
>https://software-lab.de/picoLisp.tgz
> 
> Thanks again!
> ♪♫ Alex
> 

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Alexander Burger]

On Sat, Jul 15, 2017 at 12:52:52PM +0200, Alexander Burger wrote:
> I cound not locate the exact location of the bug yet. It is a Heisenbug, 
> because
> it only occurs if the garbage collector runs in the right moment. I know this
> ...
> I will dig into it now, to find and fix it, and release a new PicoLisp 
> version.

Done! I found the culprit in the '*/' function!

A new version is available as always in

   https://software-lab.de/picoLisp.tgz

Thanks again!
♪♫ Alex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Alexander Burger]

Hi Jimmie,

thanks for your long feedback and sharing your experiences!

> I have spent a fair amount of the last 4 days playing with PicoLisp. I

Yess. From your code I see that you master PicoLisp already quite well! I
suspect that you gave up just a little bit too early.


> : (scl 12)
> -> 12
> : (*Scl)
> Segmentation fault (core dumped)

Haha, right. Calling (*Scl) is a prefect way to segfault. Think about what it
means: It calls a *function* starting in memory at address 12!


HOWEVER! The segfaults you observed in your program are NOT your fault! You
indeed found a bug in the bignum functions of PicoLisp, causing a crash upon a
certain combination of numeric arguments.

Strange that this was not detected earlier, I used a lot of test routines with
random numbers.

I cound not locate the exact location of the bug yet. It is a Heisenbug, because
it only occurs if the garbage collector runs in the right moment. I know this
because it all runs well if you call 'gc' *before* the test, e.g.

   (gc 700)
   (doit)

I will dig into it now, to find and fix it, and release a new PicoLisp version.
Thanks for finding it!


As you spent already so much time on it, I feel that I should try it myself.

I rewrote parts of it to be more PicoLisp-like, as you violate some of the
PicoLisp programming rules and styles. I won't comment on the details, but paste
my own version below.

The new version is about 150 times faster. The main reason is that you used
'nth' to index into long lists again and again. Here on my notebook it
finishes the 100 reps in one and a half minutes:

   $ time ./pil x.l +
   *Scl: 12
   createlist
   "loop1"
   87.144 sec
   loop2
   nsum: 11257.349310772499
   navg: 0.390880184402
   4.093 sec
   91.250 sec
   nsum: 11228.585386471924
   navg: 0.389881437030

   real1m31.628s
   user1m31.308s
   sys 0m0.400s


> A successful 100 rep run should give an
> nsum: 11322.307098752284and
> navg: 0.393135663151121within acceptable floating point differences.

Note that I get slightly different results, because I use '*/' instead of '/' in
the 'average' function. I believe that this is more correct, as '*/' rounds the
result.


Now let me start the bug hunt.

♪♫ Alex


PS: Here is my code:

(scl 12)

(de average (L)
   (*/ (sum prog L) (length L)) )

(de normalize (N)
   (let NN (if (=0 N) 0.000123456789 N)
  (while (<= NN 0.0001)
 (setq NN (* 10 NN)) )
  (while (>= NN 1.0)
 (setq NN (*/ NN 10)) )
  NN ) )

(de createlist (Lsize)
   (make
  (let I 0
 (do Lsize
(link (normalize (inc 'I 1.0))) ) ) ) )

(de loop1calc (I J N)
   (let V (*/ N (+ I N) (- J N) 0.1234567 `(* 1.0 1.0 1.0))
  (normalize (*/ V V V `(* 1.0 1.0)) ) ) )

(de loop2calc (I J N)
   (normalize
  (*/ N
 (+ J 1.0)
 (+ N N N)
 0.1234567
 `(* 1.0 1.0 1.0) ) ) )

(de loopN (Fun Lst Reps)
   (let I 1.0
  (do Reps
 (let J 0
(map
   '((L)
  (set L
 (Fun I (inc 'J 1.0) (car L)) ) )
   Lst ) )
 (inc 'I 1.0) ) )
   (setq
  *Nsum (sum prog Lst)
  *Navg (average Lst) ) )

(de loop1 (Lst Reps)
   (loopN loop1calc Lst Reps) )

(de loop2 (Lst Reps)
   (loopN loop2calc Lst Reps) )

(de doit ()
   (prinl "*Scl: " *Scl)
   (bench
  (let Reps 100
 (prinl "createlist")
 (let L (createlist (* 60 24 5 4))
(println "loop1")
(bench (loop1 L Reps))
(prinl "loop2")
(prinl "nsum: " (format *Nsum *Scl))
(prinl "navg: " (format *Navg *Scl))
(bench (loop2 L Reps)) ) ) )
   (prinl "nsum: " (format *Nsum *Scl))
   (prinl "navg: " (format *Navg *Scl)) )

(gc 700)
(doit)
(bye)

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Jimmie Houchin]

I would like to thank all that helped with questions. My apologies for 
the very, very, very long message below. I tried to detail my recent 
experiences.


I have spent a fair amount of the last 4 days playing with PicoLisp. I 
thought I would give it a try even though it is quite primitive feeling 
to a person who is used to the richness of a Smalltalk. But it brings 
its own benefits. Small, efficient, the ability to understand the 
language and implementation. It seems for now that I am not at a level 
to use PicoLisp well. And I don't have the time to reach that point at 
the moment. But I don't like just appearing and disappearing without 
giving the wonderful people here the benefit of learning from my 
experience. Unfortunately it will be based on probably unreproducible 
experiences. Hopefully this will help someone.


The app I was exploring does a lot of floating point math. Simple 
calculations, but lots of them and repetitively. The fixpoint system of 
PicoLisp has been quite painful unfortunately.


I have a micro-benchmark that I wrote to test languages to see how they 
compare. And yes, I understand micro-benchmarks do not tell all about a 
language. But this does represent reasonably the domain I am exploring. 
I have explored with this benchmark C/C++, Java, Kotlin, Lua, LuaJit, 
Python, Python with Numpy, Nim, Pharo (Smalltalk), Dart all on my 
reasonably fast i7 laptop. They range in performance from about 2.4 
minutes to over 6 hours to perform.


I ported this to PicoLisp and have experienced much pain. The port was 
not straightforward. And I have yet to get it to work. The benchmark is 
written in a way which all language should give the exact same results 
at the end of the test.


One of my big problems is that PicoLisp has continually segfaulted on me 
for unknown reasons. Something as simple as this has segfaulted.


jimmie@squirrel:~/Dev/languagetest$ pil +
: (version)
17.5.16
-> (17 5 16)
: (scl 12)
-> 12
: (*Scl)
Segmentation fault (core dumped)

I will readily admit that when operating on my ported code that it could 
be my fault. I readily admit my code at any of the stages of its 
development could be broken and cause segfaults. However, when I broke 
it down in to smaller and smaller pieces in order to test out each 
piece, I have the above type problem of segfaults.


I will admit that I am out of my element when developing with a file 
based language. I do not know how to use debuggers or learn how to 
examine a core dump. Pharo delivers a live experience. Segfaults are 
rare and considered to be bad and should never happen. When they do it 
is attempt to reproduce them to fix either the vm or image. User coding 
errors should never cause a crash in Pharo. They is its model and the 
common one of Smalltalks. I am not trying to say that PicoLisp should be 
the same. Just explaining my experience.


I had trouble getting my code to run. When I did, it did not give the 
same results as any of the other implementations. So I began to reformat 
so that I could explore to find the problem and fix. I figure it has to 
do with the fixpoint verse floating point.


Dealing with fixpoint some conclusions.

Set *Scl as soon as possible.
Set *Scl for the smallest precision that will satisfy your requirements.
*Scl size has significant impact on performance and memory.

As frequently as possible, every calculation that sets a variable if 
possible. Have your function restore everything to the desired *Scl 
precision. Failure to do so affects performance and memory.


Natural integers and fixpoint do not play well with each other. In my 
benchmark I have loops which I use the index of the loop in the 
calculations. I had to insure that I did (* index 1.0) every time. 
Anytime I encounter a natural integer from some source, this needs to be 
done. If not, you will not get the proper results. This is stated in the 
documentation. But it does require additional effort to insure that 
every outside source of data which might provide an integer will have to 
be sanitized to work. This is something that feels unnatural in a 
dynamically typed language.


I guess at some point you would become accustomed to insuring that you 
do all of the above. But it just opens the door for simple mistakes or 
oversights when dealing with integers, fixpoint, floating point.


However the segfault problem is really stopping me from even attempting 
to overcome these issues. Below I have my code as it currently stands. 
My apologies if it is really ugly. I haven't yet learned Lisp. I have 
run the code for 1 rep sometimes successfully. The original test runs 
for 100 reps. It has never done so. It segfaults every time at 3 and 
above. Memory has been a constant 3.6mb ram. It doesn't grow and run out 
of memory. It just dies. :(


Below is with one rep.

jimmie@squirrel:~/Dev/languagetest$ pil picoLisp-9.l +
: (doit)
"*Scl: " 12
"createlist"
"loop1"
25.360 sec
"loop2"
"nsum: " "11242.949400372845"
"navg: " 

Re: Floating Point numbers vs Fixpoint numbers

[Alexander Burger]

Hi Jimmie,

> What I didn't see in any of the examples is this
> 
> : (format (*/ 9.9 9.789 9.56789 `(* 1.0 1.0)) *Scl)
>-> "927.234744579000"

Good idea! I added this example to the reference of '*/'

♪♫ Alex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Jimmie Houchin]

Hello,

Thanks for all the help. It is a little more complicated than in 
languages with support for floating point, but it appears manageable. I 
think I am slowly wrapping my mind around it.


What I didn't see in any of the examples is this

: (format (*/ 9.9 9.789 9.56789 `(* 1.0 1.0)) *Scl)
   -> "927.234744579000"

Where you are using (* 1.0 1.0) for the divisor. I had simply used 1.0 
as in the examples, but because I had multiple values being multiplied I 
need to adjust the value of the divisor as you did. This is what I did 
not find in the examples is the divisor being adjusted accordingly to 
the number of values multiplied. That does fix it in this simple example.


Thanks again for yours and everyone's help. And thanks for the 
suggestion of the flight simulator.



Jimmie



On 07/12/2017 02:02 PM, Alexander Burger wrote:

Hi Jimmie,

the key is to use the '*/' function for both multiplication and division.
'*' is not very useful here.


: (format (* 9.9 9.789 9.56789) 20)
-> "927234744579000."

Instead, try

: (scl 20)
-> 20

: (format (*/ 9.9 9.789 9.56789 `(* 1.0 1.0)) *Scl)
-> "927.234744579000"

or

: (round (*/ 9.9 9.789 9.56789 `(* 1.0 1.0)))
-> "927.235"

: (round (*/ 9.9 9.789 9.56789 `(* 1.0 1.0)) 7)
-> "927.2347446"



So in the example below I would have to track the number of arguments to the
* function. Then multiple that number against the current Scl value. In the

Yes. Perhaps you could look at the flight simulator in "misc/rcsim.l" in the
PicoLisp distribution. It defines a read macro MUL to keep track of the number
of multiplications.

♪♫ Alex




--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Alexander Burger]

Hi Jimmie,

the key is to use the '*/' function for both multiplication and division.
'*' is not very useful here.

> : (format (* 9.9 9.789 9.56789) 20)
> -> "927234744579000."

Instead, try

   : (scl 20)
   -> 20

   : (format (*/ 9.9 9.789 9.56789 `(* 1.0 1.0)) *Scl)
   -> "927.234744579000"

or

   : (round (*/ 9.9 9.789 9.56789 `(* 1.0 1.0)))
   -> "927.235"

   : (round (*/ 9.9 9.789 9.56789 `(* 1.0 1.0)) 7)
   -> "927.2347446"


> So in the example below I would have to track the number of arguments to the
> * function. Then multiple that number against the current Scl value. In the

Yes. Perhaps you could look at the flight simulator in "misc/rcsim.l" in the
PicoLisp distribution. It defines a read macro MUL to keep track of the number
of multiplications.

♪♫ Alex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Christophe Gragnic]

On Wed, Jul 12, 2017 at 8:36 PM, Jimmie Houchin  wrote:
>
> I didn't know if PicoLisp provided a solution without complicating every
> function which uses multiplication and division.

Yes, the */ function:
http://software-lab.de/doc/ref_.html#*/
I think you just have to provide 1.0 as the last param.


chri

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Alexander Burger]

On Wed, Jul 12, 2017 at 08:05:42PM +0200, Aatos Heikkinen wrote:
> I´ve found ´format´ and ´round´ functions quite helpful, see
> https://the-m6.net/blog/fixed-point-arithmetic-in-picolisp.html

Yes, this article describes it very well.

Especially, it explains Jimmie's issues with multiplication (divide by 1.0
thereafter) and division (multiply with 1.0 before it) to adjust the result.

♪♫ Alex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Jimmie Houchin]

Yes, I understand. But not without complicating the calculation to keep 
track of the number of times I have done multiplication in the current 
result.


Formating with current scale does not work.

: (format (* 9.9 9.789 9.56789) 20)
-> "927234744579000."

So in the example below I would have to track the number of arguments to 
the * function. Then multiple that number against the current Scl value. 
In the below would give me 3 * 20 giving 60 to scale the format. Is that 
the best way to handle it? What if I have a a few dozen calculations 
with multiples of arguments. Then do I do

(format num 5)   ?
And then significantly truncate the result to get the Scl number of 
significant digits I wanted to track?


(format (* 9.9 9.789 9.56789) 60)
-> "927.234744579000"

(round (* 9.9 9.789 9.56789))
-> "9,272,347,445,790,000,000,000,000,000,000,000,000,000,000.000"

The decimal is not in the correct place.

I didn't know if PicoLisp provided a solution without complicating every 
function which uses multiplication and division.


Thanks for the reply.

Jimmie


On 07/12/2017 01:05 PM, Aatos Heikkinen wrote:
I´ve found ´format´ and ´round´ functions quite helpful, see 
https://the-m6.net/blog/fixed-point-arithmetic-in-picolisp.html


On 12 Jul 2017 18:52, "Jimmie Houchin" > wrote:


Hello,

I am trying to understand something about PicoLisp and Fixpoint
numbers.

I am writing an app and would consider PicoLisp should I get my
head around Lisp. But I do not understand how to use numbers.

I use a lot of floating point numbers and lots of calculations.
From simple experiments it seems that the numbers and math appear
to be accurate and correct. However I have no understanding of how
to present a final result formatted correctly.

Example:

(setq *Scl 5) ;; or could be 10 ...

(* 0.9 0.0009)

-> 81

>From another language: 0.81

or:

(setq *Scl 20)

(* 9.9 9.789 9.56789)

-> 927234744579000

>From another language 20 decimal points printed after converting
to floating point:

927.23474457900010747835

The math looks fine as far as these simple examples go. But if I
do several to dozens of different calculations with floating point
numbers with unknown values until streamed to the app from some
source. How do I know where the decimal point really belongs in
order to format correctly for human use? Is it possible?

I personally do not have a problem with fixpoint for internal use,
as that is simply an implementation issue. However I do need to
convert back to the best floating point representation for display
or storage.

Any help in understanding would be greatly appreciated.

Thanks.

Jimmie

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de

?subject=Unsubscribe

Re: Floating Point numbers vs Fixpoint numbers

[Aatos Heikkinen]

I´ve found ´format´ and ´round´ functions quite helpful, see
https://the-m6.net/blog/fixed-point-arithmetic-in-picolisp.html

On 12 Jul 2017 18:52, "Jimmie Houchin"  wrote:

> Hello,
>
> I am trying to understand something about PicoLisp and Fixpoint numbers.
>
> I am writing an app and would consider PicoLisp should I get my head
> around Lisp. But I do not understand how to use numbers.
>
> I use a lot of floating point numbers and lots of calculations. From
> simple experiments it seems that the numbers and math appear to be accurate
> and correct. However I have no understanding of how to present a final
> result formatted correctly.
>
> Example:
>
> (setq *Scl 5) ;; or could be 10 ...
>
> (* 0.9 0.0009)
>
> -> 81
>
> From another language: 0.81
>
> or:
>
> (setq *Scl 20)
>
> (* 9.9 9.789 9.56789)
>
> -> 927234744579000
>
> From another language 20 decimal points printed after converting to
> floating point:
>
> 927.23474457900010747835
>
> The math looks fine as far as these simple examples go. But if I do
> several to dozens of different calculations with floating point numbers
> with unknown values until streamed to the app from some source. How do I
> know where the decimal point really belongs in order to format correctly
> for human use? Is it possible?
>
> I personally do not have a problem with fixpoint for internal use, as that
> is simply an implementation issue. However I do need to convert back to the
> best floating point representation for display or storage.
>
> Any help in understanding would be greatly appreciated.
>
> Thanks.
>
> Jimmie
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>