On Fri, 13 Mar 2020 at 20:10, Neven Sajko wrote:
>
> On Fri, 13 Mar 2020 at 18:13, Ralf Hemmecke wrote:
> >
> > Look at
> >
> > http://fricas.github.io/api/DoubleFloat.html
> >
> > You find:
> >
> > convert: % -> Float
> >
> > but not
> >
> > coerce: % -> Float
> >
> > This makes a difference
On Sat, 14 Mar 2020 at 00:07, Neven Sajko wrote:
> I am not 100% sure, but the idea is that x is exactly the number that
> I printf'd from Go to Fricas, and x::DoubleFloat is then exactly the
> input value that Go has.
To clarify, x itself is not directly important for anything, rather the binary
On Fri, 13 Mar 2020 at 23:12, Ralf Hemmecke wrote:
>
> > Thanks for the idea, that does seem to be the cleanest approach. But
> > I would have to benchmark the couple of different equivalent (?)
> > approaches to see which one is the best.
>
> ???
>
> If x::DoubleFloat::Float ~= x, then using floa
> Thanks for the idea, that does seem to be the cleanest approach. But
> I would have to benchmark the couple of different equivalent (?)
> approaches to see which one is the best.
???
If x::DoubleFloat::Float ~= x, then using float(m, e) is the only
correct way and certainly not equivalent to ot
On 13.03.2020 22:47, Neven Sajko wrote:
> On Fri, 13 Mar 2020 at 21:38, Kurt Pagani wrote:
>>
>> There must be something wrong :( The digits(15000) -> 0.686467020... can't be
>> true. Even with intervals: setting digits gives wrong results. BTW Julia and
>> CL
>> confirm more or less -0.94..
>
On Fri, 13 Mar 2020 at 22:08, Ralf Hemmecke wrote:
>
> > Binary64 has only limited bits in the mantissa, around 52, I think. Thus
> > it cannot represent every integer exactly, it has to "round" to the
> > nearest representable binary64 number.
>
> Yes, clear. If you want to use exact the same dat
> Binary64 has only limited bits in the mantissa, around 52, I think. Thus
> it cannot represent every integer exactly, it has to "round" to the
> nearest representable binary64 number.
Yes, clear. If you want to use exact the same data at input as Go, then
you should make sure that FriCAS sees ex
On Fri, 13 Mar 2020 at 21:56, Ralf Hemmecke wrote:
>
> As far as I can see this expression
>
> 1.461920290375737576933544899379e+31
>
> is the *integer*
>
> 14619202903757375769335448993790
>
> and not
>
> 14619202903757375769335448993792
>
> Maybe FriCAS conversion is wrong.
>
> Ralf
Binar
As far as I can see this expression
1.461920290375737576933544899379e+31
is the *integer*
14619202903757375769335448993790
and not
14619202903757375769335448993792
Maybe FriCAS conversion is wrong.
Ralf
--
You received this message because you are subscribed to the Google Groups
"Fr
On Fri, 13 Mar 2020 at 21:49, Neven Sajko wrote:
>
> On Fri, 13 Mar 2020 at 21:47, Neven Sajko wrote:
> >
> > On Fri, 13 Mar 2020 at 21:38, Kurt Pagani wrote:
> > >
> > > There must be something wrong :( The digits(15000) -> 0.686467020...
> > > can't be
> > > true. Even with intervals: setting
On Fri, 13 Mar 2020 at 21:47, Neven Sajko wrote:
>
> On Fri, 13 Mar 2020 at 21:38, Kurt Pagani wrote:
> >
> > There must be something wrong :( The digits(15000) -> 0.686467020... can't
> > be
> > true. Even with intervals: setting digits gives wrong results. BTW Julia
> > and CL
> > confirm mor
On Fri, 13 Mar 2020 at 21:38, Kurt Pagani wrote:
>
> There must be something wrong :( The digits(15000) -> 0.686467020... can't be
> true. Even with intervals: setting digits gives wrong results. BTW Julia and
> CL
> confirm more or less -0.94..
>
> (1) -> IFL==>Interval(Float)
> (2) -> interval
Yes, maybe there is something wrong. ;-)
But probably not with the sine implementation.
(14) -> 1.461920290375737576933544899379e+31::DoubleFloat::Float -
1.461920290375737576933544899379e+31
(14) 2.0
Ralf
On 3/13/20 10:38 PM, Kurt Pagani wrote:
> There must be something wrong :( The digits
There must be something wrong :( The digits(15000) -> 0.686467020... can't be
true. Even with intervals: setting digits gives wrong results. BTW Julia and CL
confirm more or less -0.94..
(1) -> IFL==>Interval(Float)
(2) -> interval(1.461920290375737576933544899379e+31)$IFL
(2) [0.1461920290_
> The issue manifests most clearly with huge values, for example: in the
> interpreter, with digits set to 15000 (a lower value should work, too),
> sin(1.461920290375737576933544899379e+31) evaluates
> to 0.68646702078634009753101826, while
> sin(1.461920290375737576933544899379e+31::DoubleFlo
On Fri, 13 Mar 2020 at 18:13, Ralf Hemmecke wrote:
>
> Look at
>
> http://fricas.github.io/api/DoubleFloat.html
>
> You find:
>
> convert: % -> Float
>
> but not
>
> coerce: % -> Float
>
> This makes a difference in interperter vs. compiler.
>
> Whereas for the interpreter the "::" notation is
Look at
http://fricas.github.io/api/DoubleFloat.html
You find:
convert: % -> Float
but not
coerce: % -> Float
This makes a difference in interperter vs. compiler.
Whereas for the interpreter the "::" notation is translatet into
"coerce", it is also allowed to try "retract" and "convert".
I know I already received plenty of help here, but I have reached an
impasse again: I have a package like this:
CommonNumericFunctions() : Exports == Implementation where
Exports ==> with
n_s : Float -> Float
Implementation ==> add
n_s(x : Float) : Float == (sin(x::DoubleFloa
On Thu, 12 Mar 2020 at 17:21, Waldek Hebisch wrote:
>
> On Tue, Mar 10, 2020 at 06:40:38PM +, Neven Sajko wrote:
> >
> > Messages about functions being compiled appear, and I can not force
> > them to appear preemptively. To be more specific, the situation is
> > like this: I define "erfc(x) =
On Tue, Mar 10, 2020 at 06:40:38PM +, Neven Sajko wrote:
>
> Messages about functions being compiled appear, and I can not force
> them to appear preemptively. To be more specific, the situation is
> like this: I define "erfc(x) == (1 - erf(x))" and only when I call,
> e.g., erfc(0.13) does th
On Tue, Mar 10, 2020 at 11:28:17PM +, Neven Sajko wrote:
>
> > > Another problem is that when I run fricas like so:
> > >
> > > fricas -nosman -eval ')set messages startup off'
> > >
> > > The startup messages appear anyway. Maybe the problem is that startup
> > > message is already printed wh
> Thank you, that seems to work. BTW erfc and erfi are different functions, see
> https://en.wikipedia.org/wiki/Error_function
Ooops... sorry. It seems that I looked too quickly over the code without
realizing the difference.
Ralf
--
You received this message because you are subscribed to the G
On Wed, 11 Mar 2020 at 06:08, Ralf Hemmecke wrote:
>
> This error indicates that the compiler does not know (yet) about that
> function. In other words, "erf" is in the FriCAS library, but it is not
> in scope for the compiler. So you have to make it know, by either
> putting
>
> import fr
This error indicates that the compiler does not know (yet) about that
function. In other words, "erf" is in the FriCAS library, but it is not
in scope for the compiler. So you have to make it know, by either
putting
import from FloatLiouvilianFunctions
right after the "add" line (or even
On Wed, 11 Mar 2020 at 00:11, Bill Page wrote:
>
> Perhaps you meant to write:
>
> )set output algebra off
> )set history off
> )set messages prompt none
> )set messages startup off
> )set messages type off
> )set messages any off
> digits 1
> outputFloating 25
> outputSpacing 0
> cbrt: (Float
On Tue, 10 Mar 2020 at 23:43, Ralf Hemmecke wrote:
...
> If it is an option for you then do something like this
>
> )abbrev package FOO Foo
> Foo: with
> cbrt: (Float) -> Float
> erfc: (Float) -> Float
> log1p: (Float) -> Float
> == add
> cbrt(x: Float): Float == (nthRoot(x, 3))
To ensure that the last line of output is written to the file you
should include the following two commands at the end of the input
file:
)set output algebra console
)quit
On Tue, Mar 10, 2020 at 8:11 PM Bill Page wrote:
...
> )cd /tmp
> )set output algebra on
> )set output algebra fricasComputa
Perhaps you meant to write:
)set output algebra off
)set history off
)set messages prompt none
)set messages startup off
)set messages type off
)set messages any off
digits 1
outputFloating 25
outputSpacing 0
cbrt: (Float) -> Float
erfc: (Float) -> Float
log1p: (Float) -> Float
cbrt(x) == (nt
On Tue, Mar 10, 2020 at 6:40 PM Neven Sajko wrote:
>
> Hi,
>
> I am trying to use Fricas programmatically/non-interactively. More
> specifically, I want to use it as an accurate real-numbers
> calculator, to check accuracy of some fixed-precision math libraries
> written in other languages.
I jus
> )set output algebra on
> )set output algebra fricasComputationsForGo
>
> But the algebra output is not being written to
> /tmp/fricasComputationsForGo.spout, or anywhere else I see, for that
> matter! The file instead just contains this, referring to itself:
>
>Algebra output will be writte
Hi Neven,
the same problem occurs when the FriCAS book is compiled.
What you see in the book is computed with the current version of FriCAS.
The .htex files only contain the input commands but not the output.
I use $ioHook to put some markers that enable me later to figure out
which part is what.
On Tue, 10 Mar 2020 at 19:41, Waldek Hebisch wrote:
>
> On Tue, Mar 10, 2020 at 06:40:38PM +, Neven Sajko wrote:
> > Hi,
> >
> > I am trying to use Fricas programmatically/non-interactively. More
> > specifically, I want to use it as an accurate real-numbers
> > calculator, to check accuracy o
On Tue, Mar 10, 2020 at 06:40:38PM +, Neven Sajko wrote:
> Hi,
>
> I am trying to use Fricas programmatically/non-interactively. More
> specifically, I want to use it as an accurate real-numbers
> calculator, to check accuracy of some fixed-precision math libraries
> written in other languages
Hi,
I am trying to use Fricas programmatically/non-interactively. More
specifically, I want to use it as an accurate real-numbers
calculator, to check accuracy of some fixed-precision math libraries
written in other languages.
The idea is to use, e.g., 1 digit precision and round to 25 after
34 matches
Mail list logo
