First, I found that default constructor, "construct", always
copy its argument, that's inefficient if there are lots of
elements. I propose a destructive constructor "construct!",
that by potentially modify its argument, to achieve better
performance.
The second one is a minor issue, bracket alre
I'm a little lost at the "preserve type" part,
can you give me an example that INFORM doesn't
preserve type and 'x = interpret(x::INFORM)' doesn't
hold true?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from
I have updated the patch:
https://github.com/oldk1331/fricas/commit/5d0a6c2dc30825d53ddeafac6d0df1df0edf42ce.patch
more efficient Rep for Queue and Dequeue
I use destructive operations in map, but I think it's correct.
I fixed a bug that 'construct' requires a copy of argument.
https://github.
Right, even with something like conctructorName,
dequeue! from Queue will not access to Dequeue.
Change the error to a generic one or leave it as it is,
which do you prefer?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To
> The point is that 'map' may make extra assumptions. For example
> OutputForm of polynomials is produced via 'map'.
I think, I did not speak about map with the signature
map: ((A->B), SomeStructure A) -> SomeStructure B
but of
map: (A->A , SomeStructure A) -> SomeStructure A
However, wh
>
> OK, I got what you meaning: speed regression.
>
> I'm not familiar with the test stuff, so I want to ask:
>
> I think src/input/ doesn't support speed comparison,
> so you compare *.output with previous ones manually?
I usually measure time to run the whole testsute (just
using Linux 'time'
Ralf Hemmecke wrote:
>
> > So both 'map' and 'map!' for Queue should work accoring to order in
> > the queue.
>
> Well, I think that map and map! should respect order, i.e.
>
> map(f, [a,b])
>
> should be
>
> [f(a), f(b)]
>
> and not
>
> [f(b), f(a)]
>
> I would let it unspecified (in
oldk1331 wrote:
>
> Interesting question: should map on Dequeue follow
> a order? If yes, then from top to bottom or the other
> way around?
The same as Queue.
--
Waldek Hebisch
--
You received this message because you are subscribed to the Google Groups
"FriCAS
Interesting question: should map on Dequeue follow
a order? If yes, then from top to bottom or the other
way around?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails fro
> So both 'map' and 'map!' for Queue should work accoring to order in
> the queue.
Well, I think that map and map! should respect order, i.e.
map(f, [a,b])
should be
[f(a), f(b)]
and not
[f(b), f(a)]
I would let it unspecified (in FriCAS) whether f(a) or f(b) is evaluated
first. In tha
OK, I got what you meaning: speed regression.
I'm not familiar with the test stuff, so I want to ask:
I think src/input/ doesn't support speed comparison,
so you compare *.output with previous ones manually?
--
You received this message because you are subscribed to the Google Groups
"FriCAS -
oldk1331 wrote:
>
> I was looking at polynomial remainder sequence related parts
> of FriCAS, and I find there are some improvement space.
>
> I'll use PRS for "polynomial remainder sequence", not to be
> confused with package PseudoRemainderSequence.
>
> 1. PRS parts in FriCAS:
> package PRS
oldk1331 wrote:
>
> One more discussion about the map:
>
> In Scheme, (map f ls) doesn't specify the order,
> f should be functional (non-destructive, no IO), thus
> the order doesn't matter. And it also opens the gate
> for parallel map optimization. On the other hand,
> (for-each f ls) follows
One more discussion about the map:
In Scheme, (map f ls) doesn't specify the order,
f should be functional (non-destructive, no IO), thus
the order doesn't matter. And it also opens the gate
for parallel map optimization. On the other hand,
(for-each f ls) follows the order and f considered
non-f
oldk1331 wrote:
>
> OK, so you think map should process from the first to the last?
> Previous Rep doesn't have a pointer to the end, right?
> You agree with this change mostly, right?
3*Yes.
--
Waldek Hebisch
--
You received this message because you are subscrib
OK, so you think map should process from the first to the last?
Previous Rep doesn't have a pointer to the end, right?
You agree with this change mostly, right?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe f
oldk1331 wrote:
> > changes order in which map processes elements. AFAICS classic version
> > which keeps pointer to the last element does not have this problem.
>
> I don't understand, what do you mean? what pointer?
You propose:
[| ,|]
| --> rear
|
v
front
with separate
> changes order in which map processes elements. AFAICS classic version
> which keeps pointer to the last element does not have this problem.
I don't understand, what do you mean? what pointer?
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer alg
oldk1331 wrote:
>
> (56) -> PositiveInteger has KONVERT(INFORM)
>
>(56) false
> Type:
> Boolean
> (57) -> queue([1,2,3])::INFORM
>
>Cannot convert the value from type Queue(PositiveInteger) to
> InputForm .
>
> (5
oldk1331 wrote:
>
> Currently the Rep of Queue is List, thus enqueue! an
> element into the end of list is O(n) not O(1):
Yes.
> So I changed the Rep, the patch is here for you to review.
> If this patch is OK, I'll do the similar change for Dequeue.
There is one thing which may be problematic:
20 matches
Mail list logo
