10,000 Matching Annotations
  1. Mar 2021
    1. A proposal to specify the path for bury with classes as values of a hash arg: {}.bury(users: Array, 0 => Hash, name: Hash, something: 'Value') # {user: [{name: {something: 'Value'}]} So all absent nodes could be created via klass.new

      Didn't understand it at first, but now I think it's a pretty clever/decent solution.

      Just a bit more verbose than one might like...

      At first I had reservations about the fact that this requires you to pass a hash ... or rather, once you start using a hash as your "list", you can't just "switch back" to an array (a "problem" I've noticed in RSpec, where you have some tags that are symbols, and some that are hashes: you have to list the symbols first: describe 'thing', :happy_path, driver: :chrome):

      {}.bury(users: Array, 0, 'Value')
      

      But I think that's okay in practice. Just use a hash for all "elements" in your list:

      {}.bury(users: Array, 0 => 'Value')
      
    2. I think the issues/problems specified in the comments are not present with a Hash-only implementation. :) I would be supportive of re-considering this feature just for use with a Hash, where I believe 80% of the real-life use cases would (and do) exist. I have encountered this need before in the wild, but not with Arrays.
    3. data = {}.extend XKeys::Auto # Vs ::Hash, uses arrays for int keys data[:users, 0, :name] # nil data[:users, 0, :name, :raise => true] # KeyError data[:users, :[], :name] = 'Matz' # :[] is next index, 0 in this case # {:users=>[{:name=>"Matz"}]} pick = [:users, 0, :name] data[*pick] # Matz data[:users, 0, :accesses, :else => 0] += 1 # {:users=>[{:name=>"Matz", :accesses=>1}]}
    1. Yes I fully understood that this was going to be a cryptic puzzle game and that it required research outside of the game. I expected this to have ARG elements and require abstract thinking. However, I also expected it to be longer than 2 minutes of content. You are given 10 pages to read in-game, they might as well have just been screenshots posted somewhere on the internet. And you have no way to input your solutions in game.
    1. Proton is a new tool released by Valve Software that has been integrated with Steam Play to make playing Windows games on Linux as simple as hitting the Play button within Steam. Underneath the hood, Proton comprises other popular tools like Wine and DXVK among others that a gamer would otherwise have to install and maintain themselves. This greatly eases the burden for users to switch to Linux without having to learn the underlying systems or losing access to a large part of their library of games. Proton is still in its infancy so support is inconsistent, but regularly improving.
    1. I've been made aware of a "Compatibility tool to run DOS games on Steam through native Linux DOSBox" called "steam-dos". It can be found on https://www.github.com/dreamer/steam-dos . I pulled this tool from git and using it as the the steam play compatibility tool Megarace 2 runs without issue. Saving both settings and games works again! There is no keyboard support for controlling the vehicle in game but both mouse and joystick/gamepad work. To get around a missing launcher.exe error I copied "MegaRace 2.exe" to the same folder as the original and renamed the copy to "Launcher.exe". Linux users: in your MegaRace 2 folder (steamapps/common/MegaRace 2/) create a symbolic link to start.sh named Launcher.exe. This allows the game to launch through Steam. This also allows you to put time on the game through Steam, hitting that coveted 5 minute mark that makes creating a review possible. With that out of the way, the game itself is a nice touch of nostalgia but the port is absolutely terrible. I don't remember it being quite this difficult to install off the 2 CDs. The game won't launch at all without tweaking. Can't save the config settings. Can't save the game at all in fact. While I really like MegaRace 2, you unlock tracks by completing the previous ones. Since the game can't be saved, I end up running The Foundry track over and over until I'm sick of it.So I'm torn. I love the game but I hate the completely broken port. For $3 and a local install of DOSBOX it can be made to work so I will recommend it anyway.
    1. The positive reviews are clearly friends of the developer, as this is an extremely low-quality Unreal game, the kind you'd expect from a student project or a 24-hour Game Jam, not something being sold on Steam.
    1. Application: 3-D Shape RegistrationAn important problem in model-based recognition is to find the transformation of a set of datapoints that yields the best match of these points against a shape model. The process is oftenreferred to asdata registration. The data points are typically measured on a real object by rangesensors, touch sensors, etc., and given in Cartesian coordinates. The quality of a match is oftendescribed as the total squared distance from the data pointsto the model. When multiple shapemodels are possible, the one that results in the least total distance is then recognized as the shapeof the object.Quaternions are very effective in solving the above least-squares-based registration problem.
    1. My preference here is biased by the fact that I spend everyday at work building web components, so Svelte's approach feels very familiar to slots in web components.

      first sighting: That <template>/<slot> is part of HTML standard and the reason Svelte uses similar/same syntax is probably because it was trying to make it match / based on that syntax (as they did with other areas of the syntax, some of it even JS/JSX-like, but more leaning towards HTML-like) so that it's familiar and consistent across platforms.

    2. If I were to sum up why in one sentence, it's because I don't miss useEffect. I understand why it exists, I understand the approach React takes, and there are benefits of its approach. But writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. With Svelte I don't have that lingering feeling, and that's what I've come to enjoy.
    3. Svelte is different in that by default most of your code is only going to run once; a console.log('foo') line in a component will only run when that component is first rendered.
    4. Here's where I start to have a preference for Svelte; the two are very similar but once I got used to Svelte I found that React felt like jumping through hoops. You can't create a worker instance, it has to go in a useRef, and then you can't easily pull code out into a function without then requiring useCallback so it can be a safe dependency on useEffect. With Svelte I write code that's closer to "plain" JavaScript, whereas in React more of my code is wrapped in a React primitive.

    Tags

    Annotators

    URL

    1. A business with a low barrier to entry would be those people in poor countries who “wash” your windscreen at traffic lights. A bucket, a cloth, some water and you are in business. A business with a high barrier to entry might be airlines: planes are expensive, staff with the right skills hard to find, the necessary permits to fly hard to obtain.
    1. The key to any good adventure game, really any good game at all, is to guide the player toward understanding the game world's internal logic, even if that logic only makes sense in the game world. This internal logic is what differentiates a game that encourages clever, creative problem-solving from a game like Antventor, which is a maddening exercise in arbitrary, spaghetti-against-the-wall nonsense.In the old text-based adventure games, the internal logic was grammatical, often based on a simple verb-object combination. This simple structure encouraged absurd combinations, sometimes with no results, sometimes with hilarious results, and sometimes with surprisingly fruitful results. The game would subtly nudge you toward the correct solution with hints and consequences, and you would gradually learn the kinds of actions that made sense in the world and the types of consequences you could reasonably expect. Only after establishing those baselines would ambiguity start to creep in ("I could do this, but should I...?", "Is that item meant for here or there?"). As the genre aged, puzzles gradually grew more intentionally obtuse and absurd as a means to make the game "harder". Ultimately, this obscurantism was a sign of a dying genre, catering to a narrower and narrower echo chamber of hardcore fans, as the gaming world in general grew less patient with the kind of experimentation this genre was first built on.Unfortunately, Antventor takes inspiration from those later games. It is gorgeously animated, but the game design is awful. There is no scaffolding, and little to no internal logic to speak of. The interaction targets are often tiny, hidden, sometimes out of focus, and sometimes completely arbitrary. Combine this with an ever-expanding collection of items and screens, and the game quickly devolves into pointless trial-and-error with thousands of combinations.

      .

    1. "BEER" is a simple one-level platformer with an interesting concept: after some time a shadow of yourself appears and repeats every movement you've made. If the shadow catches you - it's a game over. With the passage of time, more shadows appear. Shadows will relentlessly chase you until they catch you. As much as I know, there is no victory: you will have to jump platforms and collect presents until you are caught. At one point, there are so many shadows, it's unavoidable to be touched by one of them. To delay this moment, you may move slowly, so it's easier to keep track of shadows. You may establish a specific route, so the shadows follow a predetermined pattern. Nevertheless, at one point there will be just too many shadows to avoid.
    1. Not Recommended 1.0 hrs on record Posted: February 23 Product received for free Steam is the happy new platform for another dev who likes to spam copys of the same thrash game on steam so he can bulk sell keys for it.

      .

    1. Nevertheless, co-hyponyms are not necessarily incompatible in all senses. A queen and mother are both hyponyms of woman but there is nothing preventing the queen from being a mother.

      not necessarily incompatible in all senses.

      so is this only a concern/possibility when the word in question is a polyseme?

      but there is nothing preventing the queen from being a mother

      The meaning of the "incompatibility" relation seems really ambiguous. What does that mean precisely?

      And how would we know for sure if an incompatibility (such as a peach is not a plum) or lack of incompatibility (a queen can be a mother and a mother can be a queen) is a sufficient condition to cause it to be or not be a co-hyponym?

      Oh. I guess it says

      Co-hyponyms are often but not always related to one another by the relation of incompatibility.

      so it actually can't ever be used to prove or disprove (sufficient/necessary condition) that something is a co-hyponym. So that observation, while interesting, is not helpful in a practical / deterministic way...

    2. It consists of two relations; the first one being exemplified in "An X is a Y" (simple hyponymy) while the second relation is "An X is a kind/type of Y". The second relation is said to be more discriminating and can be classified more specifically under the concept of taxonomy.

      So I think what this saying, rather indirectly (from the other direction), if I'm understanding correctly, is that the relationships that can be inferred from looking at a taxonomy are ambiguous, because a taxonomy includes 2 kinds of relationships, but encodes them in the same way (conflates them together as if they were both hyponyms--er, well, this is saying that the are both kinds of hyponyms):

      • "An X is a Y" (simple hyponymy)
      • "An X is a kind/type of Y".

      Actually, I may have read it wrong / misunderstood it... While it's not ruling out that simple hyponymy may sometimes be used in a taxonomy, it is be saying that the "second relation" is "more specifically under the concept of taxonomy" ... which is not really clear, but seems to mean that it is more appropriate / better for use as a criterion in a taxonomy.


      Okay, so define "simple hyponymy" and name the other kind of hyponymy that is referenced here.

    1. Taxonomies are often represented as is-a hierarchies where each level is more specific (in mathematical language "a subset of") the level above it. For example, a basic biology taxonomy would have concepts such as mammal, which is a subset of animal, and dogs and cats, which are subsets of mammal. This kind of taxonomy is called an is-a model because the specific objects are considered as instances of a concept. For example, Fido is-an instance of the concept dog and Fluffy is-a cat.
    2. In the simple biology example, dog is a hypernym and Fido is one of its hyponyms. A word can be both a hyponym and a hypernym. For example, dog is a hyponym of mammal and also a hypernym of Fido.

      I wish they hadn't used tokens/objects in this example. Wouldn't it be just as clear or clearer if they had stuck to only comparing types/classes?

      It may be okay to mix them like that in some contexts, but in other cases it seems like this would be suffering from ignoring/conflating/[better word?] the Type–token distinction.

      Does linguistics just not make the https://en.wikipedia.org/wiki/Type%E2%80%93token_distinction ?

      This statement seems to reinforce that idea:

      words that are examples of categories are hyponyms

      because an example of a category/class/type could be either a sub-class or an instance of that category/class/type, right?

    1. Not to be confused with tree (graph theory), a specific type of mathematical object.

      Confusing: https://en.wikipedia.org/wiki/Tree_(data_structure) says

      Not to be confused with tree (graph theory) "Tree (graph theory)"), a specific type of mathematical object. but https://en.wikipedia.org/wiki/Tree_(graph_theory) redirects to https://en.wikipedia.org/wiki/Tree_structure and https://en.wikipedia.org/wiki/Tree_structure is in category Trees (data structures) So is one a subtype/hyponym of the other ... or what?? How are they related? Skimming the articles a bit, esp. the first paragraph which clearly states as much ( :) ), I believe the answer is: a tree (data structure) is an implementation (in a programming language) of / or a "type that simulates" a hierarchical tree structure. a tree (data structure) is the computer science analogue/dual to tree structure in mathematics

    1. (Not answered on this stub article)

      What, precisely, is the distinction/difference between a semantic class and a semantic field? At the very least, you would say that they are themselves both very much within the same semantic field.

      So, is a semantic class distinct from a semantic field in that semantic class is a more well-defined/clear-cut semantic field? And a semantic field is a more fluid, nebulous, not well-defined field (in the same sense as a magnetic field, which has no distinct boundary whatsoever, only a decay as you move further away from its source) ("semantic fields are constantly flowing into each other")?

      If so, could you even say that a semantic class is a kind of (hyponym) of semantic field?

      Maybe I should pose this question on a semantics forum.

    1. Property types (e.g. "height in metres" or "thorny") are often understood ontologically as concepts. Property instances (e.g. height = 1.74) are sometimes understood as measured values, and sometimes understood as sensations or observations of reality.
    2. The words type, concept, property, quality, feature and attribute (all used in describing things) tend to be used with different verbs. E.g. Suppose a rose bush is defined as a plant that is "thorny", "flowering" and "bushy". You might say a rose bush instantiates these three types, or embodies these three concepts, or exhibits these three properties, or possesses these three qualities, features or attributes.
    1. Categorization is the human ability and activity of recognizing shared features or similarities between the elements of the experience of the world (such as objects, events, or ideas), organizing and classifying experience by associating them to a more abstract group (that is, a category, class, or type),[1][2] on the basis of their traits, features, similarities or other criteria.
    1. semantic domain or semantic field

      What, then, is the difference between a semantic domain and a semantic field? The way they are used here, it's almost as if they are listing them in order to emphasis that they are synonyms ... but I'm not sure.

      From the later examples of basketball (https://hyp.is/ynKbXI1BEeuEheME3sLYrQ/en.wikipedia.org/wiki/Semantic_domain) and coffee shop, however, I am pretty certain that semantic domain is quite different from (broader than) semantic field.

    2. For instance English has a domain ‘Rain’, which includes words such as rain, drizzle, downpour, raindrop, puddle.

      "rain" seems more like a semantic field — a group of very related or nearly synonymous words — than a semantic field.

      Esp. when you consider the later example of basketball (https://hyp.is/ynKbXI1BEeuEheME3sLYrQ/en.wikipedia.org/wiki/Semantic_domain) and coffee shop, which are more like the sense of "field" that means (academic/scientific/etc.) discipline.

    3. For instance, in basketball there are many words that are specific to the sport. Free throw, court, half court, three pointer, and point guard are all terms that are specific to the sport of basketball. These words make very little sense when used outside of the semantic domain of basketball.

      But this example seems so different than the first example they gave, "rain", which seems more like a semantic field — a group of very related or nearly synonymous words.

    1. For example, in the Dyirbal language, the morpheme balam marks each entity in its noun class with the semantic property of edibility,[8] and Burmese encodes the semantic property for the ability to cut or pierce. Encoding the functional property for transportation, housing, and speech are also attested in world languages.
    2. Basic semantic properties include being meaningful or meaningless – for example, whether a given word is part of a language's lexicon with a generally understood meaning

      The "for example" being where it is, is confusing, and I believe should be left out.

      I think this would have been better written as:

      Basic semantic properties include, for example, being meaningful or meaningless (that is, whether a given word is part of a language's lexicon with a generally understood meaning); polysemy, ..

    3. those aspects of a linguistic unit, such as a morpheme, word, or sentence,

      Speaking of ambiguity...

      Are the examples in the list "such as a morpheme, word, or sentence" examples of

      • aspects of a linguistic unit or of:
      • linguistic units themselves ?

      Unless you are already fairly familiar with those terms -- in particular, linguistic unit -- it may not be clear.

      I believe these are given as examples of "linguistic unit", in order to clarify what we mean by "linguistic unit" — perhaps (ironically) precisely because many people would be unfamiliar with that expression/term.