Re: Outerposition Patch

[Ben Abbott]

On Feb 19, 2011, at 2:21 AM, logari81 wrote:

> On Fri, 2011-02-18 at 19:06 -0500, Ben Abbott wrote:
>> On Feb 18, 2011, at 6:35 PM, logari81 wrote:
>> 
>>> On Fri, 2011-02-18 at 22:40 +0100, Konstantinos Poulios wrote:
>>>> On Fri, Feb 18, 2011 at 6:07 PM, bpabbott <address@hidden> wrote:
>>>>> On Feb 18, 2011, at 12:02 PM, bpabbott <address@hidden> wrote:
>>>>> 
>>>>> On Feb 18, 2011, at 11:04 AM, Konstantinos Poulios <address@hidden>
>>>>> wrote:
>>>>> 
>>>>> On Fri, Feb 18, 2011 at 2:36 PM, Ben Abbott <address@hidden> wrote:
>>>>>> On Feb 18, 2011, at 2:37 AM, logari81 wrote:
>>>>>> 
>>>>>>> On Thu, 2011-02-17 at 21:09 -0500, Ben Abbott wrote:
>>>>>>> 
>>>>>>>> On Feb 17, 2011, at 4:32 PM, logari81 wrote:
>>>>>>>> 
>>>>>>>>> On Wed, 2011-02-16 at 19:37 -0500, Ben Abbott wrote:
>>>>>>>>> 
>>>>>>>>>> On Feb 13, 2011, at 12:05 PM, logari81 wrote:
>>>>>>>>>> 
>>>>>>>>>>> On Thu, 2011-02-10 at 20:00 +0100, Konstantinos Poulios wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Feb 10, 2011 at 1:59 PM, Konstantinos Poulios wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Thu, Feb 10, 2011 at 9:25 AM, David Bateman <address@hidden>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Le 10 févr. 2011 à 00:25, logari81 <address@hidden> a
>>>>>>>>>>>>>> écrit :
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> thank you for this information.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> It seems that the previously attached patch causes problems only
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> legends. However, in order to treat legends correctly I need to
>>>>>>>>>>>>>>> understand their logic. How do legends exploit the outerposition
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> position properties? Is anyone familiar with legend.m to give me
>>>>>>>>>>>>>>> a short
>>>>>>>>>>>>>>> introduction?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Best regards
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> You shouldn't try to understand the logic of legend's use of the
>>>>>>>>>>>>>> position and outerposition properties. It's just a hack that 
>>>>>>>>>>>>>> worked with the
>>>>>>>>>>>>>> existing behavior. If your patch doesn't work well with legend 
>>>>>>>>>>>>>> it is
>>>>>>>>>>>>>> probably legend that needs to be fixed
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> D.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The attached patch replaces the previous one and implements the
>>>>>>>>>>>>> calculation of both position and outerposition depending on the
>>>>>>>>>>>>> value
>>>>>>>>>>>>> of activepositionproperty.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> It is not very well tested yet, so there will probably be some
>>>>>>>>>>>>> issues,
>>>>>>>>>>>>> e.g. legends will not work, but it brings a feature that maybe is
>>>>>>>>>>>>> awesome. It is something that Matlab cannot do and maybe you like
>>>>>>>>>>>>> it.
>>>>>>>>>>>>> See the following video:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> http://ubuntuone.com/p/cYM/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The position property is calculated dynamically while you rotate
>>>>>>>>>>>>> the
>>>>>>>>>>>>> view, so that all labels fit in outerposition. I think it works
>>>>>>>>>>>>> quite
>>>>>>>>>>>>> well in order to keep it. What do you think?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> As this operation involves certain computational overhead, it 
>>>>>>>>>>>>> would
>>>>>>>>>>>>> be
>>>>>>>>>>>>> interesting to get some tests on older machines. Unfortunately all
>>>>>>>>>>>>> pc's that I have access to, are too fast.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This patch also fixes http://savannah.gnu.org/bugs/?31610 for the
>>>>>>>>>>>>> fltk toolkit.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Finally, if we adopt the attached patch we have to adapt legend.m
>>>>>>>>>>>>> also.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> BR
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Kostas
>>>>>>>>>>>> 
>>>>>>>>>>>> After some more testing and fixes I think the patch is quite mature
>>>>>>>>>>>> in
>>>>>>>>>>>> the form you find in the attachment. I think it could be checked 
>>>>>>>>>>>> in.
>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> I have just checked in this changeset along with some further
>>>>>>>>>>> fixes/improvements. Now, I would like to provide some additional
>>>>>>>>>>> information and ask for some help with regard to the open issues 
>>>>>>>>>>> that
>>>>>>>>>>> I
>>>>>>>>>>> had listed.
>>>>>>>>>>> 
>>>>>>>>>>>> There are still some general issues with fltk that I will try to 
>>>>>>>>>>>> sum
>>>>>>>>>>>> up:
>>>>>>>>>>>> 
>>>>>>>>>>>> 1. In some demo plots axes labels seem to be too close to the axes
>>>>>>>>>>>> (e.g. demo legend 9). Probably in some of the previous changes 
>>>>>>>>>>>> there
>>>>>>>>>>>> is something that I have overseen.
>>>>>>>>>>> 
>>>>>>>>>>> Actually after testing older revisions of octave I realized that the
>>>>>>>>>>> problem is not new. The reason that I hadn't noticed it before is
>>>>>>>>>>> because the problem appears only in the print output and not in the
>>>>>>>>>>> plot
>>>>>>>>>>> window. It seems that gl-render and gl2ps position strings
>>>>>>>>>>> differently
>>>>>>>>>>> considering either the bottom line or the baseline of the string
>>>>>>>>>>> respectively. It is not difficult to fix, we just have to decide
>>>>>>>>>>> which
>>>>>>>>>>> of gl-render and gl2ps are we going to fix in order to make both
>>>>>>>>>>> consistent.
>>>>>>>>>>> 
>>>>>>>>>>>> 2. Legends for barplots don't show colors (this is an old problem).
>>>>>>>>>>>> 
>>>>>>>>>>>> 3. Some small y axes interference for plotyy (also not new).
>>>>>>>>>>>> 
>>>>>>>>>>>> 4. Now there is no labels-titles interference in demo subplot 1, so
>>>>>>>>>>>> there is no need for extra space between the subplots, we can 
>>>>>>>>>>>> reduce
>>>>>>>>>>>> a
>>>>>>>>>>>> bit the padding (someone which is familiar with subplot.m I
>>>>>>>>>>>> suppose).
>>>>>>>>>>> 
>>>>>>>>>>> Waiting for someone familiar with subplot.m
>>>>>>>>>> 
>>>>>>>>>> I"ve just pushed a changeset that improves the layout of the 
>>>>>>>>>> subplots.
>>>>>>>>>> 
>>>>>>>>>>  http://hg.savannah.gnu.org/hgweb/octave/rev/7b67bbf9dbbb
>>>>>>>>>> 
>>>>>>>>>> I'm also attaching a test script that runs under Octave and Matlab.
>>>>>>>>>> Results for both are attached.
>>>>>>>>> 
>>>>>>>>> This script is cool, I was thinking of doing something like that but I
>>>>>>>>> didn't realize that it can be done so easily.
>>>>>>>>> 
>>>>>>>>>> The test script places dashed blue lines around the position of each
>>>>>>>>>> axis, and dashed red around the outerposition.
>>>>>>>>> 
>>>>>>>>> You mean blue lines around the original axes position before adding
>>>>>>>>> labels and titles. The version of the script that I have attached in
>>>>>>>>> this email visualizes the updated positions which correctly coincide
>>>>>>>>> with the axes.
>>>>>>>> 
>>>>>>>> Ok. I see your point. I'll have to do some experimenting with the
>>>>>>>> corrected version.
>>>>>>>> 
>>>>>>>>>> When subplot (3,3,1:3) is used to replace the first row of subplots, 
>>>>>>>>>> a
>>>>>>>>>> green dashed box is used to encompass the new position, and a dashed 
>>>>>>>>>> magenta
>>>>>>>>>> for the outerposition.
>>>>>>>>>> 
>>>>>>>>>> The problems I see are ...
>>>>>>>>>> 
>>>>>>>>>> 1) The activeposition property is still "outerposition".
>>>>>>>>> 
>>>>>>>>> why is this a problem? Maybe we prefer this, maybe not, see my comment
>>>>>>>>> on (2). ML sets it to "position" but we do not have necessarily to do
>>>>>>>>> the same.
>>>>>>>> 
>>>>>>>> We may decide to deviate from compatibility with Matlab, but before
>>>>>>>> doing so we should discuss it on the list. The list has already 
>>>>>>>> discussed
>>>>>>>> and agreed to Matlab compatibility (before my time here), it would be
>>>>>>>> improper to deviate from that agreed upon approach without discussion 
>>>>>>>> first.
>>>>>>>> 
>>>>>>>> Can we abide by Matlab's example for now and discuss changes later. If
>>>>>>>> nothing else, that would make it easier (for me) to review the state of
>>>>>>>> graphics for Octave (via dump_demos and such).
>>>>>>>> 
>>>>>>>>>> 2) The width of subplot (3,3,1:3) has been improperly modified on the
>>>>>>>>>> c++ side.
>>>>>>>>> 
>>>>>>>>> Actually this is not really "improperly". It is doing what it was
>>>>>>>>> expected to do. What we programmed in c++ is a minimum left margin of
>>>>>>>>> 13% of outerposition(3). For the upper subplot the total width is 3
>>>>>>>>> times the width of the other subplots so the minimum left margin is
>>>>>>>>> also
>>>>>>>>> 3 times higher. It is ugly.
>>>>>>>>> This would be a reason for switching to
>>>>>>>>> activepositionproperty=position.
>>>>>>>>> This way, we wouldn't let sync_position do its job but we would do it
>>>>>>>>> manually in the frontend. Now we are able to, before we couldn't
>>>>>>>>> because
>>>>>>>>> we couldn't get any tightinset values.
>>>>>>>> 
>>>>>>>> If consistent with Matlab, the subplot(3,3,1:3) would produce an axes
>>>>>>>> with a position property that encompasses the original 3 axes (Matlab
>>>>>>>> documents this, but I've noticed some minor "bugs" on their part).
>>>>>>>> 
>>>>>>>> For now, can the position/outerposition synchronization be implemented
>>>>>>>> in the manner that is consistent with Matlab's documentation?
>>>>>>>> 
>>>>>>>> Meaning that when outerposition is active …
>>>>>>>> 
>>>>>>>> I) position(1) is adjusted to the right (never to the left), to ensure
>>>>>>>> no object extends to the left of outerposition(1).
>>>>>>>> 
>>>>>>> Right now, no objects should extend left of outerposition(1). If there
>>>>>>> is a test case not respecting this rule, please let me know (only
>>>>>>> exception is if you make the plot window tiny).
>>>>>> 
>>>>>> I don't see any cases of that. What I do see is that you're requiring a
>>>>>> minimum of space between the outerposition and position boxes. So you're
>>>>>> adding features, correct?
>>>>>> 
>>>>>>>> II) position(2) is adjusted upward (never downward), to ensure no 
>>>>>>>> object
>>>>>>>> extends below the outerposition(2)
>>>>>>>> 
>>>>>>> 
>>>>>>> likewise
>>>>>> 
>>>>>> Your approach is not consistent with the "never downward" part, Correct?
>>>>>> 
>>>>>>>> III) position(3) is decreased (never increased) to ensure no object
>>>>>>>> extends beyond the outerposition(1)+outerposition(3).
>>>>>>>> 
>>>>>>> 
>>>>>>> likewise
>>>>>> 
>>>>>> Same.
>>>>>> 
>>>>>>>> IV) position(4) is decreased (never increased) to ensure no object
>>>>>>>> extends beyond the outerposition(2)+outerposition(4).
>>>>>>>> 
>>>>>>> 
>>>>>>> likewise
>>>>>> 
>>>>>> Same again.
>>>>>> 
>>>>>>>> When the position property is active the relationship is reversed. Its
>>>>>>>> been a couple of years since I looked that this in detail. Is my
>>>>>>>> understanding of how Matlab works consistent with yours?
>>>>>>>> 
>>>>>>>>>> 3) The positions have been shifted to the left relative to what was
>>>>>>>>>> specified by subplot.m. Originally, their left edges were very close 
>>>>>>>>>> to the
>>>>>>>>>> left edge of the outerpositon.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> What do you mean by "left edges" I don't get this point.
>>>>>>>> 
>>>>>>>> Opps ... not "left", but "right"!
>>>>>>>> 
>>>>>>>> My observation was that the right edge of the "position" has been
>>>>>>>> shifted to the left even though no object impinged upon the right edge 
>>>>>>>> of
>>>>>>>> the outerposition.
>>>>>>>> 
>>>>>>> 
>>>>>>> This is 9.5%. The problem is that we consider these minimum margins 13%
>>>>>>> to the left, 9.5% to the right, 11% to the bottom, 7.5 %to the top. This
>>>>>>> is compatible with ML for normal plots, but for subplots ML reduces this
>>>>>>> limits. Actually subplot in ML is quite a hack. We have different
>>>>>>> possibilities of achieving the same behavior. I make a proposal at the
>>>>>>> end.
>>>>>> 
>>>>>> Actually Matlab does not have "minimum margins". Those margins are set by
>>>>>> the "defaultaxisposition" and "defaultaxisouterposition" properties 
>>>>>> (present
>>>>>> in the root, figure and axes objects). Thus, they are controlled on by
>>>>>> m-file side by the user.  So I think the current synchronization isn't
>>>>>> compatible with Matlab, even for normal plots.
>>>>>> 
>>>>>>>>>> 4) The xticklabels and yticklabels should be tigher to the axes.
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> This is adjustable I think. Maybe it makes sense to calculate the
>>>>>>>>> distance of ticklabels from axes as percentage of axes sizes.
>>>>>>>> 
>>>>>>>> This isn't a documented by MathWorks. However, I did some experimenting
>>>>>>>> and found that ...
>>>>>>>> 
>>>>>>>> a) xlabel baseline is (2*fontsize + 7) points below the axis position
>>>>>>>> 
>>>>>>>> b) x-axis ticklabels are (fontsize + 1.5) points below the axis 
>>>>>>>> position
>>>>>>>> 
>>>>>>> 
>>>>>>> the bigger the font, the higher the distance from the axis
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>>>> c)  the right extent of the y-axis ticklabels is (20/fontsize + 1)
>>>>>>>> points to the left of the axis position.
>>>>>>>> 
>>>>>>> 
>>>>>>> so, the bigger the font, the closer to the axis? Interesting.
>>>>>> 
>>>>>> Keep in mind that the extent property is designed for type-settting, so
>>>>>> there is some white space included. Thus, the visual result does not give
>>>>>> the impression the characters are closer to the axis box. Matlab and
>>>>>> Octave's extents aren't yet consistent, so there is good reason not to
>>>>>> blindly copy this feature. However, I do think the spacing should rely 
>>>>>> upon
>>>>>> the font and not the axis.
>>>>>> 
>>>>>>> Do you believe these 3 approximations a,b and c are fixed or they could
>>>>>>> change proportionally to the axes width/height.
>>>>>> 
>>>>>> No they do not. This is easily seen my resized the figure with the mouse.
>>>>>> 
>>>>>>>> As this isn't documented by MathWorks, they could change it. So there 
>>>>>>>> is
>>>>>>>> no compelling reason to copy the specifics.
>>>>>>>> 
>>>>>>>> However, if there are multiple axes in the same figure, I think the
>>>>>>>> spacing between axes, ticklabels, and labels  should be consistent 
>>>>>>>> (assuming
>>>>>>>> the fontsize is consistent). Does that make sense? Other thoughts /
>>>>>>>> concerns?
>>>>>>>> 
>>>>>>>> Ben
>>>>>>> 
>>>>>>> SUGGESTION:
>>>>>>> 
>>>>>>> 1st step: Add a new property (hidden?) to the axes object:
>>>>>>> minmargins = [l b rt]
>>>>>>> with default value derived from defaultaxesposition:
>>>>>>> l=defaultaxesposition(0)
>>>>>>> b=defaultaxesposition(1)
>>>>>>> r=1-defaultaxesposition(0)-defaultaxesposition(2)
>>>>>>> t=1-defaultaxesposition(1)-defaultaxesposition(3)
>>>>>> 
>>>>>> I rather not see this done. The margins are currently defined by the user
>>>>>> on the m-file side by changing the position/outerposition of the axes. 
>>>>>> This
>>>>>> just looks more complicated to me with no added capability.
>>>>>> 
>>>>>>> 2nd step: Modify sync_positions so that it takes into account minmargins
>>>>>>> instead of defaultaxesposition. This would mean no change for all other
>>>>>>> plots, but for subplots it gives as the possibility to reduce the
>>>>>>> minimum margins from the frontend (e.g. reduce the ugly 9.5% to the
>>>>>>> right).
>>>>>> 
>>>>>> I'd prefer that the synchronization limit itself to the compatible
>>>>>> behavior. For activepositionproperty = "outerposition"
>>>>>> 
>>>>>> I) position(1) is adjusted to the right (never to the left), to ensure no
>>>>>> object extends to the left of outerposition(1).
>>>>>> 
>>>>>> II) position(2) is adjusted upward (never downward), to ensure no object
>>>>>> extends below the outerposition(2).
>>>>>> 
>>>>>> III) position(3) is decreased (never increased) to ensure no object
>>>>>> extends beyond the outerposition(1)+outerposition(3).
>>>>>> 
>>>>>> IV) position(4) is decreased (never increased) to ensure no object 
>>>>>> extends
>>>>>> beyond the outerposition(2)+outerposition(4).
>>>>>> 
>>>>>> In short the position property never expands, but retracts to keep itself
>>>>>> and its children inside the outerposition.
>>>>>> 
>>>>>> Conversely, when the activepositionproperty == "position", the
>>>>>> outerposition never contracts, but expands so as to encompass the axis 
>>>>>> and
>>>>>> its children.
>>>>>> 
>>>>>> One of the difficulties I'm having with subplot is that the 
>>>>>> synchonization
>>>>>> second guesses the specified position. In addition, the current solution
>>>>>> will be difficult to document.
>>>>>> 
>>>>>>> 3rd step: Optimize subplot.m making use of the new property minmargins
>>>>>>> 
>>>>>>> Only by setting minmargins to zero would eliminate most problems that we
>>>>>>> observe now with subplot. More sophisticated use of minmargins would
>>>>>>> even allow us to synchronize the insets in rows and columns of the
>>>>>>> subplot grid (AFAIK is what ML does, can you confirm this?).
>>>>>>> 
>>>>>>> What do you think? Should I add the a property minmargins or something
>>>>>>> similar?
>>>>>> 
>>>>>> 
>>>>>> Ok, Please propose a changeset with the default for  minmargins set to
>>>>>> zero so that we'll have a compatible solution.
>>>>>> 
>>>>>> Ben
>>>>>> 
>>>>> 
>>>>> Hmm, I have a suggestion. Since I thought that the implementation of
>>>>> sync_position for single plots (not subplots) is compatible with ML,
>>>>> and you are saying that it isn't, this should be the first issue to
>>>>> fix. Could you provide me with an example of a single plot that
>>>>> demonstrates the difference between ML and Octave?
>>>>> 
>>>>> As soon as I fix this we can come back to subplot again and continue
>>>>> our discussion.
>>>>> 
>>>>> BR
>>>>> 
>>>>> Kostas
>>>>> 
>>>>> First example is for activeposition == "position"
>>>>> figure (1)
>>>>> clf
>>>>> set (gca, 'position', [0 0 1 1], 'activepositionproperty', 
>>>>> 'outerposition')
>>>>> plot (0:1,0:1)
>>>>> axis ([0 1 0 1])
>>>>> outerposition = get (gca, 'outerposition')
>>>>> I've attached the result from Matlab.  The outerposition from Matlab is
>>>>> outerposition =   -0.1677   -0.1350    1.2903    1.2270
>>>>> Octave's result does not grow the outerposition.
>>>>> outerposition =   0   0   1   1
>>>> 
>>>> ouuuuups!!! I introduced this bug in 98772e4e8a2a. It used to work
>>>> correctly before. I have just pushed the fix, so it should be ok
>>>> again.
>>>> 
>>>>> If this example so that activeposition == "outerposition" ...
>>>>> figure (1)
>>>>> clf
>>>>> set (gca, 'position', [0 0 1 1], 'activepositionproperty', 
>>>>> 'outerposition')
>>>>> set (gca, 'outerposition', [0 0 1 1])
>>>>> plot (0:1,0:1)
>>>>> axis ([0 1 0 1])
>>>>> … then I see that the default axis position is restored. This does behave 
>>>>> in
>>>>> the manner you're suggesting, but it is not described by the 
>>>>> documentation.
>>>>> http://www.mathworks.com/help/techdoc/creating_plots/f1-32495.html
>>>>> This behavior is new to me (wasn't there when I examined this a few years
>>>>> back). So it appears I owe you an apology for the back-n-forth.
>>>>> I did a quick google, and found that someone else named "Ben" had figured
>>>>> out what is happening.
>>>>> http://undocumentedmatlab.com/blog/tag/outerposition/
>>>>> Rather than minmargins, may I suggest you use "looseinset" as Matlab does?
>>>>> For the subplots, the looseinset may be set to some reasonable value by 
>>>>> the
>>>>> subplot.m function.
>>>>> Ben
>>>>> 
>>>>> 
>>>>> Same article, but this time a direct link
>>>>> http://undocumentedmatlab.com/blog/axes-looseinset-property/
>>>>> Ben
>>>> 
>>>> I am working on looseinset now. It shouldn't take long to implement.
>>>> 
>>>> BR
>>>> 
>>>> Kostas
>>> 
>>> Hi Ben,
>>> 
>>> in the attached changeset you can find a first implementation of
>>> looseinset. The sync_position function relies now on looseinset instead
>>> of default_axes_position.
>>> 
>>> Known limitations: looseinset remains always in normalized units (since
>>> it is a hidden property I see no need to support other kinds of units)
>>> 
>>> Please test this patch and send me any comments.
>>> 
>>> BR
>>> 
>>> Kostas
>>> <looseinset-1a.changeset>
>> 
>> For consistency, how difficult is it to implement the units conversion? ... 
>> or maybe a more proper question is; Is there a reason that units conversion 
>> is prohibitive?
>> 
> 
> the units conversion itself is not a problem, but how different units
> for looseinset will be interpreted in sync_positions is not very
> straightforward. My main concern however is that by adding further
> checks and conversions to sync_positions it becomes heavier and heavier.
> Since looseinset is not supposed to be accessed by users maybe it makes
> sense to support only normalized units. This should be sufficient for
> achieving a decent subplot behavior. What do you think?

I'd thought the axes properties were always stored normalized, and that 
conversion only occurred when the user did a set/get from the m-file side. 
Meaning that accessing the axes properties on the c++ side would return values 
in the default units, and that units conversion had to be done explicitly. 

How does the conversion work on the c++ side? Can you not directly access the 
properties without triggering a conversion? ... if conversion always happens, 
then why isn't setting units="normalized" sufficient to fix the conversion in 
all cases (i.e. position, outerposition, tightinset, looseinset)? In either 
event, if units=="normalized" no conversion needs to be done, so I'm confused 
as why this is a problem. Am I making sense?

Ben