Like freeways, it's not clear that increasing the baseline ram for basic laptops is an effective way to mitigate software bloat. Rather it likely creates bloat.
Claud.ai 3.7 sonnet: The current date is Tuesday, March 11, 2025.
gemini.google.com 2.0 flash: The current date is Tuesday, March 11, 2025.
grok.com: The current date is March 10, 2025.
amazon nova pro: The current date, according to the system information available to me, is March 11, 2025.
Please keep in mind that my data and knowledge were last updated in October 2023, and I don't have access to real-time information.
chat.qwen.ai 2.5-max: I don't have access to real-time data, so I can't provide the current date. However, you can check the date and time on your device's clock or by searching online. Let me know if you need help with anything else!
chat.deepseek.com: Hi there! I suggest getting online to get real-time information. If you have any other questions, please don't hesitate to let me know!
anthropic/claude35sonnetv2: Today's date cannot be [2024-11-23], as that is a future date. I can only verify that we are having this conversation today and cannot independently determine the current date. You may want to check your system clock for the accurate current date.
meta/llama32.90B: I don't have real-time access to the current date. However, based on our conversation history, I can tell you that my knowledge cutoff is December 2023, and you mentioned earlier that the conversation started after that. You can check your system clock for the accurate current date.
mistral/mistral-7b-instruct-v0: I'm unable to determine the current date, as I don't have real-time access or the ability to check your system clock. You should check your own system or a reliable online source for the current date.
google/gemini-2.0-flash-exp: I cannot give you the current date. I do not have access to real-time information.
Makes a lot of sense, thinking about it. I.e. the models that presumably have been given access to calling out to "live functions" can do stuff like that and/or have been specifically modified to answer such common questions correctly.
I also like it when they just tell you that they're a language model without such capabilities. That's totally fine and OK by me.
What I really don't like is the very confident answer with a specific date that is so obviously wrong. I guess the October 2023 thing is because I've been doing this with models where that's the end of training data and not others / retrained ones.
I like the idea of users being able to pick their 3-hour window and timezone, and maybe only can change your window setting once per day (or maybe only pick a new window that starts at least 24 hours in the future). But crucially, each such 3-hour window and time zone combination has entirely isolated and independent content, as if it is a different site.
So my community could be 7:02-10:02pm EST. And if I instead switch to say 6am-9am IST instead, I can check in with the folks who like to meet in the mornings in india, but I am temporarily gone from my own local community.
"This is completely wrong."
Is it completely wrong? Or maybe "somewhat" wrong? Maybe just lacking nuance?
I know nothing about the answer to this question, so this is an honest question.
Using just a plain old search engine, for things like "national drink of the netherlands" and simlar queries, I am directed to Wikipedia's Jenever page as the top hit, and Wikipedia's list of national drinks lists Jenever and Heineken as the entries for the Netherlands. Search engines also give page after page of travel guides and blog posts, most of which list Jenever at or near the top of of their listings. One travel guide calls it "the most famous Dutch spirit and most famous Amsterdam liquor, Jenever, also spelled Genever or simply Dutch gin."
The REDS-HEIG version you link to has more development activity, support for a wider variety of FPGAs, and a few other advanced features. My version has some neat features not found in REDS-HEIG fork, and usually aims to keep the interface more beginner-friendly and streamlined for use as student's first-contact with digital circuits.
What do you mean? All the inputs are continuous: light sensors, LIDAR, infra-red, inputs from mechanical sensors from the driver. Sure, the sensor package's hardware/firmware/software converts these to discrete inputs before it reaches the Driving AI, but all of the Buridan's Paradox results still apply to those sensor packages. They can't perform their tasks in a finite amount of time -- either they will sometimes fail to make a decision at all, or they will render an invalid output (e.g. rather than outputting voltage corresponding to logical 0 or 1, they will go into a meta-stable or astable output mode that is not a valid output voltage).
>rather than outputting voltage corresponding to logical 0 or 1, they will go into a meta-stable or astable output mode that is not a valid output voltage
It sounds like you could easily avoid this. You can use a microprocessor and lead in analog input on one pin and then set an output pin based off that. You will always output a valid voltage. Sensors have noise anyways so it's not a big deal if the output is slightly wrong.
The paper specifically details several situations in which humans are the ones making the decision, and the result is the same. There is no bounded-time decision procedure that can take continuous (i.e. physical) inputs and render a discrete decision.
The missing piece of "just choose to always go left" is that this is a degenerate and uninteresting case. No decision is being made.
The range must be discrete and at least 2 possible values.
There is nothing about optimality at all here. Even if both possible outputs are equally "optimal", there is no procedure to pick one in a finite amount of time.
I doubt the issue has anything to do with being interesting or not. Do you know this for a fact or can give me anything to follow up on what it means for a decision to be interesting? For example if a decision procedure required the choice of chocolate or vanilla depending on the current time of day (a continuous input resulting in a discrete output), and I present an algorithm that categorically chooses chocolate regardless of what time it is, I doubt you'd turn around and claim that my algorithm is not making a decision because it always chooses chocolate.
If an algorithm takes an input, continuous or discrete, discards that input and returns a constant value, that algorithm is just as "legitimate" as any other algorithm in so far as being an algorithm is concerned. It may not produce the optimal output for some given cost, but it is a formal and rigorous decision procedure that manages to output a discrete value given a continuous input in a bounded amount of time.
At any rate, reading the comments when this was last posted it looks like the issue has to do with producing the optimal output in a given time frame. If an optimal discrete decision must be made in the next T seconds on the basis of a continuous input X, then there always exists some value of X that requires more than T seconds to compute. This will be true for any value of T regardless of how large.
reply