On Thu, Feb 18, 2021 at 04:11:04PM -0800, Tobias Neumann wrote:
> > That is consequence of IEEE rules about signed zero and precedence rules:
>
> Now that is a subtle and interesting phenomenon.
>
> >From that point of view everything is consistent indeed. But in practice
> I think that one
That was the point I was trying to make: whether you use ^: ( %,
Fraction(Integer)) -> %
or ^: (%, %) -> % should at least be consistent within numerical precision
for Complex(DoubleFloat).
And I expect consistency betwen Float and DoubleFloat, so that one can swap
them and get the same
results
Not at all ;) It shows once more that DF ought to have no place in a CAS. DF is
a source of confusion on its own. I'd use Interval(Float) or Float, if need be
...
BTW 0.5 and 1/2 have different types. The interpreter is sometimes too
broadminded.
On 19.02.2021 01:17, Tobias Neumann wrote:
>
On Fri, Feb 19, 2021 at 12:56:58AM +0100, Ralf Hemmecke wrote:
> On 18.02.21 18:38, Waldek Hebisch wrote:
> > On Thu, Feb 18, 2021 at 06:36:57PM +0100, Waldek Hebisch wrote:
> >> See attached file and Aldor compilation report (I sent it before
> >> but I include it in case it got lost).
>
>
Maybe this is most convincing:
(3) -> ((-1) :: Complex(DoubleFloat))^(0.5)
(3) 6.123233995736766e-17 - %i
Type:
Complex(DoubleFloat)
(4) -> ((-1) :: Complex(DoubleFloat))^(1/2)
(4) %i
> That is consequence of IEEE rules about signed zero and precedence rules:
Now that is a subtle and interesting phenomenon.
>From that point of view everything is consistent indeed. But in practice
I think that one easily runs into this issue. I would argue that you want
to be
able to swap
On 18.02.21 18:38, Waldek Hebisch wrote:
> On Thu, Feb 18, 2021 at 06:36:57PM +0100, Waldek Hebisch wrote:
>> See attached file and Aldor compilation report (I sent it before
>> but I include it in case it got lost).
Waldek,
I do not understand why you complain here.
On Thu, Feb 18, 2021 at 01:55:13PM -0800, Tobias Neumann wrote:
> Thank you. As it turns out, complex exponentiation (^ : % -> %) with a
> Complex(DoubleFloat) exponent is also broken:
>
> Good:
> (7) -> (-1.0 :: Complex(Float))^(0.5)
>
>(7) 0.2022266248_7959507324 E -20 + %i
>
> presumably you didn't notice the different sign for the imaginary part?
Oh, no no. I did see that. Why would that be a problem?
Yes, I agree, from the name Float and DoubleFloat one might think that
these two domains are somehow related. But when you consider them as
separate domains both
Hi Ralf,
presumably you didn't notice the different sign for the imaginary part?
It's just the same issue that was present for the fractional integer
exponent.
I think that this should be handled consistently so that the cut is along
the negative real axis,
i.e. sqrt(-x + %i*0) -> %i*sqrt(x)
Being a bit nasty... ;-)
Why do you say it is broken?
Modulo an error bound of 10^(-15) it looks OK.
Do you expect exact values when you compute with floating point numbers?
Ralf
(7) -> a := (-1.0 :: Complex(Float))^(0.5)
(7) 0.2022266248_7959507324 E -20 + %i
Thank you. As it turns out, complex exponentiation (^ : % -> %) with a
Complex(DoubleFloat) exponent is also broken:
Good:
(7) -> (-1.0 :: Complex(Float))^(0.5)
(7) 0.2022266248_7959507324 E -20 + %i
Type:
Complex(Float)
Broken:
(6)
> Yes, safer code is among expected benefits. Concerning speed: AFAIK
> there is no inlining between Aldor and Spad code.
Yes, THAT is a big problem. I don't know if Peter has a solution for this.
> So if you use Spad types from Aldor (via interface) all operations
> would go via function
I'll take a look at your example; it's possible that there's some
unreleased changes that will help.
Does that test file also show a factor of 10 slowdown?
I had also started a bottom up translation of SPAD to Aldor code, but
stopped for some reason. If any one is interested in resurrecting
this
On Thu, Feb 18, 2021 at 05:46:40AM -0800, Ralf Hemmecke wrote:
> Hello,
>
> this continues a thread
> https://groups.google.com/g/fricas-devel/c/zSamEbPXRwQ/m/TmHfWltgBAAJ
> that I started in 2019 and is connected to this thread about random numbers.
>
On Thu, Feb 18, 2021 at 06:36:57PM +0100, Waldek Hebisch wrote:
> See attached file and Aldor compilation report (I sent it before
> but I include it in case it got lost).
Sorry, sent previous message too fast, without attachements.
--
Waldek Hebisch
--
You
On Thu, Feb 18, 2021 at 08:24:08AM +0100, Ralf Hemmecke wrote:
> > There were plans in early period of open source Axiom. AFAIK there
> > are no visible results. There would be some benefit if one could
> > compile algebra using Aldor. Relatively recently I did a little
> > experiment and it
>> Have there been thoughts or plans of porting the FriCAS SPAD code
>> completely to Aldor?
That were a good plan. What is missing is manpower.
>> As far as I can tell Aldor is unmaintained, so this might not be a
>> good idea in the long run.
Not completely true. Peter Broadbery is looking
Hello,
this continues a thread
https://groups.google.com/g/fricas-devel/c/zSamEbPXRwQ/m/TmHfWltgBAAJ
that I started in 2019 and is connected to this thread about random numbers.
https://groups.google.com/g/fricas-devel/c/C2YxwxnnSMs/m/DKkMJKWTBAAJ
I could now use Qian's suggestion
)lisp (setf
19 matches
Mail list logo
