On 05/04/2016 03:19 PM, clipka wrote:
> Am 04.05.2016 um 18:14 schrieb Le_Forgeron:
>
...
>
> (*) On the other hand, it could still be considered an extension to the
> ovus, as in "an ovus, but don't give me the spheres because I already
> have them"; most notably, the parameterization, as you envision it,
> would still be based on the concept of an ovus; also, it would make a
> lot of sense in terms of implementation, because all you'd have to do
> would be to suppress the spherical portions.
>

My thoughts - while probably not following you both completely. Also 
being more interested in getting at the inner citrus shape than having 
more flexible egg/ovus shapes.

I vote for providing access to the citrus shape as an extension to the 
ovus given we have the ovus today - at least as seen by us users. 
Perhaps too we should continue calling it the citrus shape of the ovus 
given it has been introduced as such already. Though certainly other 
names, like those suggested, would be more descriptive for such a shape 
standing apart.

Aside: I played some with this inner shape as an isosurface some while 
back on seeing the ovus introduced. It looked a useful base 
shape/function. However, the sharp points on the end drive up the 
isosurface time considerably, so having other access to this shape would 
be cool.

When we want:

1) the full citrus shape. Would we specify a length directly or do this 
by specifying the distance between the two spheres and both radii as 
zero or nearly zero?

2) the citrus shape clipped equally on both ends - the barrel shape. 
Would we specify a distance between spheres, both radii the same and 
then to drop both spheres from the result?

3) the citrus shape clipped at one end -an ogive or bullet. We'd do 
something like (2), but be able to drop just the larger sphere while the 
other sphere stays with a near zero radius out at the end of the citrus?

4) the citrus shape clipped unequally... Is this doable at all as a 
give-me-the-citrus extension to the ovus? It looks to me like the clip 
to the larger sphere happens perpendicular to the origin of that sphere, 
but the clip to the smaller sphere is somehow calculated & not clear to 
me how?

Bill P.

Post a reply to this message

Am 05.05.2016 um 15:15 schrieb William F Pokorny:

> I vote for providing access to the citrus shape as an extension to the
> ovus given we have the ovus today - at least as seen by us users.
> Perhaps too we should continue calling it the citrus shape of the ovus
> given it has been introduced as such already. Though certainly other
> names, like those suggested, would be more descriptive for such a shape
> standing apart.

I can only assume that the term "citrus" was introduced as a
description, not a technical term, and I strongly discourage its use in
this sense. As a matter of fact, in mathematics the term "citrus" is
already in use for a different shape.

The proper technical term would be "lemon", while I've been using the
term "spindle" instead, owing to the fact that it is the inside surface
of a "spindle torus".


> When we want:
> 
> 1) the full citrus shape. Would we specify a length directly or do this
> by specifying the distance between the two spheres and both radii as
> zero or nearly zero?

For the full shape, you would simply use

    torus { R1, R2 intersection }

with classic torus parameters for R1 and R2 (with R2>R1). Some
trigonometry may be required to compute these from some other
parameterization such as the distance between the tips and the "equator"
radius.

This syntax will be supported in 3.7.1, and has already been available
in dev releases for quite a while (though I think I didn't make much
noise about it).

> 2) the citrus shape clipped equally on both ends - the barrel shape.
> Would we specify a distance between spheres, both radii the same and
> then to drop both spheres from the result?

That depends on what syntax we eventually end up with ;)

> 3) the citrus shape clipped at one end -an ogive or bullet. We'd do
> something like (2), but be able to drop just the larger sphere while the
> other sphere stays with a near zero radius out at the end of the citrus?

I'm quite sure that would be a special case of 2).

> 4) the citrus shape clipped unequally... Is this doable at all as a
> give-me-the-citrus extension to the ovus? It looks to me like the clip
> to the larger sphere happens perpendicular to the origin of that sphere,
> but the clip to the smaller sphere is somehow calculated & not clear to
> me how?

In the current ovus implementation, the transition between the lower
sphere and the lemon actually does /not/ coincide with the equator of
the lower sphere (except for very specific selections of parameters),
even though /some/ of the sample images seem to imply that.

Post a reply to this message

Le 04/05/2016 17:42, clipka a écrit :
>>> (1) Can you update the documentation to include...
>>> >> (1.a) how the radius of the spindle is computed;
>>> >> (1.b) the fact(?) that the bottom sphere is always placed at <0,0,0>
>> > 
>> > the documentation is in the wiki, right ? So anyone could update it to
>> > add these element. I thought 1.b was already in the documentation.
> Guess what -- I'm a bit busy documenting all the stuff I've added since
> 3.7.0 ;)
> Also, I thought you might have produced the original 2D sketch, and
> might be the person most fit to add the minor spindle radius to it.
> 
> You're right about 1.b though.
> 
> 

I updated the wiki to drop "citrus", both on text and 3D image.

For the 2D sketch, I would need to remake it from scratch to better illustrate the
point
of the center being elsewhere... as well as the connection being not on the x-axis.

I might actually illustrate that better
with a large picture, I'm afraid.

Post a reply to this message

Maybe it should be called the "rind"    :D

Post a reply to this message

On 5/6/2016 12:22 PM, Bald Eagle wrote:
> Maybe it should be called the "rind"    :D
>
>
I would go for the Scots word "Peerie" as in whip and peerie (a child's 
spinning top).
It can also mean small.


-- 

Regards
     Stephen

Post a reply to this message

On 05/05/2016 11:53 AM, clipka wrote:
> I can only assume that the term "citrus" was introduced as a
> description, not a technical term, and I strongly discourage its use in
> this sense. As a matter of fact, in mathematics the term "citrus" is
> already in use for a different shape.
>
> The proper technical term would be "lemon", while I've been using the
> term "spindle" instead, owing to the fact that it is the inside surface
> of a "spindle torus".

Thanks Christoph. I wrongly assumed it was the citrus surface in use 
with the ovus due the documentation's use of the term. I used for my 
isosurface play the citrus surface equation at:

  http://mathworld.wolfram.com/Lemon.html

not the lemon surface.

Bill P.

Post a reply to this message

Correct me if I'm wrong, but does Wolfram have the 2D cross-sectional diagrams
(on the right) switched for the spindle and horn tori?

http://mathworld.wolfram.com/SpindleTorus.html
http://mathworld.wolfram.com/HornTorus.html

Post a reply to this message

Le 06/05/2016 16:13, Bald Eagle a écrit :
> Correct me if I'm wrong, but does Wolfram have the 2D cross-sectional diagrams
> (on the right) switched for the spindle and horn tori?
>
> http://mathworld.wolfram.com/SpindleTorus.html
> http://mathworld.wolfram.com/HornTorus.html

Yes, you are correct. the slice is correct, but the 3D in the middle are 
switched.

Post a reply to this message

Le 04/05/2016 à 17:42, clipka a écrit :
>> > About being doable, yes, I can (but there will be additional constraints
>> > on the values, such a minimal minor radius function of the three other
>> > distances under which you would get an error)
> Of course such constraint checks would be part of the deal.
>
>> > And do you expect default values for some parameters too ? (yet more
>> > syntax sugar... )
> Since I'd advocate to put it into the ovus primitive, of course the
> default values would be Bottom_radius for the Y coordinate of the top
> sphere, and 2*max(Bottom_radius,Top_radius).
>

back to that subject... finding a suitable syntax, backward compatible 
with existing syntax.

So far :

   ovus { Bottom_radius, Top_radius }

0 <= Bottom_radius
0 <= Top_radius <= 2*Bottom_radius

(when TopRadius > 2*BottomRadius, object is replaced by a sphere)

Additional parameters:

   InnerRadius (default to 2 * max( Bottom_radius, Top_radius )

   Distance_between_spheres (default to Bottom_radius )

0 <= Bottom_radius
0 <= Top_radius
0 <= Distance_between_spheres (Bottom is at <0,0,0>,
   but Top is at <0, Distance_between_spheres, 0> instead
   of <0, Bottom_radius, 0>

complex relation for InnerRadius vs its minimal value.

If it was only for one additional parameter the obvious syntax would 
have been:

   ovus { Bottom_radius, Top_radius [, extra_value ] }


Please provide some suggestions about an acceptable syntax.

Post a reply to this message

Am 25.05.2016 um 14:06 schrieb Le_Forgeron:

> If it was only for one additional parameter the obvious syntax would
> have been:
> 
>   ovus { Bottom_radius, Top_radius [, extra_value ] }
> 
> 
> Please provide some suggestions about an acceptable syntax.

How about

    ovus { Bottom_radius, Top_radius [, extra_value1, extra_value2 ] }

? ;)

Post a reply to this message