On 11 Mrz., 14:06, Bill Page <bill.p...@newsynthesis.org> wrote:
> Nicolas M. Thiéry wrote:
> > In short: for < = in, if it was just me, I would only use the most
> > absolutely trivial coercions. And in particular avoid there all the
> > coercions that involve projections and not embedding (like Z -> Z/nZ)
>
> +1
>
-1
> I think the new coercion model in Sage is much too aggressive -
> especially as applied when coding. As Ralf said: perhaps it makes
> sense for interactive use. Would it be possible to enable/disable some
> features dynamically?
>
-1
> Regards,
> Bill Page
Hi,
even the examples given in this thread so far speak against changes
in the current philosophy of the Sage coercion/conversion mechanisms.
It definitely should be in general as generously as possible. If at
some
local place this is not wanted, one always can make the local code to
be stricter, e.g. by explicitly asking whether "x.parent() = P" (4
above)
or any other of the means mentioned (points 1 - 3).
But if the coercion model would be strict in general, it would hardly
be
possible to "widen" it again by any local means, if so desired ...
>From the point of view of code quality, the above story about infinite
Weyl
groups sounds to me that now, that code is better than before.
I.e. it would work seamlessly whether the coercion model would be
strict
or not-so-strict as it is now. This clearly is a sign of greater
robustness, and
of the programmer having stated more precisely what the code really is
supposed to do (and what not).
Yeah, this might render writing new code more time-consuming.
But it is well worth the effort! I mean, as a general rule, the "sum
of all work"
is always the same. If you shift away work from "local" programming,
this
only means that the complexity of the general framework would
increase,
and more work would have to be done there. More precisely, one would
end up in the general framework with a jungle of if-else-cascades to
catch
each and every exceptional case, where some "different-to-norm"
behaviour
is desired. In the end the general framework would become
unmaintainable.
If, on the other hand, the general framework is not overburdened, but
the
different modules just have "more work" to do, then this can be
handled
and adressed on a one-by-one basis.
And also a clear "please not!" from my side to any differences in the
behaviour
in "library mode" versus "interactive mode". To the contrary, this is,
and should
be, a basic principle to be relied on, that the behaviour is as
identical as
possible! I want to write code, too, but without such an extra
dimension of
complexity to be taken care of during testing, experimenting, and so
on.
Cheers,
gsw
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
