On 10/13/19 11:19 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 10/7/19 1:07 PM, jr wrote:
>>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>>> Perhaps, finally, a good test case for isosurface artefacts I've worked
>>>> around for years! Confirmation Windows / OSX showing similar artefacts
>>>> would be useful. Linux users not on Ubuntu 18.04 too.
>>>> ...
>>>
>>> same artefacts (identical looking) on a Slackware box, using
>>> 3.8.0-alpha.10013324.unofficial.
>>>
>> Thanks jr.
> 
> pleasure.
> 
> (am dismayed -- riled, actually -- that no Windows/Mac users found the few
> minutes it took, apparently)
> 
>> ...
> 
> regards, jr.
> 

:-) Ah, everyone is busy and focused upon what they're focused upon. I'm 
bad at even minor task switching/juggling. Plus! Could be they see the 
man off wandering in the weeds - as a man off wandering in the weeds.

While I think I understand what's happening, results from POV-Ray 
compiled with other compilers still of some interest should anyone be 
motivated to test.

---
The code involved makes use of abs/fabs, min, max and the like. 
Behaviors of which - especially when you don't get the expected C++ 
standard library version(1) - can be different.

(1) - As happened with vector.h abs() use when linux users initially 
tried the v3.8 user defined camera. The immediate fix was to use fabs(), 
but on my to-do, someday, list to look at vector.h more closely. I 
suspect it still the case we are getting the c99 math functions in 
vector.h and not the standard library versions due cyclic includes, but 
maybe not, and maybe I should stop looking for weeds to whack.

Related to (1): Had the thought to perhaps enforce std::abs, std::min, 
std::max use over bare abs/fabs ?/..., min, max names enabled with 
'using...' statements in coretypes.h & types.h. These in particular are 
known to have MS VS to other compiler implementation differences.

Bill P.

Post a reply to this message