Val: Difference between revisions

Line 10:

== Motivation ==

If you want to find an approximation to a just interval, the immediate question is: why would you need an algorithm instead of just looking at the [[direct approximation]] possible in the edo? The answer is to avoid contradictions. For example, it might not be true that ([[~]][[6/5]])([[~]][[5/4]]) = [[~]][[3/2]] or that (~9/1)(~5/1) = ~45/1 if you are just always using the direct approximation of each of these frequency ratios (6:5, 5:4, 3:2, 9:1, etc.) in the edo, because of something called ''inconsistency'', which means if you know what intervals that you want to combine are, then combining their approximations in the edo does not give you the same result as multiplying their ratios ''first'' and ''then'' using the direct approximation of that in the edo. When this happens, we say that the arithmetic is ''inconsistent''. Therefore when this does not happen, we say that the result is [[consistent]].

If you want to find an approximation to a just interval, the immediate question is: why would you need an algorithm instead of just looking at the [[direct approximation]] possible in the edo? The answer is to avoid contradictions. For example, it might not be true that [[~]][[6/5]] × [[~]][[5/4]] = [[~]][[3/2]] or that [[~]]9/1 × [[~]]5/1 = [[~]]45/1 if you are just always using the direct approximation of each of these frequency ratios (6:5, 5:4, 3:2, 9:1, etc.) in the edo, because of something called ''inconsistency'', which means if you know what the intervals that you want to combine are, then combining their approximations in the edo does not give you the same result as multiplying their ratios ''first'' and ''then'' using the direct approximation of that in the edo. When this happens, we say that the arithmetic is ''inconsistent''. Therefore when this does not happen, we say that the result is [[consistent]].

Unfortunately, when this happens, it is not possible to fix the inconsistency, except by using a different edo that approximates the intervals in question better so that the multiplication or division of their approximations is consistent, but that is not actually necessary. Plus, even if you did that, there would still be other inconsistent ratios because an approximation cannot be perfect, so you cannot truly eliminate the inconsistency completely. Rather than giving up and saying that we cannot guarantee that (~6/5)(~5/4) = ~3/2 or (~9/1)(~5/1) = ~45/1 or (~135/128)(~24/25) = ~81/80, etc. in our chosen edo, it turns out we ''can'' actually guarantee this if we are willing to allow one or more of these ratios to '''not''' use the closest approximation by using a val. This may seem strange in this example, as one likely wants at least (~6/5)(~5/4) = ~3/2, but in principle we probably do not mind if something more complex is inconsistent, like (~11)(~11)(~75) = ~9075, if we can guarantee that the arithmetic never fails us.

Unfortunately, when this happens, it is not possible to fix the inconsistency, except by using a different edo that approximates the intervals in question better so that the multiplication or division of their approximations is consistent, but that is not actually necessary. Plus, even if you did that, there would still be other inconsistent ratios because an approximation cannot be perfect, so you cannot truly eliminate the inconsistency completely. Rather than giving up and saying that we cannot guarantee that ~6/5 × ~5/4 = ~3/2 or ~9/1 × ~5/1 = ~45/1 or ~135/128 × ~24/25 = ~81/80, etc. in our chosen edo, it turns out we ''can'' actually guarantee this if we are willing to allow one or more of these ratios to '''not''' use the closest approximation by using a val. This may seem strange in this example, as one likely wants at least ~6/5 × ~5/4 = ~3/2, but in principle we probably do not mind if something more complex is inconsistent, like ~11 × ~11 × ~75 = ~9075, if we can guarantee that the arithmetic never fails us.

== Definition ==

Line 25:

== Using a val ==

Using the 26edo val {{val| 26 41 60 }} as our example, say we want to figure out how [[9/8]], [[5/4]] and (9/8)(5/4) = [[45/32]] are mapped.

Using the 26edo val {{val| 26 41 60 }} as our example, say we want to figure out how [[9/8]], [[5/4]] and 9/8 × 5/4 = [[45/32]] are mapped.

First we have to find the {{w|Integer factorization|prime factorization}} of our intervals (then we deduce the mapping from the prime factorization and the val):

Line 41:

* log<sub>2</sub>(5/4) × 26 = 8.370… which rounds to 8 steps

* log<sub>2</sub>(45/32) × 26 = 12.788… which rounds to 13 steps

So here we can see that (9/8)(5/4) = 45/32 is inconsistent because 4 + 8 is not equal to 13, in other words, 4 + 8 = 12 fails. So we can see that the val "fixes" the 13 to 12 by obeying an ''internal'' logic provided by the val; in different contexts it may be different intervals that are fixed; not necessarily the more complex one, though usually that is how it works for edos of interest.

So here we can see that 9/8 × 5/4 = 45/32 is inconsistent because 4 + 8 is not equal to 13, in other words, 4 + 8 = 12 fails. So we can see that the val "fixes" the 13 to 12 by obeying an ''internal'' logic provided by the val; in different contexts it may be different intervals that are fixed; not necessarily the more complex one, though usually that is how it works for edos of interest.

So you may have noticed that there was quite a bit of repeated addition we can simplify, so let us note how we can simplify it exactly. Specifically, using exponent notation and not omitting implicit "to the power of 0"'s, the prime factorizations we worked out above are equivalent to:

Line 55:

* mapping of 5/4: {{val| 26 41 60 }}{{monzo| -2 0 1 }} = 26 × -2 + 41 × 0 + 60 × 1 = -52 + 0 + 60 = 8 (steps of 26edo)

* mapping of 45/32: {{val| 26 41 60 }}{{monzo| -5 2 1 }} = 26 × -5 + 41 × 2 + 60 × 1 = -130 + 82 + 60 = 12 (steps of 26edo)

This is all very tedious, but in practice using a val is much simpler, because you do not need to do this, all you need to know is [[5/4]] is mapped to 8\12 and [[3/2]] is mapped to 15\26, therefore [[9/4]] is mapped to 30\26, therefore [[9/8]] is mapped to (30 - 26)\26 = 4\26, so that since we know (9/8)(5/4) = 45/32, the mapped version of 45/32 will just be 4 + 8 = 12. This method guarantees that you never contradict yourself, even if you are technically using suspicious approximations.

This is all very tedious, but in practice using a val is much simpler, because you do not need to do this, all you need to know is [[5/4]] is mapped to 8\12 and [[3/2]] is mapped to 15\26, therefore [[9/4]] is mapped to 30\26, therefore [[9/8]] is mapped to (30 - 26)\26 = 4\26, so that since we know 9/8 × 5/4 = 45/32, the mapped version of 45/32 will just be 4 + 8 = 12. This method guarantees that you never contradict yourself, even if you are technically using suspicious approximations.

For the mathematically inclined, note that this operation is the same as taking the {{w|dot product}} between the monzo and val interpreted as ordinary vectors.

@@ Line 10: / Line 10: @@
 == Motivation ==
-If you want to find an approximation to a just interval, the immediate question is: why would you need an algorithm instead of just looking at the [[direct approximation]] possible in the edo? The answer is to avoid contradictions. For example, it might not be true that ([[~]][[6/5]])([[~]][[5/4]]) = [[~]][[3/2]] or that (~9/1)(~5/1) = ~45/1 if you are just always using the direct approximation of each of these frequency ratios (6:5, 5:4, 3:2, 9:1, etc.) in the edo, because of something called ''inconsistency'', which means if you know what intervals that you want to combine are, then combining their approximations in the edo does not give you the same result as multiplying their ratios ''first'' and ''then'' using the direct approximation of that in the edo. When this happens, we say that the arithmetic is ''inconsistent''. Therefore when this does not happen, we say that the result is [[consistent]].
+If you want to find an approximation to a just interval, the immediate question is: why would you need an algorithm instead of just looking at the [[direct approximation]] possible in the edo? The answer is to avoid contradictions. For example, it might not be true that [[~]][[6/5]] × [[~]][[5/4]] = [[~]][[3/2]] or that [[~]]9/1 × [[~]]5/1 = [[~]]45/1 if you are just always using the direct approximation of each of these frequency ratios (6:5, 5:4, 3:2, 9:1, etc.) in the edo, because of something called ''inconsistency'', which means if you know what the intervals that you want to combine are, then combining their approximations in the edo does not give you the same result as multiplying their ratios ''first'' and ''then'' using the direct approximation of that in the edo. When this happens, we say that the arithmetic is ''inconsistent''. Therefore when this does not happen, we say that the result is [[consistent]].
-Unfortunately, when this happens, it is not possible to fix the inconsistency, except by using a different edo that approximates the intervals in question better so that the multiplication or division of their approximations is consistent, but that is not actually necessary. Plus, even if you did that, there would still be other inconsistent ratios because an approximation cannot be perfect, so you cannot truly eliminate the inconsistency completely. Rather than giving up and saying that we cannot guarantee that (~6/5)(~5/4) = ~3/2 or (~9/1)(~5/1) = ~45/1 or (~135/128)(~24/25) = ~81/80, etc. in our chosen edo, it turns out we ''can'' actually guarantee this if we are willing to allow one or more of these ratios to '''not''' use the closest approximation by using a val. This may seem strange in this example, as one likely wants at least (~6/5)(~5/4) = ~3/2, but in principle we probably do not mind if something more complex is inconsistent, like (~11)(~11)(~75) = ~9075, if we can guarantee that the arithmetic never fails us.
+Unfortunately, when this happens, it is not possible to fix the inconsistency, except by using a different edo that approximates the intervals in question better so that the multiplication or division of their approximations is consistent, but that is not actually necessary. Plus, even if you did that, there would still be other inconsistent ratios because an approximation cannot be perfect, so you cannot truly eliminate the inconsistency completely. Rather than giving up and saying that we cannot guarantee that ~6/5 × ~5/4 = ~3/2 or ~9/1 × ~5/1 = ~45/1 or ~135/128 × ~24/25 = ~81/80, etc. in our chosen edo, it turns out we ''can'' actually guarantee this if we are willing to allow one or more of these ratios to '''not''' use the closest approximation by using a val. This may seem strange in this example, as one likely wants at least ~6/5 × ~5/4 = ~3/2, but in principle we probably do not mind if something more complex is inconsistent, like ~11 × ~11 × ~75 = ~9075, if we can guarantee that the arithmetic never fails us.
 == Definition ==
@@ Line 25: / Line 25: @@
 == Using a val ==
-Using the 26edo val {{val| 26 41 60 }} as our example, say we want to figure out how [[9/8]], [[5/4]] and (9/8)(5/4) = [[45/32]] are mapped.
+Using the 26edo val {{val| 26 41 60 }} as our example, say we want to figure out how [[9/8]], [[5/4]] and 9/8 × 5/4 = [[45/32]] are mapped.
 First we have to find the {{w|Integer factorization|prime factorization}} of our intervals (then we deduce the mapping from the prime factorization and the val):
@@ Line 41: / Line 41: @@
 * log<sub>2</sub>(5/4) × 26 = 8.370… which rounds to 8 steps
 * log<sub>2</sub>(45/32) × 26 = 12.788… which rounds to 13 steps
-So here we can see that (9/8)(5/4) = 45/32 is inconsistent because 4 + 8 is not equal to 13, in other words, 4 + 8 = 12 fails. So we can see that the val "fixes" the 13 to 12 by obeying an ''internal'' logic provided by the val; in different contexts it may be different intervals that are fixed; not necessarily the more complex one, though usually that is how it works for edos of interest.
+So here we can see that 9/8 × 5/4 = 45/32 is inconsistent because 4 + 8 is not equal to 13, in other words, 4 + 8 = 12 fails. So we can see that the val "fixes" the 13 to 12 by obeying an ''internal'' logic provided by the val; in different contexts it may be different intervals that are fixed; not necessarily the more complex one, though usually that is how it works for edos of interest.
 So you may have noticed that there was quite a bit of repeated addition we can simplify, so let us note how we can simplify it exactly. Specifically, using exponent notation and not omitting implicit "to the power of 0"'s, the prime factorizations we worked out above are equivalent to:
@@ Line 55: / Line 55: @@
 * mapping of 5/4: {{val| 26 41 60 }}{{monzo| -2 0 1 }} = 26 × -2 + 41 × 0 + 60 × 1 = -52 + 0 + 60 = 8 (steps of 26edo)
 * mapping of 45/32: {{val| 26 41 60 }}{{monzo| -5 2 1 }} = 26 × -5 + 41 × 2 + 60 × 1 = -130 + 82 + 60 = 12 (steps of 26edo)
-This is all very tedious, but in practice using a val is much simpler, because you do not need to do this, all you need to know is [[5/4]] is mapped to 8\12 and [[3/2]] is mapped to 15\26, therefore [[9/4]] is mapped to 30\26, therefore [[9/8]] is mapped to (30 - 26)\26 = 4\26, so that since we know (9/8)(5/4) = 45/32, the mapped version of 45/32 will just be 4 + 8 = 12. This method guarantees that you never contradict yourself, even if you are technically using suspicious approximations.
+This is all very tedious, but in practice using a val is much simpler, because you do not need to do this, all you need to know is [[5/4]] is mapped to 8\12 and [[3/2]] is mapped to 15\26, therefore [[9/4]] is mapped to 30\26, therefore [[9/8]] is mapped to (30 - 26)\26 = 4\26, so that since we know 9/8 × 5/4 = 45/32, the mapped version of 45/32 will just be 4 + 8 = 12. This method guarantees that you never contradict yourself, even if you are technically using suspicious approximations.
 For the mathematically inclined, note that this operation is the same as taking the {{w|dot product}} between the monzo and val interpreted as ordinary vectors.