fix of implicit type conversion.#79
Conversation
|
good day. |
|
Apparently the floor fix broke something. Btw, did you consider divinding by 2.0 instead of casting the value? |
|
sorry for the long answer. |
|
is this PR still relevant? |
|
I have to do something to make this PR useful. |
|
Note, https://gitlab.xiph.org/xiph/vorbis/ is the upstream project, I've been told the github repository is a convenience copy. Perhaps it is an idea to submit the patch there? |
|
Oh no. I don't have an account there. maybe a better idea would be if you fix the code there yourself. |
|
[ihsinme]
Oh no. I don't have an account there. maybe a better idea would be if
you fix the code there yourself.
do I close PR?
I am not the maintainer of vorbis, so I do not really have an opinion on this.
…--
Happy hacking
Petter Reinholdtsen
|
|
@ihsinme Thanks for the patches. Can you say a bit more about what issue you're trying to address? Do you think this is a correctness problem? Are you trying to address warnings from a particular compiler? |
| considered prevoius-to-potential-trigger */ | ||
| int stretch=max(VE_MINSTRETCH,ve->stretch/2); | ||
| float penalty=gi->stretch_penalty-(ve->stretch/2-VE_MINSTRETCH); | ||
| float penalty=gi->stretch_penalty-((float)(ve->stretch)/2-VE_MINSTRETCH); |
There was a problem hiding this comment.
The stretch itself is calculated with integer division, so maybe that's a more accurate heuristic for the penalty?
|
The appveyor integration test failure is an unrelated issue fixed in 894d1b1. A rebase should complete without error. |
the essence of the error is described in PR. this is an integer division, when a fraction is expected. |
|
Just because the assigned variable is floating point doesn't mean the calculations must all be floating point. We are free to choose at what points integer inputs are converted. For example:
Which of these criteria are most important varies. That's why I asked what specific issue you wanted to address. |
|
Good day. |
|
is there any news on this PR? |
3 participants
in casting used in your code, first the result of division is converted to an integer type, with the loss of the fractional part, and then the integer is converted to a floating point type. I think this can be simply fixed.