oldk1331 wrote:
>
> On Thu, Apr 19, 2018 at 1:05 AM, Waldek Hebisch
> <[email protected]> wrote:
> > oldk1331 wrote:
> >>
> >> On Mon, Apr 16, 2018 at 9:15 PM, Waldek Hebisch
> >> <[email protected]> wrote:
> >> > AFAICS several patches make code more complicated, I am not
> >> > shure if we want such changes.
> >>
> >> Yes, some patches make code longer, but not necessarily more
> >> complicated. I use the most natural algorithm according to FR's
> >> Rep: most functions takes 2 sorted list as arguments, then the
> >> function body loops over them, doing computations (on exponents
> >> and flags) and deduplicating items with same factors.
> >>
> >> You will see that after my patches, 'exquo', '=', 'gcd', '*'
> >> all have similar structures. Also, this explicit loop is required
> >> to achieve O(N) complexity instead of O(N*log(N)) or worse.
> >
> > Well, in actual use I typically see number of factors smaller than 10.
> > Do you have any application in mind that requires large number of
> > factors?
>
> I don't have any applications in mind other than artificial ones.
> Still, users may call Factored directly with big arguments.
There is a lot of things in FriCAS that could be improved and
users _may_ have some benefit. But if we spend time on things
with marginal benefits we _surely_ will miss things with bigger
impact. As a little example we have a few asymptiticaly fast
algortitms and data structures. But we miss several popular
ones like red-black trees. In slightly different spirit,
in U32VectorPolynomialOperations we have reasonably fast
artitmetic for modular polynomials. It uses quadratic
algorithms but is significantly faster than other implementations
when it matters, that is for degress below 100. Note that
this implementation does not support algebraic extensions.
If we had algebraic extensions it could be used to speed up
several other algortihms. In case of Groebner bases packing
polynomials into arrays can lead to large speedups (probably
of order 10 to 100) for important special cases. But new code
takes time to write and test so this waits for resources.
> >> Can I merge all these patches? I would prefer to merge them
> >> each as a individual patch.
> >
> > What do you really want? I wrote about batching the patches,
> > now you want them separately?
> >
> > As I wrote 0001 can go in and should go as separate patch. 0002 and
> > 0003 are really single patch, splitting them is artificial and
> > confusing.
> > --
> > Waldek Hebisch
> >
>
> What I meant is to commit them in sequence, so that commit history
> is clear. 0002 and 0003 should be merged, 0008 and 0010 can be
> merged, the rest should be separate commits so that the commit
> history is atomic and clear.
Separate commits means separate change log entries and separate
testing. If I were doing this probably there would be three
patches: one for renaming (trivial codewise, but touches a lot
of files) one for rewrite to fr.spad and one (0009) for NNI change.
However, that is not critial issue. I encourage you to think
in terms of bigger chunks of code, but if you want them separate,
then go on (but merging 0002 and 0003).
P.S. More generaly, what I write may sound harsh, but
critique is crucial for improvement. I appreciate work
that you are doing.
--
Waldek Hebisch
--
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 from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
