Hacker News new | past | comments | ask | show | jobs | submit | mbroshi's comments login

Brilliant! Makes a simple children's game very interesting. One aspect I really enjoy is that it makes clear the knee-jerk response towards action bias[0]. There are times when your opponent has two-in-a-row, but the probability of a frown on the third is > 50%, in which case it's in my interest to have my opponent click on the third square instead of me (but even knowing that cognitively, it's still hard to not action).

[0]: https://en.wikipedia.org/wiki/Action_bias



FYI, Sage is also the name of a mathematical programming language: https://www.sagemath.org/


Thank you!! Sage will eventually change its name (I just recently found out about this), but I haven't had time to come up with a good replacement name and make art + quippy sayings for it yet! :)

I might just go with a completely made up word to avoid any trademarks entirely haha


What are the constraints that you want for the name?

I was thinking "Pragmata", or something along those lines.

Continuing with natureish themes: Alga Moss Myco Wisp Ivy


My major constraint is just that the name must lend itself well to artistic representations and fun mottos/slogans hahaha!

I love these suggestions, especially Moss and Ivy! Thank you!


I was surprised to find no associated programming languages for sumac and bay (leaf).


Mint? ;)



Hahaha I doubt there's an English word left!!!


Rosemary and Oregano are free! Thyme is not.


How long until we enumerate all the herbs?!?!?!?!?! The pantry's almost empty!!!


I like it! And if that's trademarked too I could always fall back on "spearmint" instead haha


I used SageMath for my masters. It was a life saver.


I'll have to check it out and reimplement it's good features for THIS Sage hahaha


There's an implicit assumption that the organizers would cancel the race if conditions are unsafe. E.g., when I go on a rollercoaster, I assume engineers have calculated the safety better than I could ever evaluate


Sounds like an interesting--although presumably not easily and quickly scalable--solution to fertilizer shortages. I am dubious about the environmental improvement. According to a meta-analysis[0], chemical fertilizers produce less ammonia emissions

> However, ammonia emissions, nitrogen leaching and nitrous oxide emissions per product unit were higher from organic systems.

Basically, chemical fertilizers are much more efficient and have more uniform distribution of nutrients.

[0]: https://www.sciencedirect.com/science/article/pii/S030147971...


I see a lot of doubters, but the bet is still open. If you're so doubtful, go ahead and put your money where your mouth is!


It isn't a bet. It is a donation to charity with the hassle of going through a registration process.


> Did you use a regex to verify the data looks like a uuid before putting it into the database?

Is that really a thing? I have used UUIDs as primary keys many times in my life, and never had a need to do such a thing. I am struggling to even think of a valid use case.


> Did you use a regex to verify the data looks like a uuid before putting it into the database? Is your database (like sqlite) using a case sensitive collation for the column? Then you have a problem.

yeah, it seems like the premise is flawed. I don't know that there's actually a problem here.


Might be related to the use of SQLite which doesn't really support data types to begin with and allows to store anything in a column regardless of the declared data type (e.g. you can store 'fourty two' in a column declared as integer).

Apparently it's a deliberate decision because they don't really want to be a "database" just something better then "a file".


Strict table support came in last year to help address this: https://www.sqlite.org/stricttables.html


The only thing I can think of is if the user can export data from one system and import it to another, and for some reason there was a requirement to keep the UUIDs the same.

...or maybe if you're storing data from a remote API that uses UUID's as primary keys, and you want to make sure you catch it if they change things. Though in that case I would likely have my own primary key and store the remote primary key in a separate column


This is something I have thought about a lot.

I have had coffee daily, gone months without any caffeine, and currently average about one cup of coffee every week or two.

I think the best approach is experimental and data-driven. Everyone has different genes, life circumstances, sleep quality, etc., so it's hard to deduce too much from others' anecdotes. Once a week, I do a version of the Beck Depression Inventory[0] to measure my mood over the previous week. For me, daily coffee definitely causes me to be slightly depressed. I have found a cup when I really need it (which is about once every week or two) is ideal. But, whatever it is you want to optimize for (lines of code, happiness, sleep quality, etc.), make sure you are measuring, and then start experimenting!

[0]: https://en.wikipedia.org/wiki/Beck_Depression_Inventory


As Tyler Cowen always responds to headlines like this: "If it’s true, why isn’t the price of oil down?"


This is a great idea! I tried it on a 200-page document [1], and it took over a minute to process in my browser, and the result seems to be about 75% highlighted. Not sure if it's the "math-ese" or length that is the issue.

One cool thing is that it highlighted both the same sentences in English and French. I presume you translate the text before analyzing.

[1] https://www.math.mcgill.ca/darmon/theses/leahy/thesis.pdf


Hi mbroshi,

There's no translation being done at all! It's completely language-agnostic (apart from some hardcoded signal words, which I only noted down in English).

Really large documents such as entire books or theses are supported, but as you've experienced it results in a far from ideal experience at this point. Thanks for reporting this and linking to the document, now I know that this is a problem worth addressing. :)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: