oldk1331 wrote:
>
> On Sun, Jun 24, 2018 at 10:42 PM, Waldek Hebisch
> <[email protected]> wrote:
> > oldk1331 wrote:
> >>
> >> But for 'min'/'max', the 'map' paradigm is not very suitable.
> >> The appropriate way is to use 'reduce'.
> >
> > Well, one can use imperative 'map' to implement 'reduce'.
> > The point is that 'map' is the only place which _must_
> > know how to iterate over an aggregate. Given 'map'
> > all other kinds of iteration may be build in generic
> > way.
>
> You can use 'map' to implement 'reduce', but that's not the
> optimized way. In your version, you used "Union" and "Reference",
> that's wrapped twice, so your version has many unnecessary
> memory accesses. I didn't say this in previous thread because
> I though this was obvious...
Yes, it is not optimised. But this is default implementation
and speed here does not matter much. Note that "Union" could
be easily eliminated -- I did not to this to keep things
simpler and cleaner. If you want real speed
you need specialised version, either by hand or via compiler
optimisation. Now, in principle compiler could optimise this
version to nearly optimal code, but currently (and in near
future) Spad compiler does not contain needed transformations.
But the point is that this version while not optimised is
optimisable. And when doing optimisation by hand one should
do them in places where it matters, and default implementation
is almost always the wrong place to do them (with current
compiler you can frequently gain speed just by copying code
to different place). Let me remind you about old 90-10 rule:
90% of runtime usually goes to less than 10% of code. So
in main 90% we want to have as regular code as possible
with little duplication. In the remaining 10% we do tricks
(including creating specialised versions) to get better speed.
> >> Can I commit my original patch?
> >
> > If you insist yes, this is too small thing to make much
> > fuss about it. However, in general you should note
> > that rewriting code against wish of original author
> > is not nice thing. Question of style are hard to
> > judge objectively and may lead to heated debates.
> > Simple rules like "do not change code without
> > strong reason" and "in doubt original author is
> > right" help to avoid many problems.
>
> I hope you can understand my performance concern
> (and aesthetic reason: it's strange to use 'map' with
> a side effect function).
Imagine that you want to write an aggregate domain with
constraint that only one functions knows how to walk
around it, other functions should be generic. Current
solutions in algebra is to have 'parts' as core primitive
and build other on it. But if you want to avoid memory
allocation, then imperative primitive (that is using side
effects) is natural choice.
--
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.
