|
From: Stavros M. (Σ. Μ. <mac...@al...> - 2016-01-28 17:11:38
|
I looked back at the original discussion of this topic from Jan/Feb 2014
(Subject: Floating point overflow: what to do?), and I see no consensus to
release this feature. Quite the contrary.
Swarbrick pushed a patch with no discussion, and announced it. Fateman, Ray
Toy, Jorge Calvo, and I were mostly opposed, or at least ambivalent. Dodier
seemed to be OK with it, but asked that it be controlled by a switch (which
Swarbrick added, with a default of true).
Nowhere in this discussion did I see *any substantive rationale* for the
feature. What sort of user or application benefits from it? What are its
advantages and disadvantages? When does it make for *less* correct results?
Many of the points that have been raised in the current discussion were
raised then and never answered: what about underflow / gradual underflow?
What about consistency with translated/compiled code?
Given all this, at the very least, the default value for
promote_float_to_bigfloat should be false.
Fateman's proposal is much more consistent. If we make 1.0 and 1.0e0 denote
bfloats (ideally decimal, not binary, but binary is a good start), we get
clean semantics. We then reserve, say, 1.0d0 for machine floats. *However*,
many parts of Maxima handle floats correctly, but not bfloats:
rat/keepfloat and thus all functions that use CRE (ratsimp, eigenvalues,
limit in some cases); some special functions.
So I don't think we currently have a proposal on the table that is both
clean and easily implemented. Certainly not one that has a consensus behind
it.
-s
On Thu, Jan 28, 2016 at 1:00 AM, Robert Dodier <rob...@gm...>
wrote:
> Raymond Toy <toy.raymond <at> gmail.com> writes:
>
> > This is why I was opposed to this change. It is no longer possible to
> > reason on what a program will do without knowing all the possible
> > values.
> >
> > I lost that battle.
>
> For the record, there is a flag to turn off the float->bigfloat
> promotion. It is named promote_float_to_bigfloat and its default
> value is true.
>
> If someone wants to change the default value to false,
> I wouldn't mind.
>
> It's discouraging that there are bugs in the current implementation
> but I think in essence it's an interesting idea so I would be dismayed
> if the code were simply removed. I guess I could live with moving
> the code to a branch -- I think it's only a few commits.
>
> FWIW
>
> Robert Dodier
>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Maxima-discuss mailing list
> Max...@li...
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>
|