Fantastic. Thanks Alex!
On Sun, Dec 12, 2021 at 4:33 AM Alexander Burger
wrote:
> Hi Kevin, hi all,
>
> On Thu, Dec 09, 2021 at 09:40:51PM +0100, Alexander Burger wrote:
> > The conversion function can easily detect the type (short or big) when
> > converting to float, and overflow to bignum if
Awesome, thanks!
On Sun, Dec 12, 2021 at 9:25 AM Alexander Burger
wrote:
> On Sun, Dec 12, 2021 at 10:25:46AM +0100, Alexander Burger wrote:
> >: (pow 100.0 100.0) # This did not work
> >->
>
On Sun, Dec 12, 2021 at 10:25:46AM +0100, Alexander Burger wrote:
>: (pow 100.0 100.0) # This did not work
>->
>
Hi Kevin, hi all,
On Thu, Dec 09, 2021 at 09:40:51PM +0100, Alexander Burger wrote:
> The conversion function can easily detect the type (short or big) when
> converting to float, and overflow to bignum if necessary when converting back
> to PicoLisp numbers.
>
> This should really be fixed ...
On Thu, Dec 09, 2021 at 03:09:41PM -0500, Kevin Ednalino wrote:
> I also found the issue was brought up previously:
> https://www.mail-archive.com/picolisp@software-lab.de/msg10799.html
Oh, yes, I completely forgot that thread ;)
> I agree with keeping the spec small (in regards to the most
Ah, I see.
I also found the issue was brought up previously:
https://www.mail-archive.com/picolisp@software-lab.de/msg10799.html
I agree with keeping the spec small (in regards to the most recent
discussion), but possibly another token to identify bignum returns?
-Kevin
On Thu, Dec 9, 2021 at
Hi Kevin,
> found some of the intermediate
> values (the determinate) were smaller than 1e6 (my scl is 6) and so my
> thought is to increase the scale to increase the precision.
The problem are not the small numbers, but the larger ones.
I think it is a design flaw in the float/double interface
My issue is with relatively small floating point values in the context of
OpenGL. More specifically, I ported a matrix inverse calculation and it was
producing significantly different results than the C counterpart[1] (which
was correct and matched the rendering). I found some of the intermediate
On Thu, Dec 09, 2021 at 09:21:44AM -0500, Kevin Ednalino wrote:
> but I will review the IEEE standard.
It is not directly an IEEE issue.
On Thu, Dec 09, 2021 at 03:36:48PM +0100, Alexander Burger wrote:
> Yes, the number needs to be divided and rounded (with '*/') by the proper
> quotient of
On Thu, Dec 09, 2021 at 09:21:44AM -0500, Kevin Ednalino wrote:
> That was my other thought. I guess I was expecting the number to be rounded
> or truncated, but I will review the IEEE standard.
Yes, the number needs to be divided and rounded (with '*/') by the proper
quotient of both scales
That was my other thought. I guess I was expecting the number to be rounded
or truncated, but I will review the IEEE standard.
-Kevin
On Thu, Dec 9, 2021 at 2:44 AM Alexander Burger wrote:
> Hi Kevin,
>
> > I'm getting strange results with the following:
> > ...
> > : (scl 16)
> > -> 16
> > :
Hi Kevin,
> I'm getting strange results with the following:
> ...
> : (scl 16)
> -> 16
> : (setq Ptr (%@ "malloc" 'P 4))
> -> 9674752
> : (struct Ptr NIL (list -1.0 1280.0))
> -> NIL
> : (format (car (struct Ptr '(-1.0 . 1))) *Scl)
> -> "-103.5058256155770880"
> ...
> The value seems completely
Hello,
I'm getting strange results with the following:
: (version)
21.11.17
-> (21 11 17)
: (scl 16)
-> 16
: (setq Ptr (%@ "malloc" 'P 4))
-> 9674752
: (struct Ptr NIL (list -1.0 1280.0))
-> NIL
: (format (car (struct Ptr '(-1.0 . 1))) *Scl)
-> "-103.5058256155770880"
: (struct Ptr (cons 'B 4))
13 matches
Mail list logo
