 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I even followed this one.
http://blog.quenta.org/2012/09/0x5f3759df.html
--
Darren New, San Diego CA, USA (PST)
"They're the 1-800-#-GORILA of the telecom business."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 15.09.2012 19:30, schrieb Darren New:
> I even followed this one.
>
> http://blog.quenta.org/2012/09/0x5f3759df.html
What the...
... well, no fuck indeed. Makes perfect sense, even to me.
Which begs the question: Would it be worth to use this approximation -
maybe with a few more steps of newton - in POV-Ray, or at least in an
experimental patch thereof?
I suspect that if you complement this approximation with enough newton
steps to obtain full precision, it'll be no faster than the "sqrt" and
"pow" runtime library functions - after all, if it would be both fast
and precise enough, the RTL functions would already make use of this
very approach (for exponents in range -1..1), wouldn't they?
With a little tweaking of sigma the approach could be modified to
compute upper or lower bounds to sqrt(x) or 1/sqrt(x) instead, which
could theoretically be used for quick checks involving square roots.
However, the classic approach of replacing sqrt(x)<y checks with x<y*y
checks is probably in the same ballpark as far as speed is concerned,
without any loss of accuracy, no need for type casting (which might
actually incur a speed penalty for moving data between floating-point
and integer registers), and much better portability characteristics.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 16/09/2012 03:23, clipka a écrit :
>
> Which begs the question: Would it be worth to use this approximation -
> maybe with a few more steps of newton - in POV-Ray, or at least in an
> experimental patch thereof?
If you consider that:
1. POV-Ray has currently no requirement on using IEEE-754 float (of
exactly 32 bits)
2. The FLOAT & other types of POV-Ray are customisable
such approximation would impact:
* portability (you now MUST have 32 bits floats, nothing else)
* precision or speed (if you need newton steps... )
* as black-box magic, it would be a hell to debug if you ever get a
typo on one digit.
I remember a very old port on a M68000 family system, where the float
where natively rather a 48 bits: such trick would ruin such portage.
(48 bits was for every floating point values)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/17/2012 7:07, Le_Forgeron wrote:
> such approximation would impact:
> * portability (you now MUST have 32 bits floats, nothing else)
I would think it would be pretty straightforward to ifdef it if needed.
--
Darren New, San Diego CA, USA (PST)
"They're the 1-800-#-GORILA of the telecom business."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Which begs the question: Would it be worth to use this approximation -
>> maybe with a few more steps of newton - in POV-Ray, or at least in an
>> experimental patch thereof?
>
>
> If you consider that:
> 1. POV-Ray has currently no requirement on using IEEE-754 float (of
> exactly 32 bits)
> 2. The FLOAT & other types of POV-Ray are customisable
>
> such approximation would impact:
> * portability (you now MUST have 32 bits floats, nothing else)
> * precision or speed (if you need newton steps... )
> * as black-box magic, it would be a hell to debug if you ever get a
> typo on one digit.
It would be interesting to see how much it affected the speed first. If
it was some significant speed-up with no visible loss in image accuracy
then I suspect many people would be happy to install a custom/patched
version to make use of the speed-up.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 17/09/2012 03:21 PM, scott wrote:
> It would be interesting to see how much it affected the speed first. If
> it was some significant speed-up with no visible loss in image accuracy
> then I suspect many people would be happy to install a custom/patched
> version to make use of the speed-up.
On the other hand, "everybody knows" that square root is a very
expensive operation, so people structure their code to avoid it as much
as possible. Thus, making it fast probably wouldn't have that much of a
drastic impact.
Then again, what do I know? I don't even understand how a Sturmian root
solver works!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 17/09/2012 16:19, Darren New nous fit lire :
> On 9/17/2012 7:07, Le_Forgeron wrote:
>> such approximation would impact:
>> * portability (you now MUST have 32 bits floats, nothing else)
>
> I would think it would be pretty straightforward to ifdef it if needed.
>
Next step after the opening of that can of worms: inline assembly...
under #ifdef, of course...
Back to off-topic:
for having to deals professionally (well, I get paid for that) with a
code with plenty of #ifdef options (it always starts with "a small and
easy option" from salemen & marketing... ), it is a true nightmare to
debug or even amend (and test coverage is not funny either)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/17/2012 9:20, Le_Forgeron wrote:
> Next step after the opening of that can of worms: inline assembly...
> under #ifdef, of course...
Yep. "Portable" C really just means you can put lots of different versions
of the program in the same source file. :-)
--
Darren New, San Diego CA, USA (PST)
"They're the 1-800-#-GORILA of the telecom business."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
