Readit News logoReadit News
Aramgutang commented on Voice assistants are not doing it for big tech   theregister.com/2022/11/2... · Posted by u/rntn
_dain_ · 3 years ago
>Voice assistants are basically just mainstream non-visual command-lines, and it's unsurprising to me that something that relies heavily on memorization and extremely specialized "skills" isn't quite taking off in the way it was imagined.

This got me thinking. Voice recognition is basically a commodity now .. there are open source AI engines that can do it offline really well. So the recognition part is solved, you can just grab it from your distro's package manager. Now there's just the language part.

Thing is, I don't want to speak to my computer using English. Aside from the enormous practical problems in natural language processing you've outlined, I just find the idea creepy[1].

What I want is to unambiguously tell it to do arbitrary things. I.e. use it as an actual computer, not a toy that can do a few tricks. I.e. actually program it. In some kind of Turing complete shell language that is optimized for being spoken aloud. You would speak words into the open source voice recognizer, it writes those to stdout, then an interpreter reads from stdin and executes the instructions.

Is there any language like this? What should it look like?

And yeah that would take effort to learn to use it right, just like any other programming language; so be it. This would be a hobbyist thing.

[1] https://i.kym-cdn.com/photos/images/original/002/054/961/748...

Aramgutang · 3 years ago
That reminds me of the handwriting recognition approach [1] used in old Palm Pilot devices. Even though the shapes it expected you to draw resembled the corresponding letters, you would never draw them like that if you were writing on paper.

You knew that you were drawing something designed for a computer to recognise as unambiguously as possible, while being efficient to draw quickly and easy to learn for you. I feel like that's the kind of notion that voice interfaces should somehow expand upon.

[1] https://en.wikipedia.org/wiki/Graffiti_(Palm_OS)

Aramgutang commented on Show HN: Visualising real-time Sydney bus congestion with Marey charts   jakecoppinger.com/2022/11... · Posted by u/jakecopp
chewxy · 3 years ago
SydneyTransitGraph.com - there are multiple bus routes for 412, 423, 433
Aramgutang · 3 years ago
Those other routes aren't in Sydney, though. Regional bus route numbers sometimes overlap with Sydney route numbers.
Aramgutang commented on Show HN: Visualising real-time Sydney bus congestion with Marey charts   jakecoppinger.com/2022/11... · Posted by u/jakecopp
jahnu · 3 years ago
Have things improved since I lived there in 2010?

The busses were constantly late (sometimes waiting an hour for a bus from Darlinghurst to the eastern suburbs on the weekends) Unbelievable noisy. Walking through the CBD on a workday morning was deafening. Engines with no acoustic dampening at all. Reckless drivers. Gave up trying to ride a bike. Just too dangerous and aggressive bus and car drivers :(

Aramgutang · 3 years ago
I definitely don't find myself complaining about them as I much as did 10 years ago. Back then, one of my local bus stops in Newtown had "what is the point of this?" written in marker over the timetable, and everyone who saw it smiled in agreement.

However, this could be explained by today's GPS tracking data, rather than improvements in reliability. When you open your transit app, you want to know when the next bus is, so you can find an alternative if the wait is too long. When it tells you the next one is in 3 minutes (which is an accurate estimate because of the GPS), you don't actually care if that bus is running 18 minutes later than originally scheduled.

For the bus I use for my commute, I don't leave either the house or the office until I see its GPS tracker pass certain points of the route. I've never had to wait for more than 3 minutes at a bus stop doing that. On occasions where there is no GPS feed, I treat that bus as "theoretical", and don't risk going out to try to catch it at its scheduled time, unless I'm desperate. But every time I did risk it, it ended up arriving right on schedule.

So I'd say the experience of catching buses has profoundly improved, but not necessarily because the reliability has improved.

And 10 years ago, we didn't have Opal readers, which are great, since together with having digital driving licenses on our phones, it has allowed many of us to completely forgo carrying a wallet.

Bus drivers are still as reckless and grumpy as they used to be though.

Aramgutang commented on FTX balance sheet, revealed   ft.com/content/0c2a55b6-d... · Posted by u/parenthesis
lysecret · 3 years ago
Wait will the forced liquidation crush a large part of crypto ?
Aramgutang · 3 years ago
There isn't much there to liquidate that still has any worth. They didn't have significant holdings of any of the major assets. That's kind of the main reason they were insolvent.
Aramgutang commented on Stop using utcnow and utcfromtimestamp   blog.ganssle.io/articles/... · Posted by u/tomerbd
22c · 3 years ago
I'd say the main issue here is that in the article, we have

> ts = 1571595618.0

This a timestamp, there is no TZ data required.

> x = datetime.utcfromtimestamp(ts)

Now for some reason the developer cares about UTC all of a sudden?

If the developer doesn't care about the TZ, they should use:

datetime.fromtimestamp(ts)

Aramgutang · 3 years ago
A timestamp doesn't require TZ data because the timezone of the unix epoch is defined in UTC. To convert a timestamp into a meaningful datetime value, we need a timezone, otherwise there is loss of information.

The main issue is that .utcfromtimestamp and .fromtimestamp both return naive datetimes, instead of aware ones with the timezone property set to UTC or the local timezone respectively.

Aramgutang commented on Stop using utcnow and utcfromtimestamp   blog.ganssle.io/articles/... · Posted by u/tomerbd
Aramgutang · 3 years ago
I was familiar with the issue described, but it was useful to learn the shortcut of passing a timezone to `now()`, since I used to rely on `utcnow().replace()`, which was needlessly verbose.

    # what I used to do:
    >>> datetime.utcnow().replace(tzinfo=timezone.utc)
    # what I'll be doing from now on:
    >>> datetime.now(timezone.utc)

Aramgutang commented on The medieval habit of ‘two sleeps’   bbc.com/future/article/20... · Posted by u/shrumm
dang · 4 years ago
I remember it well, and also how curiously it died out. But I don't think it's really that related.
Aramgutang · 4 years ago
It's doubly curious that there hasn't been a recent resurgence. I'd expect that the WFH trend would be making it more practical and sustainable for many.

During polyphasic experiments in my youth, my biggest obstacle was always securing reliable conditions to allow the daytime naps.

Aramgutang commented on Finding a Creature in Ethereum's Dark Forest   bertcmiller.com/2021/12/2... · Posted by u/tosh
stavros · 4 years ago
This is very interesting, thanks! It reminds me of a friend's adventure, he found a contract containing some ETH that could be called with some more ETH and would send the entire sum back to the caller. He analyzed it a bunch of ways to make sure it wasn't a scam, and then sent some ETH to it.

It was a scam.

I wonder how it was done, Etherscan didn't show anything and compiling it led to a few bytes of difference between what was compiled and what was deployed.

Aramgutang · 4 years ago
There are so many clever ways to code honeypots using obscure peculiarities of Solidity and/or Etherscan that there's little hope of being sure that it isn't a scam just by looking at the code and transaction history.

Fortunately, there are tools like Ganache, which you can run with `ganache-cli --fork` to reliably emulate locally what will happen when transactions are sent to mainnet. I would accept no substitute approach when dealing with suspect contracts.

Aramgutang commented on Finding a Creature in Ethereum's Dark Forest   bertcmiller.com/2021/12/2... · Posted by u/tosh
zwkrt · 4 years ago
Saying things about blockchain technologies that paint them in a bad light is taboo for people making money (or imagining making money) on them.
Aramgutang · 4 years ago
The author of the article, Robert Miller, is a leading authority on MEV (Miner/Maximum Extractable Value). Those involved in MEV are quite a different bunch from most of the crypto crowd.

For one, they don't rely on "number go up" to make money, they use strategies similar to those used by HFT firms to make money from market inefficiencies. They generally don't have loyalty to a particular crypto platform, they just go wherever they can find a competitive advantage. They also tend to be much less politically outspoken and often left-leaning, in contrast to the vocal libertarian views that permeate the rest of the field.

They also most certainly aren't "imagining" making money. Most of their strategies are essentially elaborate forms of arbitrage, which are risk-free sources of profit by nature (until out-competed). Their only losses come from fees paid for deploying strategies that turn out to be unsuccessful. Even fees for failed transactions are pretty much a non-issue these days because of Flashbots.

u/Aramgutang

KarmaCake day342November 12, 2010
About
[ my public key: https://keybase.io/kotot; my proof: https://keybase.io/kotot/sigs/r-e6UinIXX1EG9Bu4eS89ym7RLH6GqEcX-xo1TE3kIQ ]
View Original