Wednesday, January 4, 2023

Digest for comp.lang.c++@googlegroups.com - 3 updates in 2 topics

"Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Jan 05 12:23AM +0100

On 4 Jan 2023 02:54, Chris M. Thomasson wrote:
 
> One of my friends kindly texture mapped one of my IFS's on a half
> sphere, great for a sky dome. Here is the 3d object:
 
> https://skfb.ly/oCqn7
 
You should put this to music by Nirvana, In Bloom.
 
- Alf
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 04 01:41PM -0800

On 1/4/2023 3:07 AM, Juha Nieminen wrote:
> indices (that refer to coordinates in some manner) and actual Cartesian
> coordinates are both used at the same time, it's quite important to make
> the distiction.
 
Ahhh. x, y, z are the indices not coordinates. I see where this can
confuse the reader. The code in question is:
___________________________
// GRID!!!!! :^D Okay, let's go...
void
build_field_grid_data(
field_data& fdata,
unsigned long grid_n
) {
// double check
{
/*
// front face
fdata.m_field.push_back({ {-1, -1, 1, 0}, -1, {1, 0, 0, 0} });
fdata.m_field.push_back({ {1, -1, 1, 0}, -1, {0, 1, 0, 0} });
fdata.m_field.push_back({ {1, 1, 1, 0}, -1, {0, 0, 1, 0} } );
fdata.m_field.push_back({ {-1, 1, 1, 0}, -1, {0, 1, 1, 0} });
*/
}
 
 
glm::vec3 grid_min = { -1, -1, -1 };
glm::vec3 grid_max = { 1, 1, 1 };
glm::vec3 grid_dif = grid_max - grid_min;
 
float normal_base = 1.f / grid_n;
 
unsigned long grid_iter_n = grid_n + 1;
 
for (unsigned long z = 0; z < grid_iter_n; ++z)
{
for (unsigned long y = 0; y < grid_iter_n; ++y)
{
for (unsigned long x = 0; x < grid_iter_n; ++x)
{
glm::vec3 normal = {
x * normal_base,
y * normal_base,
z * normal_base
};
 
glm::vec3 p0 = grid_min + grid_dif * normal;
glm::vec4 field_p0 = { p0, 0 };
float field_mass = -1;
 
fdata.m_field.push_back({ field_p0, field_mass -1, {
normal.x, normal.y, 1 - normal.z, 0} });
}
}
}
 
fdata.m_field.push_back({ {-3, 0, 0, 0}, 500, {1, 1, 1, 1}});
fdata.m_field.push_back({ {3, 0, 0, 0}, 500, {1, 1, 1, 1} });
}
___________________________
 
 
I am creating the normal using the x, y, z indices:
 
glm::vec3 normal = {
x * normal_base,
y * normal_base,
z * normal_base
};
 
 
 
> understandable, I would still err on the side of actually spelling
> it out rather than use an abbreviation. Even if it makes it just
> a tiny bit clearer, that's a plus.
 
What about x_index ? I don't mind using underscores. I have did enough
work with pthread's where an underscore is no problem at all.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 04 10:48PM


> I wish this topic could be discussed with civility and professionalism,
> without the hubris.
 
Yes, that would have been nice, but you presented the matter as black
and white with no nuance or room for alternative perspectives. That may
well be your sincerely held opinion, but then what discussion, beyond
nodding agreement, are you wishing for here?
 
When it first appeared that there were sincerely held opinions that
differed from yours, you did not show any interest in finding out what
there were. In fact, rather than asking for more details, you
frequently "poisoned the well" for any further discussion by saying
things like
 
"I very much oppose the brevity-over-clarity style of programming"
 
and
 
"Clearer variable names are better. You will have extremely hard time
convincing me otherwise."
 
Suggesting that only a defence of brevity at the expense of clarity, or
an argument for the superiority of more obscure names will do.
Furthermore, you repeatedly presented disagreement as a simple failure
to understand
 
"How hard is this to understand, really?"
 
And examples were often batted away, sometimes with extraordinary broad
(and unfair) accusations such as
 
"mathematicians are almost proud about the fact that their scribbles
are as compressed and cryptic as possible"
 
Civil? Professional? Without hubris?
 
Now some people may have been "arguing in bad faith" (though not, I
think, the person that was aimed at) but was everyone? You can't have
thought you were engaging only with trolls or you would not have posted
this wish for a professional discussion. So when you found yourself
writing
 
"so why all this? I honestly cannot understand."
 
I think the onus is on you to try to understand "why all this". Do you
think you could accurately summarise what you believe some of the
respondents have been saying in way that would allow you to refine your
argument to address those points? If you don't think you could, you
didn't ask enough questions. Understanding other people's points of
view does not mean you agree with them, but it is a first step in having
a productive discussion.
 
--
Ben.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)