Ranges are a (start, end) pair of iterators that support begin/end -- think of them like a subset of containers that just provide access to the iterators over them. They also support the end iterator being a different type to the sstart iterator, supporting things like sentinel iterators (e.g. null pointer checks).
The next standard library supports using the standard algorithms with ranges, so you can say things like `std::sort(v)` instead of `std::sort(v.begin(), v.end())`.
IIUC, views are ranges that can adapt the results of the underlying object without changing the contents of that object, such as a lower-case view, or a reversed view. These work by doing the lower-case conversion on dereference, or swapping the increment/decrement operations.
Destructors in C++ aren't just for making sure you leak memory. They are used for many lifetime controlled things such as:
1. general resource cleanup (file handle, database connection, etc.) using RAII (Resource Aquisition Is Initialization);
2. tracing function entry/exit.
It does work in rust. you just cannot rely on Drop for memory-safety. If you mem::forget a struct that holds onto some other resource then all that means is that you're committing that resource to the lifetime of the process. We usually call that a leak but it can be intentional.
In my experience, try-with-resources is inferior to RAII, since it's very easy to forget (that is, it's very easy to do "Foo x = bar();" instead of "try (Foo x = bar()) { ... }"), leading to resource leaks. More than once I have added a finalizer to an AutoCloseable class just to warn loudly if close() hasn't been called; unfortunately, there's no way that I know of to suppress the finalizer once close() is called, so the GC still has to do all the work to call the finalizer even when the class was used correctly.
And the nightmare of determining who owns the APIs in things like SQL, BSD, POSIX, libc, speadsheet functions, the cairo and HTML canvas path APIs, HTML DOM, and more. Not to mention compatibility projects like wine, DOSBox, and various emulators. If printf is copyrighted, it will affect C, PHP, python, the command line application, and others. Then there are things like where C# is clearly influenced by Java.
The whole programming landscape would need to be audited.
A large majority of those APIs are protected by ISO, ECMA, OpenGroup with their respective copyrights and many of them aren't available for free, specially ISO ones.
You just them as free beer, because a couple of developers have decided to put their money for you, specially the ISO ones.
What about something like "in_order_traversal", which is an algorithm and you need to keep track of the traversed stack. You could either write it with functions in which case you would need to pass the stack as a parameter and have a constructor/initial state version of the function that passes the stack to the main function, or have a functor/function class that keeps the stack internally.
A better comparison would be the yearly death toll due to flu for the US, noting that the current COVID-19 death toll is over a 2-3 month period. Preliminary estimates for the 2019-2020 US flu season [1] put the number of deaths for a 6 month period (Oct 2019-Apr 2020) at 24k-62k, so the COVID-19 attributed deaths are 2x-4x that of flu over half the time (3 months vs 6 months).
The audio generation is split into packets or chunks of audio. There are two general methods of storing/generating these chunks:
1. LPC/formants -- building the audio using the LPC (linear predictive coding) or frequency (formant) parameters and a residual carrier for the difference;
2. OLA (overlapped add) -- combining and overlapping audio split at individual wave (peak to peak) packets.
The different systems (klatt, MBROLA, etc.) build on these basic techniques. The *OLA systems are more space intensive, as they need more of the audio data to synthesize the voice, but tend to result in more natural voices.
The other complexity is how the individual phonemes (building blocks of speech) are stored. Different languages and accents have different sets of phonemes, so more complex languages require more data. Systems like MBROLA store the data as diphones (from the mid-point of the first phoneme to the mid-point of the second), to make it easier to join the phonemes. There are more diphones, although not all combinations are in a given language and accent.
This data is controlled by different prosodic parameters (e.g. pitch and duration). Neural nets can be used to control these parameters, or techniques like decision trees and probabilistic models.
IIUC, there are two approaches to neural nets when using audio generation: 1) generate the LPC/formant parameters; 2) generate the audio directly. These can either operate on phonemes, or on the text directly. Operating on the text directly limits the voice to a particular language and accent, but potentially allows the neural net to infer pronunciation rules itself.
Hmmmm.... In my experience, for (neural) TTS the dominant option is to have one model to generate a melspectrogram from the text (handling prosody) and a second model for synthesizing samples from the melspectrogram. (Tacotron, Lyrebird, and this Facebook group are all doing this.) There's certainly research projects on going directly from text to samples, but it's not the currently winning strategy... Maybe eventually, though. The Text->Mel portion specializes the prosody and pronunciation problem, and provides a nice place to add extra conditioning.
On the vocoder side: LPC, F0, etc can all be estimated from a reasonably sized melspectrogram; for the most part, these neural models are just letting the big vocoder model handle all of these things which are traditionally (fragile!) subtasks. The question is which "classical" parts are both cheap and reliable: you can compute these on the side and lighten the neural network's burden. LPC is great for this.
Then it’s probably not a vitamin if we can synthesize enough of it to function fine.
The definition of vitamin is that it’s gotta be organic, necessary for healthy functioning, and we must be incapable of synthesizing enough of it to survive, even if it’s also available in our food. This is why cholesterol isn’t a vitamin; it’s necessary for us to live, but we’re fully capable of synthesizing enough of it on our own.
That's interesting. So what you have is some sort of similarity metric that is colour based. You could define it as being 1 for an exact match, and 0 for not matching, so cyan, etc. would be 0 red, while orange may be slightly red (e.g. 0.1), and pink may be slightly more red (e.g. 0.25). This would be a 3D function/surface.
This would allow you to model classes of colours, like purples. Shades of a colour could then be any similar colour in the range 0 to 0.5 (or 0.25).
Yes, this is what Delta E in the CIELAB color space is meant for. But in RGB color space this concept doesn't make sense; well, only if you would accept a non linear similarity metric - but then what is the metric for, if you need to apply a curve to it to normalize it? But still, this is different from modeling 'shades' of a color (if we say 'shades' are varying brightness in RGB space using the 0.21/0.72/0.7 brightness conversion - but again, I argue that 'shades' is an ambiguous concept).
My point is, again, that colors are a much more difficult concept than some in this discussion are making it out to be, and 'distance between colors' is more complex still.
It depends on the show and the presenter. John Humpfreys was very pro-Leave -- there was one segment on the Today program where he was interviewing someone advocating for a people's vote and angrily asked them how working people would feel betrayed (or something to that effect); meanwhile, he was very soft when interviewing Gove and other Tories. The same applies to how the Today program focused its vox pops on Leave-voting areas.
Likewise, if you look at something like The News Quiz, that and the presenters/guests are left wing and pro-Remain.
Usually the problem is that you can’t realistically change the interface, because too much other software relies on it, and having all that software rewritten would be too costly, and also risky. In addition, as a sibling mentions, the reason the old interface is a pain point is often that it exposes implementation details in a way that prevents you from rearchitecting the implementation. In that situation, adapters typically won’t help.
Even if you don't change the interface, by doing fun things like writing types in go that accept strings or ints as ints to strangle a perl server binary and proxying unimplemented handlers, you can still end up with problems. We started having issues with our db getting knocked over by callbacks from our server fleet on an endpoint we hadn't even rewritten yet. Turns out the slowness of perl handling the tls connections had shielded the db and forced retries, switching to go meant the db was hammered with the concurrent requests from perl workers, unhindered by the tls handshake.
The next standard library supports using the standard algorithms with ranges, so you can say things like `std::sort(v)` instead of `std::sort(v.begin(), v.end())`.
IIUC, views are ranges that can adapt the results of the underlying object without changing the contents of that object, such as a lower-case view, or a reversed view. These work by doing the lower-case conversion on dereference, or swapping the increment/decrement operations.