When comparing signed and unsigned integers of same size the signed one will be converted to unsigned. In a reasonably configured project compiler will warn about it.

In case of integers smaller than int, promotion to int happens first.

In case of signed and unsigned integers of different size, the smaller one will be converted to bigger one.

> Hardware and software that belongs to everyone. Waiting to be OSHWA certifie

> Hardware & Industrial Design All rights reserved. The hardware design, including but not limited to Are proprietary and the intellectual property of Juan Ramón. No commercial use or reproduction of the hardware is permitted without express authorization.

Same for software, the comparison table says MIT, other parts say GPL v3.

Also the whole concept of exam mode which is in any way effective seems contradictory with GPLv3. Any hardware means which would limit the ability to use modified version of software would violate GPLv3.

In the limitation section they are quite direct with it: "images used .. are mostly isometric and noise-free CAD-images" and "limited CAD vocabulary used in this study needs to be extended by including more sophisticated CAD tokens such as revolve operation, edge operation (e.g., fillets/chamfers)". It currently supports only series of pads (can be subtractive). Many simple beginner exercises of seemingly similar complexity don't fit those constraints. Some of the parts shown could be more naturally created using wider set of tools, but technically can be created using only pads.

So even if you tried with clean screenshot of simple 3d model, it will likely fail if camera settings aren't right, and it will fail if model can't be represented using series of pad operations. Anything containing spheres, cones, nearly all lathe parts, fillets which can't be included in 2d sketches will fail. In theory arbitrary extrusion angles are supported, but all examples showed only axis aligned parts.

That said I wouldn't be surprised if it failed even if you considered exact limitations not just similar complexity in your attempts.

Assuming images in the googledrive are the training data, "mostly isometric and noise-free CAD images" is a bit of understatement. All of them are at very specific angles using and single style. Specific solid gray infill color for "images", and white infill with weird shading around perimeter for "sketches". Both with white background and pixelated non antialised 1px lines. No reason to expect it capable of processing anything which doesn't have exactly same visual style. For practical product that would have to be solved but that wasn't really the point of this research. All the style transference papers have show that it's more or less solvable problem, but for a paper exploring what model architecture and 3d representation could work best for AI cad it seems like unnecessary distraction that would only bloat the training costs and time. Most annoying part is that it makes hard to test the model with your own inputs.

I would even argue that for basic modelling majority of tools/features in CAD operate at the abstraction closer to CSG for describing what and B-rep is only treated as how. Just like good chunk of code based CAD use combination of CSG for what and triangle mesh based geometry engine for how. That's assuming you consider standard 2d->3d operations (extrude, revolve, sweep along arbitrary 2d profile) as valid primitives for CSG.

User comes into direct contact of B-rep in very specific situations: 1 doing operations like fillets/chamfers/draft/thickness based on intermediate geometry, 2 attaching sketches or other features to generated geometry or using generated edges (instead of new sketches) for guiding operations like complex sweeps, 3 surface based modelling workflows where you build up the the solid from individual faces typically including complex curved surfaces.

In case of 1 and 2 the the dependency on b-rep based representation is only marginal, in theory you could select edges in triangle mesh based underlying representation but the final result but quality of result wouldn't be as nice and TNP issues for parametric model editing would likely be even bigger than it is for existing CAD. That's not really CSG territory anymore but isn't exclusive to B-rep either, and involves a bunch of work that's outside the scope of B-rep. In non parametric mesh modellers with more destructive editing workflows like blender chamfers and fillets work fine. And if anything for reliable parametric models you often want to limit dependencies on intermediate geometry as that depends on CAD keeping track of where each edge/face originated from outside the b-rep and increases the chance of TNP issues.

3 is critical for industrial design containing large amount of complex curved surfaces like cars and other consumer products, but there are also many more technical parts where it can be completely ignored. Cad tutorials for beginner tutorials almost completely ignore this category of cad modelling. The part about not being exclusive to b-rep also applies for surface modelling part.

Just switching between left to right or right to left wouldn't be that useful but it also permits to interleave the subexpression evaluation. Grouping memory fetches/writes, taking into account how many execution units and registers of different kinds a CPU has can have some performance benefits.

For example if you have something like `++a[0] + ++a[1] + ++a[2] + ++a[3]` instead of evaluating each increment one by one both GCC and Clang will vectorize it loading all 4 values from memory using single simd instruction, incrementing and then writing result back to memory. And if you add fifth one (but not 8) which needs to be handled using regular instruction, that will be done after the first 4. If standard defined that left subexpression of addition is fully evaluated before the right expression that wouldn't be allowed.

In practice half-assed HID drivers by OS, badly designed OS<->application APIs, hardware manufacturers copy pasting HID descriptors from other devices, not following the standard properly, firmware bugs getting fixed with drivers instead of firmware fixes, intentional discrepancies from standard, console manufacturers reinventing the wheel has lead to the current mess.

It even works correctly for 0% and 100% chance events. Assuming 0 is counted as 0 - For 0% there are 0 numbers less than 0 on dice so chance of throwing number less that is 0/100=0%. For 100% all 100 numbers are less than 100 so no matter what the result of throw is you will succeed.

If you knew all the items ahead of time and didn't require adding/removing them incrementally you could build optimal skiplist without randomness. But in such situations you likely don't need a skip list or BST at all. Binary search on sorted list will do.

As for where it came from to me it very much feels like the defense of serif typefaces is largely typographers defending existence of their craft and people talking past each other with overgeneralized claims. There is definitely value in the art and craft of typography and I respect that. It would be too bland if everything used plain sans serif fonts that barely differ from each other, and you can definitely mess up typography making text hard to read when done badly. But I also believe that there is plenty of things based on traditions and "everyone knows x because that's how we have always done it".

As for sans serif for screens the obvious reason and also thing that comes up multiple times is low resolution text. At certain resolution there are simply not enough pixels for serifs. The author of paper suggest that with modern high resolution screens this argument doesn't stand. My personal opinion is that it's not a big issue at sufficiently high text size. But even on somewhat modern 2560x1440 screen I can find plenty of UI elements that have only 7-8 pixels high labels. Not everyone is using retina displays and not everything is long format text. Screen resolutions have increased, but so have information density compared to early computer screens, although there is recent trend of simplifying UI to the point of dumbing it down and adding excessive padding all over the place. There are other screens beside computers and mobile phones, many of them not very high resolution even by standards of early computer screens. It doesn't make sense to put high resolution screen and Linux computer in every little thing. Problem is made worse by lack of antialised text sometimes due to screen, sometimes MCU memory and compute limitations. You are probably not going to have modern font rendering stack on something like black and white washing machine screen, gas station pump or thermostat The research multiple times mentioned stuff like low resolution, but it hardly ever quoted hard numbers in a meaningful way. How many pixels a typeface needs to be comfortably represent serif? How many arcseconds? Surely there must be research related to that one. This might be part of problem for some comparative research - can't compare readability of serif/sans serif if there is no serif typeface at those resolution. Stuff like point 10 or point 12 without additional details is meaningless.

Some personal anecdote -> text antialising has huge effect. Made a sample text of serif and sans serif font and zoomed out to the point where lower case letters are ~6px high. I wouldn't expect there to be enough resolution for serif but you can perceive surprising amount of detail in letter shapes. Zoomed in on screenshot it's a blurry mess, but at normal zoom level the serif letters are fine. It's readable but wouldn't consider either of 2 comfortable. When scaled up to 8px both pieces were still harder to read than same height text in UI labels. Why is that? Why is one identical height sans serif text much more readable than other? Are UI labels better pixel aligned? Is it due to subpixel antialising? That's on a 90deg rotated screen, is subpixel antialising even working properly there?

Just for fun switch OS UI font to serif. Due to font sizing inconsistency it ended up being 1 pixel shorter (7px) than same size default UI font. Can those even be considered serifs when they are hardly a pixel each? It felt weird, nowhere near as bad I expected, but still weird.