Hacker Newsnew | past | comments | ask | show | jobs | submit | more Misdicorl's commentslogin

This is not true. Angles very much have units and it's why you can express the same concept with different numbers. Pi equals 180 degrees equals 0.5 turns.

1 radian has different units than 1 steradian and if they didn't there wouldn't be a need for two different words to denote them.

The quantity is a ratio of two lengths, and the length measure does "drop out". But it's not just any ratio, it's a very particular ratio, and the unit defines the particularness of that ratio.


The reason it is confusing is because an angle measure is a kind of logarithm of a rotation, and logarithms (sort of) have a unit: the base.

The appropriate canonical representation of a rotation is a unit-magnitude complex number z = exp = cos θ + i sin θ, which has a planar orientation (whatever plane i is taken to represent; if you want to represent a 3D rotation you can replace i with an arbitrary unit bivector) but is unitless.

Such a rotation z can be thought of as the ratio of two vectors of the same magnitude: z = u / v satisfies zv = u, i.e. is the object by which you can multiply v on the left to obtain u. Whatever original units your vectors u and v had gets divided away.

This is similar to the way the "ten" in "scale by ten" is unitless, but if you take the logarithm you get "scale by 10 decibels" or "go up by 3 octaves and 3.9 semitones", which have the base of the logarithm as a kind of unit.


I think I fundamentally disagree with you. Angles do not have a "base" any more than meters do (being embedded inside some metric space could be considered a base I suppose).

But you seem to be drawing a distinction between meters and angles in your analogy where I assert none exists. The base of a number system only affects representations.

This is not true for divisions of lengths. 1 meter divided by 2 meters is 0.5 as a number. But it is only 0.5 radians under (1ish) specific arrangements of those lengths in a particular metric space


The logarithmic base for an angle is something like "degrees", "radians" or "turns".

This is analogous to the way a scalar logarithm can have a base of "octaves" (doublings), "decibels", or "powers of the golden ratio" (as found in the Zometool construction toy). Or pick your favorite other logarithmic system.

Both are "units" in a certain sense, but neither one is quite the same kind of "unit" as light years or foot–pounds or amperes.

> 1 meter divided by 2 meters is 0.5 as a number. But it is only 0.5 radians under (1ish) specific arrangements of those lengths in a particular metric space

Just as 1 meter straight ahead divided by 2 meters straight ahead is the unitless scalar number 0.5, we can likewise treat angles (i.e. rotations) as ratios: 1 meter straight ahead divided by 1 meter to the right has the unitless bivector-valued ratio i, oriented like the ground you are standing on. You can multiply this bivector by some other coplanar vector to rotate it a quarter turn. For example, you can multiply it by the vector «3 inches due North» to get the new vector «3 inches due West»; notice how the units do not change because our bivector i is unitless.


I understand your analogy, but I reject it's validity. Degrees/radians/turns map to meters/feet/angstrom. Decibels and octaves are true "number" multipliers. You could for instance talk about degrees in octaves or in dB if you like. It's just not particularly useful for the domain

Edit: another example difference. I can't measure an octave or dB. I can measure a degree

Edit2: we've reached reply limit but I concede you can measure a decibel. Point about dB degrees still stands though


You absolutely can measure an octave or decibel. It's just a relative quantity, in just the same way any quantification of orientation is relative.

(For example, you can measure an octave by marking out a particular fret on your guitar; it will make an octave change whichever particular note you start with.)

You can feel free to "reject" whatever you want. You'll just be wrong/confused. ;-) (But you'll be in good company. Most working engineers, scientists, and mathematicians don't have or need a particularly clear philosophical understanding of angles.)


I think this will devolve at this point. But you should consider that you are perhaps far too confident in your position here. My last attempt is due you to consider what happens when you

A) multiply two degrees together

B) multiply two dBm values together

The output "units" in A change but do not in B. dB and angles are very different.

Edit: the units in B do change, but the dB part doesn't. Tired.


Multiplying degrees together is not a meaningful concept.

But you can compose rotations.

Multiplying decibels together is also not meaningful, but you can compose scaling.


> Multiplying degrees together is not a meaningful concept.

Curious what you think of the d_theta * d_phi term in a spherical coordinates integral...


You can compute solid angle (a.k.a. spherical excess, normalized spherical surface area) by taking a surface integral, but the units are not "square degrees" or "square radians", but instead an entirely new type, usually just measured in radians ("steradians"). Some people have defined https://en.wikipedia.org/wiki/Square_degree but that is a stupid unit.

While rotation is naturally oriented like a bivector (plane), solid angle is naturally oriented like a trivector (3-space).

The natural representation is as a kind of (unitless) ratio formed from 3 vectors, not the product of two vector–vector ratios.


Yeah, units that algebraically reduce to 1 are always very interesting to me. Consider a chart showing how many CPU seconds you're consuming per second. The unit is seconds/second, which is equal to 1, but it is still a distinct concept from radians.


Jeez, I've really kicked off quite the heated discussion in the replies... I don't want to get bogged down in lengthy arguments, but I feel I should explain my reasoning in more detail.

Essentially, I think that whatever angles are, they are not like other dimensionful physical quantities. I have two arguments.

The first: Someone mentioned symmetries in a reply. I wanted to mention them too but didn't have time to structure my thoughts into a coherent argument. But the gist of it is that dimensionality is just a kind of scale invariance, and the scale invariance of angles is fundamentally different from that of linear quantities due to their periodicity — to apply a unit transformation, you have to scale the quantity _and the period_.

The second: Consider units from a "type theory" perspective instead. If you are considering exclusively linear trigonometry (no arcs), it's trivial to assign a dimensional type structure to expressions (e.g. cos takes angle type and maps it to dimensionless type). But as soon as you allow arc lengths, it becomes cumbersome to type common expressions.

I think these distinctions form the crux of the disagreement. Ultimately, it depends on your intuitive notion of what "dimensionality" actually means, and how it ought generalise to other kinds of quantities.

Here is an example to highlight my point. Let there be a circle C of centre O and radius r. Let A be a point on the circle. Let there be a point M outside the circle such that (AM) is tangent to C. Let B be the intersection of C and [OM]. Let s be the arc length along C from A to B. Then we want to write AM = r tan(s/r).

How does one get s/r to resolve to an angular dimension? Ought we instead ascribe s dimensions of length-angle? Imagine, then, that the circle is in fact a pulley, and we wish to measure a change x in length of rope as the pulley rotates through the angle of the arc from A to B. We would want to write x = s. But this is now dimensionally inconsistent.

It's certainly possible to make all these expressions correctly typed by introducting appropriate conversion constants. But this seems to me to be cumbersome. Since in physics, arc and linear lengths can convert freely into one another, it seems more economical to just let angles be dimensionless.


The solution to your quandary is to realize the division operator is massively overloaded in your expression. What you actually want is to specify s and r as true line segments and define a new operator which takes two segments and outputs the angle between them. This operator happens to reduce to division of magnitudes in certain circumstances.

Edit: in other words, you've encoded tons of information in the problem statement about the relationship between r and s and you aren't properly encoding that in your type system allowing s/r to output an angle


Surely the lighting matters but I think it is only secondary. The thing that's missing in reproductions is the physical texture of the paintings.


I'm thinking super high-end 3D printers in 10 years will solve this problem.


Detail-wise 3d printed reproductions have been decent enough for a while I think. The trickier part is mimicking the texture of complexly layered and blended oil-paint with filaments.


I'm not so certain. Up close, paintings are complex 3D sculptures made from a palette of materials, (not colors), each with varying levels of translucence, different reflective properties, different textures, etc. and they can be combined and moved around in infinitely complex ways.

Might be possible in a few decades, though.


They’re doing this! Read about the restoration of Rembrandt’s The Night Watch (https://www.rijksmuseum.nl/en/whats-on/exhibitions/operation...). Amazing tech.


desalinization (does require transport infra, but mostly steady state)


Could you solve/mitigate it with curation? Let the users be anonymous or pseudo-anonymous and keep the server signing, but add another signing field called the curator.

At first blush the curation signer looks the same as the server, but I think its subtly different in a way that is maybe effective?

A) You can re-curate or multi-curate a message, but you should (probably) keep the source community constant

B) It separates moderation concerns from on-topic concerns which is a constant struggle. Easy for a server to host many different communities/topics/communication mores and import the content stream in different ways from different curators

Who does the curation? I guess its as simple as the upvote button, but perhaps you can improve that model substantially


Nit: Syscall bound, not necessarily I/O bound.


Both, because it allows async file I/O.


Your application must feel I/O bound. But in reality it must be syscall bound in order for io_uring to make any noticeable improvement.

In other words: if your application is already writing/reading at the max speed the hardware its on allows, you will see no improvement from this. That application is truly I/O bound.

An application that feels I/O bound will be doing lots and lots of little reads and writes and achieving low hardware utilization. That application is syscall bound rather than I/O bound, and io_uring will help tremendously.


I take the same approach with the extra precaution that those logins also get a separate email address (with a different pseudo-strong password). Makes it really easy to share nonsense logins with my wife/family.


Another answer:

> Imagine I want to fetch user data by id from Galactus, the user data service. I know what shape of data I want from it, and Galactus knows what shape of data it provides. Should both my service and Galactus have full, individual copies of this data structure?

No. Galactus should have the full shape of the "user object" but should never put that on the wire or expose it. The wire API should expose sensible things like "what is the billing and shipping address(es) of this user id". Galactus is responsible for maintaining the mapping between the "user object" and whatever the relevant return format is for those data.

Edit: This allows you to run API migrations and data migrations independently. Which is crucial for any service that will last longer than 1 year.


Agreed with all of this. I consider the API structure (which might be defined by protobuf/Avro/Thrift/etc) to be separate from anything that is used by either the server or client services. The API structure is the only thing that should be shared.

When you start out, it will feel very repetitive because your client object structure matches your API structure matches your server object structure. You might even think "DRY!" and want to combine these, but IMO, resist the temptation. You will eventually have a case where these need to evolve independently. For the Galactus case, imagine that for compliance (or whatever) reason, you need to start soft-deleting users, and you do that via the simple case of an `IsDeleted` flag on the User table. You'll need that flag on the User object on the Galactus side, but you don't want to add this to the API and expose it to clients.

> Edit: This allows you to run API migrations and data migrations independently. Which is crucial for any service that will last longer than 1 year.

Totally agreed here too.


Is it normal for people to just splat their database across the wire? Because that seems pretty terrible. We wrap every API response in a DTO and are deliberate about picking and choosing which fields we want to expose. Anything else sounds like a recipe for bad times.


I think it is both an awful idea and very common. In the early stages your database looks very similar (if not identical) to what you want your API to look like, so it's very tempting to reduce boilerplate by having your API and database objects use the same data structures internally.


Yep, it’s a terrible idea but that’s exactly what frameworks like Rais push you to do.


Yes, but that's not his point. Obviously Galactus has some internal user data structure that is private to it.

But there's also something going over the wire, as a response from Galactus' API, and consumed by one of more other services.

His question was, shouldn't the knowledge of the structure of that be in some type of shared code?


IMO if that structure is autogenerated from the API specs (like protobuf, OpenAPI, ...), it's not needed to share it. Plus you can make it evolve at the pace of each service, if your API keeps backwards compatibility.


> This allows you to run API migrations and data migrations independently. Which is crucial for any service that will last longer than 1 year.

I've felt nervous for years about going all-in with Django Rest Framework, and you've articulated exactly why.


We use it at work. We always define the exact fields we want, and can swap them for SerializerMethodFields if we need to do something different/funky. It works very well, imo.


Yeah, I wish every language had something as nice as DRF. I’ve never had issues with it for a few different multi-year codebases.


They made a coulomb bomb https://gravityandlevity.wordpress.com/2013/05/22/what-if-i-...

> I worked on all sorts of problems that involved the Coulomb interaction, and occasionally my proposed solution would be very wrong. The worst kind of wrong was the one that made my advisor remark “What you just created is a Coulomb bomb,” which meant that I had proposed something that wasn’t neutral on the large scale.


Its callous, not stupid. Consider whether those individuals best work (nobel prize granting e.g.) came before or after they started families. Consider how involved they can be with their families given how often you likely saw them around the department. Yes, it can be done. But its hard. And you're unlikely to be ultra successful if you devote the time your family deserves (not to mention the luck/charisma/skill/dedication needed on top of that).


Albert Einstein was married and had a kid by the time of his “miracle year” in 1905.


Albert's wife agreed to this:

A. You will make sure:

1. that my clothes and laundry are kept in good order;

2. that I will receive my three meals regularly in my room;

3. that my bedroom and study are kept neat, and especially that my desk is left for my use only.

B. You will renounce all personal relations with me insofar as they are not completely necessary for social reasons. Specifically, You will forego:

1. my sitting at home with you;

2. my going out or travelling with you.

C. You will obey the following points in your relations with me:

1. you will not expect any intimacy from me, nor will you reproach me in any way;

2. you will stop talking to me if I request it;

3. you will leave my bedroom or study immediately without protest if I request it.

D. You will undertake not to belittle me in front of our children, either through words or behavior.


Maybe it's that being married and having children helped them be successful.


Are housing prices in Seoul seeing the same inflation we see in many western cities? I'd be mildly surprised. (Anecdotally) It seems like Asian cultures are much less likely to treat housing as an investment and/or allow the few to dictate to the many (specifically in the housing arena).


>It seems like Asian cultures are much less likely to treat housing as an investment

Isn’t China one of the most prominent examples of using real estate as investment? There’s even whole ghost towns of apartment buildings that are constructed for this purpose.


yea all my Chinese (in China) relatives assume you should only invest in housing. And then when we tell them we have zero investment properties, they get really, really concerned for our future welfare and think that we're not doing very well.


Isn't all that investment outside of China? My understanding was ghost towns weren't investment based but planning failure based


No, domestic savers have capital controls and do not have the means to move money easily outside the country. The stock market also is not reliable in China as an avenue of investment. Government pensions are also small. So that mostly leaves real estate.

Evergrande Group is emblematic of the real estate industry’s trouble there. Property is 15-30% of Chinese GDP and much of it goes towards investment property.


Thanks!


Yes. Seoul housing is inflated.

No. Koreans and Chinese both love propping up property as an investment.

Japanese are the ones who don't, as their system is vastly less investment oriented and less expandable.


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

Search: