I am experiencing conflicts between xcos blocks. For example I am not able to connect a real [-2 1] output to a real [1 1] input.
Does anybody know, in general, what negative indices mean for datatype size?
This is explained # https://help.scilab.org/docs/6.1.0/en_US/scicos_model.html :
in
A vector specifying the number and size of the first dimension of regular input ports indexed from top to bottom of the block. If no input port exist in==[]. The size can be negative, equal to zero or positive :
If a size is less than zero, the compiler will try to find the appropriate size.
If a size is equal to zero, the compiler will affect this dimension by added all positive size
found in that vector
If a size is greater than zero, then the size is explicitly given.
In Safari 12.0.2 and Chrome 71.0.3578.98 on Mac Mojave 10.14.2, when setting the font-size using rem units, the actual size won't go below 9px.
See this example:
https://codepen.io/stephenjwatkins/pen/OrbGxL
My browser's font size is set to the default (16px) with a minimum font size set to 6px:
Setting text-size-adjust to none doesn't affect the problem. Firefox renders the size correctly.
The only thing that I've found to fix the problem is setting font-size: 0; to a parent element. For instance, if you add font-size: 0; to .container, the correct font size is rendered.
Does anyone know why it's not honoring the rem size below a certain threshold?
Chrome and its Blink rendering engine seem to have some non-obvious font-scaling rules. I'm unaware of any official comprehensive documentation, so let's go to the source.
(Note that I'm not an expert on Chromium internals generally or Blink renderer particularly. I've just been tracing through the source code and speculating on the most probable answers to the questions as posed.)
It seems to me that the engine calls upon the FontBuilder class during a redraw. This class has various dispatch methods that pass the DOM, zoom, and other relevant factors into what appears to be the crucial method: FontSize :: getComputedSizeFromSpecifiedSize. In that method, we see some juicy comments that address the points you've raised:
1. Why does setting font-size: 0; to a parent element fix it?
// Text with a 0px font size should not be visible and therefore needs to be
// exempt from minimum font size rules. Acid3 relies on this for pixel-perfect
// rendering. This is also compatible with other browsers that have minimum
// font size settings (e.g. Firefox).
2. Why is it not honoring the rem size below a certain threshold?
// We support two types of minimum font size. The first is a hard override
// that applies to all fonts. This is "minSize." The second type of minimum
// font size is a "smart minimum" that is applied only when the Web page can't
// know what size it really asked for, e.g., when it uses logical sizes like
// "small" or expresses the font-size as a percentage of the user's default
// font setting.
// With the smart minimum, we never want to get smaller than the minimum font
// size to keep fonts readable. However we always allow the page to set an
// explicit pixel size that is smaller, since sites will mis-render otherwise
// (e.g., http://www.gamespot.com with a 9px minimum).
3. For the curious, what are these minimum values when given relative units (eg x-small)?
// Strict mode table matches MacIE and Mozilla's settings exactly.
static const int strictFontSizeTable[fontSizeTableMax - fontSizeTableMin +
1][totalKeywords] = {
{9, 9, 9, 9, 11, 14, 18, 27}, {9, 9, 9, 10, 12, 15, 20, 30},
{9, 9, 10, 11, 13, 17, 22, 33}, {9, 9, 10, 12, 14, 18, 24, 36},
{9, 10, 12, 13, 16, 20, 26, 39}, // fixed font default (13)
{9, 10, 12, 14, 17, 21, 28, 42}, {9, 10, 13, 15, 18, 23, 30, 45},
{9, 10, 13, 16, 18, 24, 32, 48} // proportional font default (16)
};
// HTML 1 2 3 4 5 6 7
// CSS xxs xs s m l xl xxl
// |
// user pref
Interestingly, and a bit of an aside, the FontBuilder class dispatches to TextAutosizer :: computeAutosizedFontSize to scale the font size. This method uses hard coded values and a variable scaling factor:
// Somewhat arbitrary "pleasant" font size.
const float pleasantSize = 16;
// Multiply fonts that the page author has specified to be larger than
// pleasantSize by less and less, until huge fonts are not increased at all.
// For specifiedSize between 0 and pleasantSize we directly apply the
// multiplier; hence for specifiedSize == pleasantSize, computedSize will be
// multiplier * pleasantSize. For greater specifiedSizes we want to
// gradually fade out the multiplier, so for every 1px increase in
// specifiedSize beyond pleasantSize we will only increase computedSize
// by gradientAfterPleasantSize px until we meet the
// computedSize = specifiedSize line, after which we stay on that line (so
// then every 1px increase in specifiedSize increases computedSize by 1px).
const float gradientAfterPleasantSize = 0.5;
From these facts, we see there are a good number of hard-coded pixel values, with 9 and 16 being commonly sprinkled about the relevant code. These hard-codes, the presence of several rules to scale the font down to a limit, with the ability to override using font-size all seem to match the observations and suggest it's behaving as intended -- if not necessarily intuitively.
Also, I've found that the most recent comment posted in Chrome bug #319623 very much resembles your report.
Possibly related: when using relative units on the html tag, rem-based values defined elsewhere will have a lower bound of 9px.
See CodePen: http://codepen.io/larrybotha/pen/wKYYXE
Workaround: absolute unit on html, em unit on body. rems everywhere else.
It may be prudent to watch that bug for further developments, though maybe not with breath held. The last update was in 2015.
Github page
Looking generate_anchor_base method, which is Faster R-CNN util method in ChainerCV.
What is the base_size = 16? I saw in the Documentation that it is
The width and the height of the reference window.
But what does "reference window" mean?
Also it says that anchor_scales=[8, 16, 32] are the areas of the anchors but I thought that that the areas are (128, 256, 512)
Another question:
If the base size is 16 and h = 128 and w=128, Does that mean anchor_base[index, 0] = py - h / 2 is a negative value?
since py = 8 and and h/2 = 128/2
The method is a util function of Faster R-CNN, so I assume you understood what is the "anchor" proposed in Faster R-CNN.
"Faster R-CNN: Towards Real-Time Object Detection with Region Proposal Networks" https://arxiv.org/abs/1506.01497
base_size and anchor_scales determines the size of the anchor.
For example, when base_size=16 and anchor_scales=[8, 16, 32] (and ratio=1.0), height and width of the anchor will be 16 * [8, 16, 32] = (128, 256, 512), as you expected.
ratio determines the height and width aspect ratio.
(I might be wrong in below paragraph, please correct if I'm wrong.)
I think base_size need to be set as the size of the current hidden layer's scale. In the chainercv Faster R-CNN implementation, extractor's feature is fed into rpn (region proposal network) and generate_anchor_base is used in rpn. So you need to take care what is the feature of extractor's output. chainercv uses VGG16 as the feature extractor, and conv5_3 layer is used as extracted feature (see here), this layer is a place where max_pooling_2d is applied 4 times, which results 2^4=16 times smallen feature.
For the another question, I think your understanding is correct, py - h / 2 will be negative value. But this anchor_base value is just a relative value. Once anchor_base is prepared at the initialization of model (here), actual (absolute value) anchor is created in each forward call (here) in _enumerate_shifted_anchor method.
I have defined multiple constraints with Greater Than or Equal and Less Than or Equal. How does iOS decide which view will change its size when the superview changed its size?
Let's assume I have one view with constraints Greater Than 10 and Less Than 20.
And I got a second view with the constraints Greater Than 40 and Less Than 60.
Now the superview changes its size and the available space will increase by 10 pixel. I need a way to define which constraint is allowed to resize first (and take the 10pixel).
NSLayoutConstraint's priorities tell iOS & OS X which constraints to satisfy first.
If you have a view viewOne that you'd like to expand first, apply a constraint with visual format #"H:[viewOne(==9999#499)]". That will tell iOS that, after the required constraints 10≤viewOne≤20 & 40≤viewTwo≤60 are met, it should attempt to make viewOne 9,999 pixels wide, causing it to expand before viewTwo.
If you don't want to store the magic number 9999,
NSNumber* maxWidthForViewOne = #(20) ;
NSLayoutConstraint* constraint = [NSLayoutConstraint constraintsWithVisualFormat:#"H:[viewOne(==asBigAsPossible#499)]" options:0 metrics:#{#"asBigAsPossible":maxWidthForViewOne} views:views] [0] ;
I tested these in OS X, and I found that 499 (NSLayoutPriorityWindowSizeStayPut - 1) was the highest priority that allowed me to shrink viewOne by resizing the window. Since you're using iOS, you'll want to test what priority behaves as you like.
I've done a bit of a search but couldn't find an answer to this question.
For example:
sampleComponent.explicitMinWidth = 500;
sampleComponent.explicitWidth = 10;
Sets the width of the sampleComponent to 10, even though I've set the minimum width to 500.
The same thing seems to happen with width. In Adobe's documentation, it states that 'measuredMinWidth - Specifies the default minimum height and minimum width of the component, in pixels. Flex cannot set the size of a component smaller than its specified minimum size.'
I've tried setting the measuredMinWidth as well, same result.
Eventually, I tried every combination of minimum width settings I could, but they were all ignored when I set the width (or explicit width).
sampleComponent.measuredMinWidth = 300;
sampleComponent.minWidth = 300;
sampleComponent.explicitMinWidth = 300;
sampleComponent.width = 10;
Additionally, what is the difference between width and explicitWidth, in every case I've tried, they have performed identically (couldn't find any help on this either)
The min/max values are considered only when flex is calculating the size of the component. If you explicitly set values to width/height yourself those values will be ignored.
Which brings us to the issue of explicit: size of a component may be set by either specifying a fixed value, or a percentage. When setting a fixed value (in mxml) for width/height, that value gets saved in explicitWidth, explicitHeight etc, while percentages get stored in percentageWidth, percentageHeight and so on...
More info about this can be read on the adobe livedocs.