While evaluating some Fourier cosine transforms, I recognized that (for
instance) the integral
-- integrate(cos(x*y)/sqrt(x),x=0..%plusInfinity)
gives a wrong value:
+---+
\|%pi
(1) --
+---+
+-+ |2 y
\|2 |---
\|%pi
On 06/11/2018 03:34 PM, Waldek Hebisch wrote:
> I think that we should not expose MathMLFormat, ScriptFormulaFormat,
> TexFormat and TexmacsFormat. AFAICS TexFormat1 has to be
> exposed to fulfil its role, so probably should be exposed.
Although my version of TexFormat can be used to adapt the
I agree.
On Mon, Jun 11, 2018 at 9:34 PM, Waldek Hebisch
wrote:
> I think that we should not expose MathMLFormat, ScriptFormulaFormat,
> TexFormat and TexmacsFormat. AFAICS TexFormat1 has to be
> exposed to fulfil its role, so probably should be exposed.
>
> Opinions?
>
> --
>
+1
On Mon, Jun 11, 2018 at 9:34 AM, Waldek Hebisch
wrote:
> I think that we should not expose MathMLFormat, ScriptFormulaFormat,
> TexFormat and TexmacsFormat. AFAICS TexFormat1 has to be
> exposed to fulfil its role, so probably should be exposed.
>
> Opinions?
>
> --
>
On Mon, Jun 11, 2018 at 8:17 AM, oldk1331 wrote:
>>> The grammar for 'reduce': "func"/[args]
>>> is not only very strange, but also not applicable in interpreter.
>>>
>>> I don't think it's worth the effort that compiler supports this grammar,
>>> because it should be easilly replaced by
On Sun, Jun 10, 2018 at 12:55 PM, Prof. Dr. Johannes Grabmeier privat
wrote:
> Hi all,
>
> have added sqrt for prime fields, perhaps for next release.
>
> (1) -> )r sqrtpf
> ..
+1 Thank you.
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer
I think that we should not expose MathMLFormat, ScriptFormulaFormat,
TexFormat and TexmacsFormat. AFAICS TexFormat1 has to be
exposed to fulfil its role, so probably should be exposed.
Opinions?
--
Waldek Hebisch
--
You received this message because you are
OK for the 3 'optimize' patches.
>
> A similar optimization in vector.spad:
>
> optimize 'same?' in DirectProduct
>
>
> diff --git a/src/algebra/vector.spad b/src/algebra/vector.spad
> index a166f394..a18de376 100644
> --- a/src/algebra/vector.spad
> +++ b/src/algebra/vector.spad
> @@ -386,7
oldk1331 wrote:
>
> function 'find' is only meaningful for finiteAggregate
If you _know_ that it will find something it also makes sense
for infinite aggregates. Of course in infinite case
"failed" is meaningless, but it is reasonable to keep
uniform interface.
--
A similar optimization in vector.spad:
optimize 'same?' in DirectProduct
diff --git a/src/algebra/vector.spad b/src/algebra/vector.spad
index a166f394..a18de376 100644
--- a/src/algebra/vector.spad
+++ b/src/algebra/vector.spad
@@ -386,7 +386,7 @@
if R has BasicType then
same?
optimize 'last' in URAGG
diff --git a/src/algebra/aggcat.spad b/src/algebra/aggcat.spad
index 822a0178..de4666ff 100644
--- a/src/algebra/aggcat.spad
+++ b/src/algebra/aggcat.spad
@@ -1508,8 +1508,15 @@
k
last(x, n) ==
- n > (m := #x) => error "index out of range"
-
optimize 'removeDuplicates!' in ListAggregate
diff --git a/src/algebra/aggcat.spad b/src/algebra/aggcat.spad
index 58c48445..64fae13e 100644
--- a/src/algebra/aggcat.spad
+++ b/src/algebra/aggcat.spad
@@ -2380,8 +2380,7 @@
removeDuplicates! l ==
p := l
while not
function 'find' is only meaningful for finiteAggregate
diff --git a/src/algebra/aggcat.spad b/src/algebra/aggcat.spad
index e51ad717..c6adb24e 100644
--- a/src/algebra/aggcat.spad
+++ b/src/algebra/aggcat.spad
@@ -180,10 +180,10 @@
++ \spad{construct([x, y, ..., z])} returns the collection
>> The grammar for 'reduce': "func"/[args]
>> is not only very strange, but also not applicable in interpreter.
>>
>> I don't think it's worth the effort that compiler supports this grammar,
>> because it should be easilly replaced by "reduce(func, args)",
>> so I want to remove this grammar
Ralf Hemmecke wrote:
>
> > ATM "func"/[args] notation has one big advantage: it does not create
> > an intermediate list. So it is more efficient than 'reduce(func, args)'
> > variant. Supporting it in compiler in a sense is almost trivial:
> > most of code is present anyway to support '[i for
> ATM "func"/[args] notation has one big advantage: it does not create
> an intermediate list. So it is more efficient than 'reduce(func, args)'
> variant. Supporting it in compiler in a sense is almost trivial:
> most of code is present anyway to support '[i for i in l]' construct.
The syntax
oldk1331 wrote:
>
> >>
> >> Replace '"append"/' with 'concat'
> >>
> >> https://github.com/oldk1331/fricas/commit/f4909fd49add27b006db4e11476e9071a58ab680.patch
> >
> > Why?
> >
> >> Use 'gcd/lcm' instead of 'reduce'
> >>
> >>
17 matches
Mail list logo
