________________________________
> From: [email protected]
> Date: Mon, 22 Aug 2016 21:53:12 +0000
> Subject: Re: [Libmesh-users] DenseSubMatrix and DenseSubVector lack of
> ctor and operators
> To: [email protected]; [email protected]
> CC: [email protected]
>
> On Mon, Aug 22, 2016 at 1:08 PM Mike Marchywka
> <[email protected]<mailto:[email protected]>> wrote:
> I tried that and the compiler did not like it because of the way you
> designed the classes...
>
> Compiler didn't like what? You have to write C++ that compiles. That
> has nothing to do with the "class design". Pay attention to the
> Doxygen pages... they tell you how to use each of the
> objects: http://libmesh.github.io/doxygen/classes.html
>
> I was curious why you did that so the code would be more solid and
> optimization is one possibility
> although no one did mention the rationale behind making the size() of
> a fixed size vector into a norm - it sounds like you are still
> deprecating things as you go.
>
> The library evolves over time... new features are added and some old
> things deprecated. That's the way with any software project.
>
> The rationale behind size() for TypeVector was because TypeVector
> represents a mathematical vector. The "size" of a mathematical vector
> is its norm... with the 2 norm (also called the Euclidean Norm) being
> the most obvious choice. Check the first sentence
> here:
> https://en.wikipedia.org/wiki/Norm_(mathematics<https://en.wikipedia.org/wiki/Norm_%28mathematics>)
>
>
> Go ask a mathematician how they would measure the size of a vector...
> and they will directly tell you to use a norm. The number of entries
> doesn't mean anything mathematically.
Thanks, if the "size" can be measured by the norm then calling something called
a norm would presumably make sense if that is the "size" that was desired?
Or maybe size(name) would make sense as opposed to size() which
could return just about anything ?
In any case that seems very colloquial in the wikipedia context as a synonym
for length, and I can't find it
at Wolfram or any edu sites immediately. It may be more common in math
journals, I'll have to
take your word for it, or something but norm seems a lot more common or maybe
length.
I take it no mathematicians were upset by its removal. In any case there is
room for
"evoluation" as you suggest and things that are confusing to new users may be
of interest to you.
>
> Not too mention that there is no need for a function to return the
> number of entries in a TypeVector... because the number of entries is
> always LIBMESH_DIM.
Or for that matter maybe sizeof()/sizeof(value_type)? lol.
It was not obvious and not shown in the examples and seems
a reasonable issue to consider for users. I guess you could have a
get properties method.
>
> That said, we realized the name could be mistaken for being the number
> of entires in the array and added the new "norm()" function and we'll
> remove "size()" soon. This is simply to reduce confusion. You can
> read the discussion here: https://github.com/libMesh/libmesh/issues/813
>
> It would be easier to get it working if I could move code around freely
> with normal operations being permitted.
>
> I'm not sure what you mean here... you can "move around" anything you
> want... as long as what you write is still valid C++.
>
> Maybe I wasn't clear earlier... so let me try again: you are currently
> not in a position to recommend modifications to libMesh. libMesh is
> used by hundreds of people every day. The design has been carefully
> curated and evolved by experts over the last 15 years.
>
lol. I'm not sure that the question rose to the level of militant suggestion.
Please consider the question for the sake of anyone seeking to use this
and not wanting to spend 15 years learning it. I was quite clear
about all of that but not sure of the relevance. As a new user I wanted
some ability to move the code around without a lot of effort.
Providing some of the interfaces with templated signatures could help
make them more flexible. Rather than learning how all of your classes
work, a user with existing dense matricies that support (i,j) may have an
easier time of it.
> Before recommending changes or criticizing things about the library:
> you are going to need to use it the way it is. After you develop an
> application (or two... or three) and you understand the current design
> then you can come back to us with well reasoned design evolutions and
> we can have a proper discussion.
>
I did plan on using it the way it is and actually I wish I would have found it
years ago. So far it is working amazingly well given my lack of prior
experience- I almost have a recognizable
system and the grid is evolving in a sensible way. However, I do have certain
observations
and questions that, as I stated earlier, may not make much sense if you have
used this
a lot and I was a bit alarmed that dernormals were so common with wrong
subscripts as this
can produce hard to find errors.
Rather than do as you suggest however it would probably be easier for me to
play with my
own copy and if I can actually demonstrate that something works then it would
be easier
to discuss. Since the thing is evolving then maybe this is just a tangent to an
existing conversation
or as you suggest a trivial distraction.
Did you start the clock ticking yet?
Thanks for your interest and concern however.
> Derek
------------------------------------------------------------------------------
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
