>>>>>>> I changed mingw.org's mingw-runtime to mingw-64 (32-bit).
>>>>>>> Then an error didn't occur and correct test.pdf was generated.
>>>>>>>
>>>>>>> https://github.com/trueroad/gub/tree/binutils-2.24
>>>>>>>
>>>>>>> I may pull request if you request it.
>>>>>>>
>>>>>>> Further, even if the runtime is mingw-w64,
>>>>>>> bad_alloc occurred when optimization was turned on.
>
> There is this at the end of skyline.cc:
>
> // Should add during ver2.19 (to avoid an endless loop
> // when merging identical skylines with a vertical segment)
> // if (end >= s2->front().end_) s2->pop_front();
>
> Also, the mention of optimization reminds me of one of the horrors of
> floating point types: a value in a register can quietly be changed when it is
> written to memory. Take a look at some of the “myths” in section 1 of
> https://hal.archives-ouvertes.fr/hal-00128124/en/ .
>
> Do the skylines need to deal with the wide range of values that “double"
> allows? If not, replacing the Real class with a fixed-point math class would
> make the code a lot less scaring.
I think that floating point can be used as long as it's used correct.
operator== shouldn't be used for comparison of floating point values.
operator!= shouldn't be used too.
operator< and operator> may be used.
It's better not to use operator<= and operator>=.
I tried the following patch.
But bad_alloc occurred.
Then, I think the floating point problem may be unrelated to this case.
```
--- a/lily/skyline.cc 2014-12-01 21:31:21.353083100 +0900
+++ b/lily/skyline.cc 2014-12-04 22:56:17.740379900 +0900
@@ -184,7 +184,7 @@
// conceals and intersection_x involve multiplication and
// division. Avoid that, if we can.
- if (c.y_intercept_ == -infinity_f)
+ if ((isinf(c.y_intercept_) && signbit(c.y_intercept_)))
{
if (c.end_ > b.end_)
return b.end_;
@@ -197,7 +197,7 @@
return start_x;
Real i = b.intersection_x (c);
- if (i > start_x && i <= b.end_ && i <= c.end_)
+ if (i > start_x && (i - b.end_) < DBL_EPSILON && (i - c.end_) <
DBL_EPSILON)
return i;
start_x = c.end_;
```
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
