> On Jul 30, 2017, at 12:25 PM, Mario Meissner <mr.rash....@gmail.com> wrote:
>
> Hi again!
>
> Attached goes current state of my new function. I've not even tried to run it
> yet as I still need to work on it before expecting anything to work.
I encourage you to approach this from a somewhat different development
approach, one feature at a time.
Looking at your code you’ve obviously done well writing for the big picture,
but you have conditionals with questions on both sides of the conditional
because you’re already working on one of the more harder cases before getting
two simpler cases working. That lets issues accumulate and makes it really
hard to talk about whether the direction is appropriate or not, to say nothing
of how it complicates answering questions.
In general terms, it’s the difference between breadth-first and depth-first
coding. Another word for it is coding “complete”, which relates to what was
mentioned here:
http://brlcad.org/wiki/Summer_of_Code/Acceptance#Write_complete_code
<http://brlcad.org/wiki/Summer_of_Code/Acceptance#Write_complete_code>
> However, I would love to know if this is even remotely heading towards the
> right direction.
> Inside the code are some questions commented out that I may need an answer to.
I’d request you revert the code back a bit to just implementing the very first
step (i.e., no points), and demonstrate it compiling, running, working. That
will get you through so many pedantic issues.
That would have weeded out your "fancier way" question (for which the answer is
to see vmath.h, specifcially VSETALL and VINIT_ZERO) and you would have
encountered a critical bug that is currently affecting all point cases (it will
crash on writes to the origin pointer). It will also make it a bit more
apparent that an origin might not be needed if there are no points.
> For now I give the function a set of points and from that I build the
> vectors. However it makes no sense to recompute the vectors every time we
> call the function. How and where should we store the information so that when
> asking for density values the function knows where to look at to compute the
> result? Some shared structure maybe?
That’s jumping ahead. :)
> Although we said we wouldn't yet deal with this, for the sake of structuring
> things up correctly I think it's useful to discuss it. If we have more than
> two points, would it be a good approach to draw vectors from the first point
> to every other point we got? Something like giving the first point the status
> of origin so that all other vectors start there? I've tried to do it this way
> for now, as you can see in the attached code.
I can appreciate that this is conceptually very hard to accept — leaving these
preconceptions to future-you. “Structuring things up correctly” is almost
certain to be *incorrect* if you jump to the more complex case without gaining
any experience and insight with the simpler cases. And reworking complex code
on the simpler cases almost inevitably makes their code far more complex than
they need to be as well.
For example, you question assumes vectors will be needed or used when you have
3+ points and that’s not certain. It’s not even 100% certain that it’s a good
way for 2 points, but it seems reasonable. That uncertainty will be reduced
when 2-points is working and we can consider the structure implications. Right
now, you don’t even need a structure.
Cheers!
Sean
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
